The difference between Usability and Experience Design

I hear a lot of people using "Usability" and "Experience design" interchangeably. This is quite a big mistake.  They are both important for product success, both are tested differently, both are successfully crafted differently, and they both need quite different focus and skill sets. Usability answers the question: "Can the user accomplish the goal"?

Experience Design answers the question: "Is the user delighted"?

Imagine you go to a retail website to buy a pair of jeans. You arrive at the homepage and easily find and navigate to the jeans that you want. You pick your size and the colour. You add them to your cart without a hitch, pay and check out. Job done: awesome.

This is usability. Your customers can easily buy products off your website. They understand what to do, it all works as expected, it's easy, and fast.

Ok. It's 5 days later and your jeans have arrived, but 3 days later than promised. They are the wrong size and the wrong brand. You can't find out how to send them back and ask for your order to be filled properly. None of this information is with your package. You go to the website and after 10mins of searching find a phone number. You're not sure whether it's a customer service number or not but you call it anyway. You listen to 5mins of options to choose from on a recording before you even get to speak to a human. Finally a tired sounding man sighs and then says "whateverjeansdotcomcustomerservicehowcanihelp?". You begin to explain your problem and he interrupts you and transfers you to somewhere else. A woman picks up and asks you what you want. You explain your problem again. She tells you that you have to go to a post office and send the package back yourself. Then you need to fax them the receipt and they'll reimburse the postage costs. She needs to refund your money for the jeans to you and needs you to go back to the website, order and pay all over again...

Will you be ordering from here again?

This is experience design. I can delight you by taking full responsibility for my mistake, and ensuring that you not only get your order the same day, but that you also are compensated for the mistake. I can also take into consideration that because I sell jeans, sometimes people will order the wrong size, so I can delight you by not penalising you for it. Instead I will include in every package a ready paid empty mail bag so you can just drop it in a post box and return it at no cost. I might determine that my customers want to experiment and try products they have never bought before. I can create a whole experience around that so that people can select a whole bunch of clothes, we ship them out to you, you try them all on and send us back what you don't want to keep. We'll charge you for the ones you keep, you don't need to go back on the website to do anything.

Delving into your user journey, seeing that this is a single purchase, I question needing to have to add it to a cart. After all in a store you wouldn't grab a shopping cart or a basket if you are about to buy one item. If I wanted to improve on the usability, I might investigate this in more depth. Can I reduce friction even more? If you are a repeat customer, can I remember your payment and shipping details for you too?

Can you see any other opportunities? I'd be learning about my customers as much as possible. Not just about the things that they tell me they want, but also by using ingenious methods to gain insights into the things they never knew they wanted. What are the unarticulated needs? What is my competition doing and how can I be a better? How do I give you a totally kickass experience that you will love and remember? How can I reach you on an emotional level?

If I have a physical store, I'll do more. I'll want to ensure that the entire experience of our brand, be it online or in the store, is always the same kind of awesomeness that you deserve as a customer, or even as a potential customer. What do you think the Amazon physical store would be like if there was one?

