Loading...
May 12, 2012#

Lean UX, lean deliverables duh!

Forgive me if this blog post rambles a little, I just needed to find an outlet for some recent musings around the nature of user centred deliverables and their usage.

So I have started a personal crusade to deliberately create deliverables that convey exactly what I want them to, to the right people.  Interestingly enough, this has led to some sometimes wacky, but really cool design artifacts that paint the right pictures in the seconds worth od attention span I usually get from the stakeholders involved.

What should we standardise?

Firstly, when I get informed that a project demands another set of ‘wireframes’, or page flows or user journeys or user flows. I find myself becoming increasingly eager to challenge the purpose and nature of these deliverables.  Especially when they are asking for other deliverables to be produced in an agile/simultaneous manner (e.g. high fidelity mock-ups with annotations)

I suppose that with all the various disciplines of the web over the last 20 years or so, we have all as professionals tried to mature and become more formalised in our approaches.  Led by the IT engineering counterparts who have explored and applied practices to increase working efficiencies and thusly allowing better management.

Now, whilst I am completely onboard with this.  I am also concerned. As a user experience practitioner, I strongly believe that around a third of my role lies conceptualising solutions based on user centred design practices and knowledge from the usually associated disciplines of HCI, cognitive science and user centred analysis.

Another third of the role is the ability to capture, examine and convey the complexities of an experience and communicate the journey one has undertaken from concept to recommendation.  For me, this is such an exciting and often challenging enterprise in itself.  So, given the freedom to define the deliverables where necessary on a project is of paramount importance to the success of communicating and exerting an overall positive influence on those needed to be enlightened.

The final third (and i’m sure the distribution of these job functions can vary dependent on one’s t-shape) area I feel I need to accomplish is to become the champion and influencer of change for the user.  Again, the importance of creating captivating deliverables that can give brief summary, codified takeaways and joined up thinking as to quickly distill the essence of that which we wish to change.

Without being to verbose on this matter, the concept of standardised deliverables has been recently becoming an issue of growing concern.  UX is being absorbed by the masses, and client’s are appointing so called ‘UX coordinators’ to help set the interface for deliverables.  Now with a limited understanding of the intricacies of consulting for UX I feel there is an inherent danger that this situation leaves us in a situation that locks our deliverables into project plans where we cannot be feel as free to create the right, more agile deliverable to suit the unexpected moment.

Lean UX vs Agile Project Management

It feels like the literal application of the more transitional UX deliverables is becoming out of date.  I would love to drive the need for deliverables on the basis of each client or team that requires information.

Just because page flows were traditionally an approach to documenting fairly static sites from the mid-2000s doesn’t mean it should still be looked upon as a deliverable of value on a highly dynamic responsive application today.

If the stakeholders wish to see ‘wireframes’, why can’t we create hybrid user journeys with wireframes? We can!!!

The issue is, before one gets into the thick of a project, it is difficult to be able to predict the kind of bespoke deliverable one may need to use.  And therefore we end up feeding into a project plan that is not worth the paper it is printed on.

Recently, whilst trying to champion several versions of a site navigation structure highlighting the ideal hierarchy and then referencing the impact potential technical limitations.  It became naturally apparent to create a representational diagram illustrating the user frustration of each real representation based on the original site structure and linking the perceived experience to the personas.

When I used this artefact with the stakeholders, it accelerated the conversation and they remarked how much clearer it was than attempting to communicate the issue via the traditional site structure diagram which we had created at the original request of the client from a deliverable perspective.

Summary

I suppose this is what it is like when we try to formalise and bring standards to any discipline.  It just feels like some elements of the user experience practitioners toolkit should not be needed to be commoditised so heavily.

Running a leaner project is great, but it feels like in the quest for producing agile project plans we shoe horn our work into ‘one size fits all’ deliverables instead of being more pragmatic dependent on client, sector, project and stakeholders involved.

I really hope to see people embrace more flexible, interesting and lightweight deliverables/artifacts that instead focus on various abstract elements of a user experience.  They draw together the complexities in a fun and user centric way.

What do you think? How do you introduce a more flexible approach to your deliverables in the context of a specific message you want to convey that an ‘off the shelf’ deliverable might not succinctly communicate? Would love to know your thoughts!

Leave a Comment