Our Blind Spot: Creating a Shared UX Vision

Related posts:


The most difficult thing about UX design is not creating the experience, but making sure it gets delivered as conceived. Whilst it might be terribly easy to blame the developers, or worst still the client, the reason why delivery may not match the concept is a little closer to home.

A shared vision?

The truth is: there is rarely a shared vision or understanding of the end experience amongst all parties. This is not down to the abilities of the UX designer, but the way in which the experience gets communicated. We have come to rely on a set of tools and documentation that instead of giving a unified view, allows different people to project different outcomes from it.

So I found myself nodding furiously at Jeff Gothelf’s article Lean UX: Getting Out Of The Deliverables Business, calling for a more agile UX process less defined by the deliverables. We have trained clients to believe that the value lies in the documentation itself, demoting the UX to a sign-off phase. It means we disengage decision makers at the very point their input is most crucial.

we disengage decision makers at the very point their input is most crucial

Whilst we have been advocating this ‘rapid-prototyping’ approach for some time it does not remove the need for documentation altogether, but we do need to create a better understanding of its purpose and application.

Communicating the vision

Our stock-in-trade site map, wireframe and visuals are very poor at communicating the vision to a user or stakeholder, but are essential for documenting it. I link this to the electrical wiring diagram for your house. The electrician needs it, but you just need to know that all the sockets are in the right place.

Some document types and techniques are great for concepting, but not great for sharing. We need others to describe the user context we are designing for (semantic arguments aside see Helge Fredheim’s articles on Why User Experience Cannot Be Designed). Neither promotes the shared vision we need – although they are vital to making sure we understand the users’ mental models. This is where the interactive prototype, the video and the storyboard come in. They are real and give the reviewer a true picture of the end experience. It’s an approach more akin to the way advertising agencies and TV producers work and more in tune with the kinds of digital assets we are making now. It is only with this more accessible view that a proper assessment can be made as to whether the experience meets both the needs of the user and the demands of the business.

This is where the interactive prototype, the video and the storyboard come in. They are real and give the reviewer a true picture of the end experience.

Where has this come from?

As UX professionals we are used to working with closed, task based infrastructure systems, led by technology constraints or a CMS – basically desktop applications and websites. This is where the documents have evolved from, as they define and codify the closed system and how a user interacts with it. If this is the context we are designing within, then the more ‘traditional’ approach fits. It gives the blueprint needed to make sure that the end result is usable and fit for its purpose.

The thing is these infrastructure builds form a very small proportion of today’s UX output. The adaptive design of content-led sites and mobile or social apps needs a different approach. As does the creation of rich content. We also need to build a proper appreciation of how the UX reaches beyond the interaction with the technology or content itself, to interact with other systems and the physical world.

No one size fits all

The key, as usual, is in avoiding the one size fits all approach. It’s not about throwing out the tools and techniques we have honed, but knowing when and where to apply them. An ‘agile UX’ approach has a place in this but is not a solution in itself. We need a flexible, fluid framework that focuses on the specific experience, within the specific context, to bring the vision to life.

A new order

So perhaps we need to turn it all on its head. Perhaps it’s time for a new order where the site map and wireframes are the end, not the start point. Where content creation, prototyping and storytelling take point in a collaborative process that unifies the user, the designer, the developer and the brand in a shared vision.

Jeremy Baldwin

Jeremy Baldwin is a company director at Bright Blue Day, a full-service design and marketing agency based in Dorset, UK. He is also a keen creeper, regularly exploring old and abandoned buildings.

3 comments on this article

  1. Jeremy,

    Is this really a blind spot for UX practitioners and projects? The lack of a shared vision certainly takes place; even frequently so; but this challenge has been discussed and addressed to varying degrees for nearly a decade. Videos, prototypes, and storyboards are common tools used to tell a story about the intended experience. There are others – equally or better suited to the task – all of which should not come as news to a UX practitioner. Especially not to those responsible for articulation a vision for the end experience.

    Whilst I agree with the underlying point that a shared vision is important to the successful implementation of the design, blaming its absence on an ignorance of storytelling techniques seems a stretch. As a broad community storytelling and narrative have enjoyed a relatively high prominence for three years or more.

    Nor do I think we need look to Agile methods to alleviate this problem. My understanding of the area – and I admit it isn’t deep – is that the work of envisioning and communicating the desired end point is done prior to an Agile approach being introduced. Collaboration: yes; participation: yes. A purposeful and concise use of documentation: certainly.

    “The thing is these infrastructure builds form a very small proportion of today’s UX output” – I would also question the veracity of this statement. Again, my experience with the industry in Australia, US, Europe and Asia suggests that, for the vast majority of UX practitioners, technology-led, Web- or mobile-based projects are the norm; and designing for experiences in physical environments, for example, is the exception.

    This is changing. And the wireframe and sitemap are certainly not appropriate artefacts for communicating, say, the experience of a face-to-face interaction. But then, they’re not appropriate for communicating any part of that interaction anyway. We do need different methods of articulating the design for these experiences, but those methods are already in widespread use, and I certainly endorse the view that UX practitioners should be familiar with them.

    Steve

  2. Pingback: Reading notes of “Lean UX: Getting Out Of The Deliverables Business” « Xun and Interaction Design

  3. I believe this is a key issue and as Steve says this is not a new one. How do we take a vision for an experienced and then design for such an experience?
    I believe there are two main components to this issue: artefacts and actors. Artefacts (or artifacts if you prefer) are the “things” we create as designers. When these are used to communicate they become a kind of boundary object, but the problem is while a certain artefact may be great for a designer it may not be great for other parties. Actors are those people who are involved in bringing an experience to fruition. I think most of us recognize the age-old problem of not having the right people involved in a team consistently and then we end up “throwing things over fences” i.e. we’re done designing it, now you build it, or we’re done building it, now you sell it, or we’re done defining a market for it now you design it.
    We’ve got to address both of these issues to make real improvement on this.