The Four Seasons hotels have found a common pattern where people enter their hotel room, throw their bag on the floor and coat on the bed, and then drop into the armchair...and exhale. They refer to this as something like "the exhale moment". You want to savour that moment. They have ensured that everything is in place to make that moment especially amazing. The seat itself, the proximity of reading material and the mini bar...(more about this in Tim Brown's book). Where is the "exhale moment" in your software product? I think it has its place in experience design as well.

Things you might talk about when considering usability:

• Accessibility
• Interaction design
• Layout
• Path to completion
• Funnel analysis
• Time on task
• Eye tracking
• clicks
• ...

In short, you are in the minutia of user interface design.

Things you might talk about when considering experience design:

• End-to-end customer journey
• Personas
• Behavioural
• Real world context
• Scenarios
• Ethnography
• Social science
• Perceptual psychology
• Design Thinking
• Environmental design
• ....

It's a much larger subject area than usability. It involves a lot of diverse and complex skill sets, and requires a solid understanding of psychology, business strategy, design principles, brand strategy...it is cross-disciplinary.

As a developer, you should know all about usability, especially if you are a front-end developer. You should have a fantastic grasp on how to lay things out and know all the rules and how to break them. This is not the sole responsibility of the "UX" person on your team. It is your responsibility too. It's fundamental if you want to create a quality software product. Usability is the responsibility of the team.

The real crux of the job for experience designers is being outstanding at experience design. This does not mean that as an experience designer you don't care about usability. On the contrary, it's one of the keys to success. On the other hand, you should know where the areas of improvement are, how to find out about the ones you don't suspect, know how to benchmark and measure quantitatively and qualitatively, and know the customers. You should know what they want, what they want but can't articulate, what they need from your services/products, who they are, who they might be in future, how to persuade them, know how they behave in every different scenarios, be able to understand if this reconciles with the current business strategy and know what to do if it doesn't.

Where does visual design fit in?

It is fundamentally important to have excellent visual aesthetics for your product. There is plenty of evidence about what a huge difference it makes and I rarely find anyone argue that it isn't. The mistake here is to think that this is the only aspect of design to take into consideration when actually designing a software. When you are designing a service, there will always be visual touchpoints and these need to be cared for as much as any other detail in your work. If the experience is awful like in our jeans buying example above, do you think you'd be more impressed with the service if the website and packaging looked stunning? On the other hand, do you think that you would even consider buying jeans from the website if it looked terrible?

"Design"

It's not "usability design" it's just "usability". Why does this fall to the designer on so many occasions? It is the responsibility of the whole software team to ensure that what they are making is at least usable. It's called "experience design" because it is a practice of design. Design is fundamentally about problem solving. Innovation is a design problem, for example. Design is about solving problems by finding out what they are exactly, and then executing the best solution possible. Jonathan Ive does a lovely job of summing up what it means to be a good designer in this interview. He's an industrial designer rather than an experience designer, but still design is design.

I think that the following quotes sum it up neatly:

"Design needs to be plugged into human behavior. Design dissolves in behavior." -Naoto Fukasawa

"A lot of what we are doing is getting design out of the way." -Jonathan Ive

To conclude, if you are worrying exclusively about what colour that "Add to cart" button is, rather than  considering whether you need a cart at all, and finding out what to do instead...You're not doing experience design.

Wabi-Sabi in Experience Design

Wabi-Sabi, simply put, is the ability to see beauty in simplicity, the ordinary and the imperfect. English is too clumsy a langage to explain it fully, and I am too much of a clumsy writer to do so well, but you can think of them like this: Wabi: The ability to make do with less; A "wabibito" is a person who can make something out of less parts than anyone else. It means content with little, and taking pleasure in the ordinary.

Sabi: The gift of time; To grow old gracefully and with dignity.

Wabi-Sabi aesthetic is also described as "imperfect, impermanent and incomplete". The beauty of those things is found in their simplicity, their unpretentiousness, their humbleness. They are unencumbered by anything unnecessary but not to the point that they look or feel clinical, rather their raw essence alone is left. They are not the center of attention but are unassuming and command a quiet authority. Wabi-sabi isn't just about the aesthetic though. It's also about the object giving you a feeling of serenity and having a connection to the object.

"Pared down to its barest essence, wabi-sabi is the Japanese art of finding beauty in imperfection and profundity in nature, of accepting the natural cycle of growth, decay, and death. It's simple, slow, and uncluttered-and it reveres authenticity above all. Wabi-sabi is flea markets, not warehouse stores; aged wood, not Pergo; rice paper, not glass. It celebrates cracks and crevices and all the other marks that time, weather, and loving use leave behind. It reminds us that we are all but transient beings on this planet-that our bodies as well as the material world around us are in the process of returning to the dust from which we came. Through wabi-sabi, we learn to embrace liver spots, rust, and frayed edges, and the march of time they represent." (Tadao Ando)

Wabi-sabi in Life:

I've always loved the wear on my beloved denim jeans and old shoes.The wear on my moleskins that I dragged around the world with me. My cherished old family photographs, yellowing and frayed at the edges. Our old children story books from when we were small. I love asymmetrical things and simple design. I find magnificent beauty in less. I found joy in fewer possessions, less waste, big passions, being in nature and an uncomplicated life. Not striving to have it all and not trying to predict what my life should be like next year or next month or next time. Learning to be content in the present, and finding enjoyment in every day things. Wabi-sabi exists in my life, and I wager that it has its place in yours too.

Wabi-sabi in experience design and Lean/Agile teams:

As experience designers and as members of Lean/Agile teams, I think we are very Wabi-Sabi in our work:

• Our work is never finished, and so always incomplete
• We try to fail fast
• We try to limit waste
• We never release anything that is perfect
• We try to keep our experiences simple and unencumbered, without losing the humanity in them
• We strive to keep them subdued and honest
• The work we do will always evolve and age, and we will work with the downsides of design decisions we made earlier
• We never do "big upfront design", so our worldview is ever-changing and intuitive
• Our emphasis is always on working code and not on beautiful looking documentation. In this sense each artefact is one of a kind
• We know that our design will evolve, so we think about the present moment rather than projecting far into the future
• We work in iterations, in an organic way
• We adjust to change easily and avoid deliberations
• If we can do it with less, we do
• We pay attention to the ordinary (all those habits people develop to deal with bad design)
• We ensure our software "fails gracefully"
• Users "wear in" our designs and their relationship with the product changes over time
• The more people use our designs, the more they connect to them (like your relationship to your email account)
• We reuse code and design elements where we can
• The team has a history and a shared knowledge that seeps into the product

Resources:

BERG London have a beautiful blog post written by Tom Armitage on Wabi-Sabi right here.

Leonard Koren wrote a book called "Wabi-Sabi for artists, designers, poets & philosophers".

Marcel Theroux discovers Wabi-Sabi through the experience of the Japanese tea ceremony: "

15 things Ray and Charles teach us

There's an awesome essay by Keith Yamashita called "15 things Charles and Ray teach us" (PDF), that I found via SwissMiss. I wanted to share it with you and summarise the 15 points here for those who don't have time to read the whole thing, but I encourage you to have a gander, because it's really beautifully presented and well written. I've applied the 15 points to experience design of course :) 01. Keep good company

Surround yourself with other awesome people, it will inspire you. For us experience designers it means brilliant people from different backgrounds, areas of expertise, industries...Making the effort to get out and meet them, and spending some time learning and sharing.

02. Notice the ordinary

Notice the simplicity in people's desired interactions and design them in that same way. If someone wants to drag and drop an item with a finger, don't make a complex dropdown menu. Use patterns that work well and are familiar to people where appropriate, so the learning curve stays manageable. Don't over-design things, keep it simple.

03. Preserve the ephemeral

Don't be afraid to design something that will work for a while and then be replaced by something new. I keep notes on things that I made to serve a purpose for a little while (lean start-up style), and then replaced and redesigned as I discovered more about the user needs. Those things in turn get redesigned again. As the user's relationship with the software evolves, so should the design. In the same vein, keep note of fads in experience design. They reflect a culture and a need at a certain time. There are interesting patterns there.

04. Design not for the elite but for the masses

Design things that will work on all sorts of devices, make your designs responsive, and cater for all kinds of connection speeds. Make your interaction design easy for most people to grasp, and allow your visual design to tell a story that many will appreciate. Ironically, observing extreme users will help you identify needs not so easily spotted in the average user. The designs you craft as a result will delight the majority of users.

05. Explain it to a child

In the same way that toddlers are able to pick up an iPad and use it immediately, your should strive to design software that is so simple to use that even a child could pick it up. I think this can apply to accounting software as well as games and anything else. This is not to say that it is designed for children, mind you. Your product/service/process ideas be solid enough that you can explain the essence of them to a child and have him/her understand with no difficulty. In fact you might get some pertinent questions!

06. Get lost in the content

Reach out to subject matter experts, read up on the new industry you are designing for, immerse yourself in the needs of users and the lives they lead...understand what their world is like, how it looks form the inside of their world, and what they aspire to. Understand the technology, speak to developers, try it out.

07. Get to the heart of the matter

Make sure you are solving the right problem, and articulate it clearly and concisely. Don't make documentation for documentation's sake. Just what you need, when you need it, aimed at the correct audience, and get to the point swiftly.

08. Never tolerate “O.K. anything.”

Fight for great design, in your work and in others too. If you are working in a lean way, ensure that your product is a great MVP, not an ok one. "Just enough design", does't mean "ok design". If you think something isn't good enough, that it could be better, say so.

09. Remember your responsibility as a storyteller

Collect user stories, tell them in a convincing way, either through role-play, customer journeys, a video clip,  presentations, illustrations...Tell the story of the design clearly, and in appropriate detail. Get good at storytelling. Read up on this and practice, it's a really useful skill.

10. Zoom out

Never fail to see the big picture.

11. Switch

"Never get Bored". Don't restrict yourself to designing websites, apps or whatever. Expand your horizons and apply your skills to whatever you can, whatever comes your way. Design a garden, a process, a book, a shop,  a shoe, a room, a city, a bus or a spoon. Anything.

12. Prototype it

And early on.

13. Pun

Have fun. Play on words, play with ideas, with software, with images, with objects...can you use something in an unusual way? Have fun for fun's sake and share it with others.

14. Make design your life… and life, your design

It is awesome when you are lucky enough to find a career path that you love so much that the line between work and play ceases to really exist anymore. I think that's when you can say that you're in the right job. Make your own design for life, your own philosophy, and live it.

15. Leave something behind.

Our work lives through the people we work with, those who use our products, our clients, our friends. Beyond our craftsmanship, we should have the kind of positive presence that allows everything we stand for to emerge and remain once we have gone.

8 qualities of great Experience Designers

Designers of all kinds, in particular experience designers, come from a variety of backgrounds. They are different in many ways, and will always disagree with each other to some extent (minimalism, Helvetica, logo size...the list is long) but great designers have a number of qualities in common. I am fortunate to know a bunch of really brilliant experience designers, and was thinking about made them so great. I found that I could distill that into 8 main qualities that they all have in common.

 1. Discipline

To engineer a great design you must have great respect for all of the rules, and break them when they need to be broken, not just because you can. You also need to continuously learn about new interaction patterns, seek out interesting designs, and read up on up and coming methodologies in all areas that touch experience design. Working on your project alone will teach you more than you knew before, but won't be enough to sustain you in good ideas for long. Great designers are always seeking out the cutting edge of their discipline, and spend many hours reading, learning and practicing.

2. Ritual

It can be tempting to cut corners when you have designed something a thousand times before. It's important to keep the rituals in place, and keep looking for a new way to do something, question everything until you are sure that it has a legitimate place in your design. Explore, find inspiration first, then ideate and find a solution. Don't get sloppy.

3. Craft

You must be attentive to the details, check your design, and communicate it effectively to the team.  Wireframes should be clearly annotated and thorough, assets should be high quality, the end product should be excellent. You should be a master of your craft, at every stage of the design. This means that you need to identify any areas for improvement and actively work to get better at them all the time. The craft of experience design goes beyond deliverables such as wireframes, sketches, interactions, and so on, but also includes facilitation skills, communication skills, presentation skills, diplomacy, and more.

4. Awareness

This means awareness of new technologies, design patterns, trends and so forth, but also awareness of the current project space. You are never designing a noun (an app, a shopping website...) you are designing a verb (shopping, discovering, enjoying...). Ensure that what you think you have been asked to make is really what the business and the users need. Make it your business to be aware of the full implications of what you are designing (does it impact the world in a positive way?). How is the evolution of the design being perceived by others? Are your stakeholders scared of your unusual design? Be ready to explain, show, convince at all times.

5. Introspection

Take some time on each project to be alone. Even on a fast Agile, collaborative team. Even if it's just 10mins. On every project there are a lot of people to listen to and work with, from people in your team to people who will be using the product once it's made. I noticed that great experience designers take a little time alone on each project to think slow. Everyone I have ever met has an opinion on how a design should be. Has a decision been made because it's easier to agree and move along, or was it legitimately thought through? Do you really agree with the decisions that have been made? Are they really for the best?

6. Focus

Decide on what the end goal is for your design at the start, and focus on making it happen. This saves you from adding in unnecessary features, trying to design for too many needs, and making something that is a complicated Swiss army knife rather than a slick, easy to understand design. Define your design language and stay with it. Go for a colour or a set of principles and stay with them. It is important to be able to pivot and change course quickly, but it's also important to focus long enough on what you're doing so this can be sensibly judged.

7. Commitment

At the start of a project there is always excitement, everything is new and shiny, full of potential. As you make your way on the path to completion, the best designers enthusiasm remains high, and they continue to commit themselves fully to the work. While we all have ups and down on projects, and it's important to acknowledge that there are low energy days, we still need to give ourselves to the work fully each day. Beware of situations where you have more than one project on the go, and be quick to voice any problems you see up ahead. It's all too easy to commit to more than one project and then see all of them turn out mediocre. This will exhaust you and you won't get the satisfaction you get from doing great work. Don't muddy the water. Dieter Rams during his whole career has been committed to particular principles of design. Do the same, even if your principles are different.

8. Love

If you don't love the work you are doing, if you don't love the act of designing, you will never truly do any great work. It's really difficult to be focused and committed to something you don't genuinely have an interest in. All great designers of any ilk really do love what they do. If you don't, then find what it is you do love and go and do that. There's nothing satisfying about being mediocre at your job. Pure love for what you do is a nourishing thing, that helps you grow as a person and drives you to want to improve and break barriers. It lights up your life. There is a real blur between what is considered "work" and "play" when you love what you do.

An Experience Design Manifesto

 Thanks to Lizi Hamer for all the help and for letting me steal off her! I learnt lots along the way.

"I believe that all software should be designed, using a human-centered approach. Interactions will be obvious, seamless and pleasurable. I will not refer to you as an "end-user" but as a full person, a participant in the software's story. I will fashion experiences for you that do not degrade you, and that allow you to engage with our work in an appropriate manner. I will endeavour to measure the success of our software, not solely based on hard metrics, but also based on your own evaluation of it. I know that you do not necessarily perceive the world in the same way that we do, and I will do my utmost to be mindful of not inflicting our subjective experience of the world on you. I believe in sweating the details, so that you don't have to. I believe in setting a consistent design language, so that you can feel comfortable quickly. If I can do it with less, I will. I believe in ensuring that our software fits seamlessly into your day and life, by remembering that it is not the centre of your universe. Finally, I will ensure that everyone on my team is aware of you, and that they are mindful of your needs and respectful of your time and energy".

Marie-Claire Dean

Pairing for designers (Agile)

  It's important to collaborate because it allows the team to become a powerful unit, full of common knowledge and questions. Each individual has a clear view of what is going on and has the power to affect the product direction and evolution. If as a designer you do not collaborate with the rest of the product team, you essentially deny yourself this right. By pairing with the QA, (front and back end) developers, BA, PM and anyone else who is part of your team, you gain all of the necessary perspectives on the project to really understand the product you are making. You should ideally always be working with another person and never alone. This allows the team to cut out a lot of time draining and uninspiring inter-team formal communication, and actually focus on the product.

More importantly, the design then belongs to the whole team, and is no longer treated like a sacred cow.

How to pair with a developer:

You will need a whiteboard and a few whiteboard pens, a shared screen and a mouse and keyboard between you. Use the whiteboard to communicate your design ideas, and work together on solving design problems that crop up and technical problems that you encounter as well. This way you are designing that is feasible technically, every single time. You don't have to have meetings about the design, where you show wireframes or photoshop files. You don't have to have talk about possibly trying this or that to get over a hurdle....you can just do it right now, together. Experience design needs to be user-centered but also technology centered. Weirdly enough, a lot of designers forget the latter. If you need you need to make something in photoshop to go into the design, then do it together and then make it into working code right away. Working this way is a LOT of fun and the product that you are making comes to life quickly. Your client will be super happy because you have made something tangible in record time, and you now have something that works to put in front of users. Yey!

It is tough though. Be prepared to sweat. As a designer you have to know your job well enough to do it on the fly with little preparation. You have to let go of perfectionism and aim for a minimum viable product that still fulfills your user needs. Remember that you will iterate. Better still, because you have a working product to put in front of users really quickly, you can include solid feedback in the next iteration and not make all those features that nobody ends up using.

Why you shouldn't code (even if you can):

The whole point of pairing is that you can share the load together, and bring a wealth of expertise and experience to the product. Imagine that you are designing a login screen. It's always useful to start with the action, so tell your programmer pair to make a login button. While s/he is focused on the button, and on the minutia, you are focused on how the entire design hangs together across the whole product...all the other screens that you know about, and all the design decisions that you are about to have to make. You are the big picture person and the other is the small picture person. If you are coding, you will pretty much only be focused on that button. While that button is being made, maybe you are drawing out the login interaction on the whiteboard and the next screen.

Where to start?

"Build what you can with what you know" is the slogan I like to use. It is tempting to want to get all of the information about everything up-front, but the reality is that by actually making something you put yourself in a better position. You can modify, start again or carry on the next day. Iterate. remember that there is never really such a thing as an "End product" because if it's any good, it evolves and there is no end. The more you think about it, the more the whole team thinks about it...the more it is misunderstood by the team. Everyone forms their own assumptions and ideas of what it is and how it works and what it looks like. It all becomes more like a field of dreams. Sometimes we even agree as a team, whilst all thinking we are agreeing to whatever we each have in our heads. Actually we are more confused than ever before. Keep it tangible. Make the product now and keep making it. When you talk about it, point to it. Everyone can see what it is, what colour it is, what shape it is and how it works. It couldn't be clearer. All of your focus should be on your product and not on your process. Show your work often to your client, and let them use what you have made so far. It makes for a better conversation than a meeting that refers you to wireframe 180(a).

But what if it's all wrong?

Throw it away and start again. You are throwing away some code, that's all. This is far preferable than the potentially huge cost of  a design lead time (where developers are twiddling their thumbs waiting for you to come up with a design). You may have made some mistakes or maybe yes, t is all wrong, but by collaborating you now have shared experience as a team, you have learned to make something together, and you have probably alos won client trust because you have shown that you can make something that works in a morning rather than a week or month. Even if it is wrong, you have failed fast and learned something valuable from that experience. The team will be a lot closer. You will share your valuable design knowledge with team members and learn things from them as well. You all win. A lot is to be gained from jumping in and making something that is wrong rather than spending a lot of time making nothing, trying to fill in all those gaps (we talked about those in the last post). At the end of the day, you might find that you have pursued 3 different approaches and made all of them in the same time it would take to go away and wireframe everything meticulously on your own.

What if you have layers of management to get approval from before you can make anything? 

Working in an Agile way requires the client to work closely with you, so that you can make decisions quickly. If your client is very removed from your project, then it will be hard to be Agile. You will have to make documentation that gets sent up the management chain for approval and this might take some time. In this case, you have fallen into a waterfall. Fear not though, this is fine. As a good BA friend of mine says: This is exactly the situation for which waterfall was designed for". If this is not the way you and your team want to work, then you need to have a chat.

How do you ensure that the product remains user-centered and ends up being right?

If you are in an Agile environment, you need to ensure that while you are making, you are also discovering and learning how best to evolve your work. The diagram below shows that you should be focusing all of your energies around the product. The further you are from actually doing code (making), the further you are from the center of the concentric circles. Tasks on the outer rim might include user interviews for example. That isn;t to say that these tasks are less important or devalued, they remain deeply and crucially important, because they give you direction and ensure you make the right thing. Anything in between the outer disc and the inner one are things that...we...fall in between. To ensure that you are not just blindly making or lost in a world of research and no making you should be working on tasks on the outer and on the inner discs simultaneously. The stuff you do in between is up to you. Additionally I split the whole thing into examine, define, create, verify. Most tasks will see a full revolution.

To finish: Cultivate Li:

Jade cracks along its natural contours, which adds to the artistry in working with it. Jade carvers incorporate the breaks into their work, bringing into evidence the natural elegance and great beauty of these lines. They are said to rely on the stone's natural "Li". Each and every project has its own "Li". Allow it to be there and learn to work to turn all of the challenges into something beautiful in the end. Take advantage of them. Drop the fear and the resistance, trust the integrity  and capabilities of the team. It takes more than just your immense capacity to make logical decisions to succeed. You need to be invested fully so that you can trust your instincts, trust your heart and trust your gut. (More about "Li" in this excellent book: "Awake at work")

What is an "experience designer"?

Here is my brief attempt at describing what it is some of us do. Emphasis has been placed on simplicity of message.

Tangible wireframes: "the wirefoam"

The Situation:

Designing in an Agile development environment requires transparency, clear communication and frequent delivery. Teams will work in sprints (typically 2 weeks) with a focus on making software rather than documentation. Wireframes are useful for designers to work out interactions, potential pitfalls, communicate design ideas, and are very useful to the development process. They are a visual representation of the layout of features and content of a user interface or website, and I would also add, in many cases how things in it get used and behave.

They are however considered documentation, and we should always prefer working code over docs. This means that it's not going to be very efficient to lock the UX team away for a few weeks to design a whole load of stuff that the development team can't actually build, because of limitations and restrictions. These can be technical, or financial, or even related to resources available amongst many things. The planning of the user experience might be awesome, but it's useless to user and the stakeholders unless it is functional. Although this is true, it doesn't mean that there isn't a place for them and that they shouldn't be used. There are more efficient ways to make use of them and get answers quickly, rather than how they are traditionally presented.

The complication:

As experience designers we are often not the ones to have total sign off on the end solution. A lage team of people will have a say and add their 2c before anything is signed off to be developed and later, deployed. It's time consuming to get round to presenting ideas to everyone, it's hard to get all the relevant parties in a room together because they're inevitably very busy, and it can create a lot of extra work as well (collecting different team member and stakeholder concerns, needs and ideas). Additionally, presenting on a screen, although it gives everyone a good idea of what you're talking about, can fail to get the message across. The reason for this is that a wireframe does not look like a finished product, and is static. Even if your wireframe is an interactive Axure prototype, it's still a picture. It isn't as engaging as as it could be and isn't easy to use in a collaborative environment.

"Plant a seed, grow a tree"

Often, we will not launch the final version of a software feature, but a functional version, designed to be improved on and evolved. This is very useful to us as experience designers, because we get a chance to collect live data and user impressions on the stripped down functionality before adding bells and whistles. This means that we add the bells and whistles that are actually required by users, rather than guessing what may be best in advance. A stat that gets thrown around a lot is that 80% of users use 20% of features. All those extra bits appear like a barnacle effect over time, the more people get involved and the longer you have in my experience. It's good to start with just what is needed, before discussing any further features.

A resolution: tangible wireframes

Instead of showing your design on a screen, even projected onto a wall, make it tangible. It's pretty easy. All you have to do is print it out, stick it on some foam board, and then use a box cutter to make it into jigsaw-like pieces.

For your team:

Stick some blutack on the back and stick each feature up on the wall for the whole team to see. This allows people from your team to come up and move things around to get a feeling for the experience. You can stick up some poster sized paper up there too and allow people to write their thoughts, ideas and concerns up. I have a separate one for technical concerns.

For stakeholders:

In a stakeholder meeting, you can bring the "wirefoam" along and introduce each feature bit by bit and pass it around the table for everyone to have a good look at. The fact that they can hold it and piece it together with other bits will make it an easier, more productive conversation. On the back of each piece of wirefoam, you can write down the name of the stakeholder who requires the feature, and for what reason. This is particularly useful for forms for example. Taking a piece of wirefoam off the table and putting it back in the bag (or even the bin), is a very effective way of moving the conversation on to the next thing, now that it has physically disappeared.

It's also quite good fun, so you're likely to have happier people around the table and more interesting outcomes from those meetings! It's easy to add and take away features. It makes it easy to role play interaction. It's a great documentation tool, because you can take photos of all the different combinations of pieces that people come up with, or show how it evolved for example.

Have fun :)

ROI of UX

photo credit: baldiri The scientist in me is always trying to measure everything, trying to find patterns and insights, trying to quantify and accurately qualify...It's no surprise that the ROI of UX is a topic that has been on my mind for some time now. Business people understand numbers and I learned that using them in ways they understood often won me time or budget or both. I'm working on various ways to measure the effect of the UX team in organisations, mainly because it would help us not only understand its value but also clearly see any bottlenecks. I would like to speed up the UX process, but in a way that greatly minimises risk. If you speed up a process, and decide to spend less time on certain things, there is always going to be a trade-off. I'd like to be able to accurately say by what percentage we traded-off, and what the effect of that was.

Agile and UX:

There is a lot of debate at the moment on how to integrate UX in an Agile development process. I think the key to that is live site/software metrics, remote user testing, and more metrics. I think that to include UX in the Agile process, you have to also favour working software over documentation, same as in any of the other disciplines in our teams, like QA or BA for example. This means pairing with a Dev and getting things done immediately for low risk features, is preferable to drawing up wireframes. It means sketching with a pen and paper, and updating those sketches during feature meetings, with other team members and stakeholders. Draw it and hold it up for everyone to see: "This is what we're talking about".

If you deploy features without doing live user tests, you can still check how well they're doing by analysing the analytics on the live site. This is why it's so important to have sophisticated analytics, beyond Google Analytics and other free solutions. Just so we're clear, I don't recommend doing this for innovative solutions, but rather for things that the team already has experience with (i.e. How many highly innovative contact forms have you designed in the last 10 years?).

There will be a trade-off, but if we accurately measure how effort, time, and so on are affected, we will have an idea of how well this method worked. If we have no idea of how productive the UX team is, or what the value of their time is, we are essentially working blind.

Measures:

Before you even begin thinking about design, I think that it makes sense to agree what the ROI is for different stakeholders. It can be different for different groups involved in the project, and you might not be able to please everyone every time. Keeping tabs on which way the balance is tipping is really important.

Hard measures might be:

- Conversion / Acquisition

- Lead generation

- Retention

- Traffic

- Viral referals

- Employee productivity

- Cost savings on Dev etc...

- Decreased time to market

Soft measures might be:

- Engagement

- Customer / User satisfaction

- Brand loyalty

- Product/service adoption

- Awareness

- Ethics

- Team morale

The value of UX:

For every $ invested in UX, there is a ROI of $2 - $100.

The UI accounts for:

- 47%-66% of the total project code

- 40% of the Dev effort

- 80% of unforeseen fixes required

An equation might go something like this:

Value = (Benefit - Cost ) / Cost

This can shed some light on what the ROI is, once the cost of the team has been taken into account.

In conclusion:

If we can measure the exact ROI of UX, we can demonstrate the value of the UX team, their work and also justify the need for research when it is necessary. Often the complaint around UX is speed. We can speed up the UX process by sketching, measuring features when they are live, and evolving our designs rather than working to create a final and highly polished version at launch. We can calculate the trade-off of using this faster deployment method rather than the more traditional process of doing lots of user testing up-front. There will be times where it isn't appropriate, and knowing the numbers allows us to justify this to the business. A caveat for the faster deployment method is that the UX team must be very senior and experienced.

I liked Dr. Susan Weinschenk's video about the ROI of UX, enjoy!