User Centered Design is not broken

There's been a huge amount of discussion in the last few years on the topic of User-centered Design (UCD). Many have been saying that it's broken and never worked, that it limits our work as designers, that it is harmful (this is really great read btw).

Harry Brignull wrote a good blog post called "Is user-centered design broken or is it us?" exploring this discussion a bit further and raising some questions. I agree that this is starting to sound a lot like the "Agile is broken" argument that has been around for years. I think that the problem stems from people needing a particular recipe for success and following it down to the letter. I've always said that the Agile Manifesto is non-negotiable, but that how you implement it is really up to you and will and should change according to the circumstances. The same is true for UCD.

UCD is fundamentally about knowing who your end-users are in great depth and detail  and using that knowledge to inform your design. It's a problem solving process that requires you to check your assumptions and validate your ideas with real users. The process is basically Think - Make - Create - Evaluate (sound vaguely familiar?) At first you go for divergent thinking and bring a preferably cross-disciplinary group, with users at the heart, to convergence. It's a widely used method, and Harry ponts out, it's a process not a fairy-godmother. Amazingly successful designs do not automatically pop out the other end. Those things take a whole bunch more than just UCD or any other kind of design process.  

Frankly, UCD and ACD for that matter, are just common-sense to me.  I have no idea why you would want to design any other way if you have the right circumstances for those. We have all been in a scenario where our years of experience and our vast knowledge about some area will mean that we can do "Genius design" and just make the thing already. In this case, I am always 90%+ sure that it will will work because I've done it before in very similar circumstances. Of course, I'll still test. Why would I prolong the process though?  

In many other circumstances, I don't know what the outcome should be, because maybe I'm designing software for Alaska crab fishermen. I have never fished or been to Alaska or met any of these kinds people. I wouldn't have the first clue what they needed. In this case UCD serves me well, and so does ACD. It never occurred to me to separate them out and use one over the other. They go hand in hand in my design at least. One inevitably leads to the other. None of the design methodologies are broken, they're just misused and misunderstood. 

The biggest misunderstanding I bump into almost every week is the notion that testing with 5 users is enough. It isn't always true, in fact most of the time, it doesn't work. more on that in this post. Saying that because you tested with 5 users and got misleading results, then user testing is broken is sort of the same as saying UCD is broken because you didn't know how to use it. 

Personas is another huge stumbling area. Making up personas to try to make your team more emphatic will work to some degree...one could argue that it's not empathy that you're eliciting but sympathy mind you. These Ad-hoc personas can be useful when used with great awareness of their limitations. All too often, they become law and everyone forget that they were made up. Data-driven personas on the other hand are hugely beneficial. They are the result of extensive user research, more likely than not 100's and 100's of user interviews, surveys, data points...all distilled into one persona, or a library of personas. Which way you slice the personas is really crucial. Don't slice by role, characteristic, or demographic...look for the patterns that are emerging from your research. This is the catch, you'll only be able to se them when you have enough research. Personas aren't broken because most teams don't have them, have no idea how to use them or can't see the point in investing in the research.

Those who are really great designers are amazingly creative problem solvers, and are so familiar with all the tools and methods, that they instinctively know what to use and when. They supplement that with a double whammy of experience and talent, and don't get hung up on process. In fact, they deviate all the time. They're good enough that they know how to and when to break the rules.

Are there senior designers out there using one design methodology and never diverting from it, doing the same thing every time they are confronted with a design problem? I don't know, but it sounds pretty dumb to me.

Not everything requires a hammer. If all you have is a hammer, then you better learn to use it in unconventional ways.

photo credit: Buzz Hoffman via photopin

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: "

Take the pain out of failing

A lot of us have the joy of working in Agile environments and have all read, heard and learned that you should "Fail fast and often". The idea is basically that if something isn't going to work, it's better to find out as soon as possible, and learn as much as we can from it so that we can move on and focus our energy on something that will work. It doesn't mean that we set ourselves up for failure, quite the contrary, we try to do everything we can to ensure success. The problem is that if you are working in an innovative space, or say, in a well defined space that you're looking to disrupt, it's hard to guarantee success off the bat. What's interesting to me, is that we don't like to fail. I have yet to meet someone who really relished in this. I know a lot of people who can see the value in failing, and are comfortable with the fact that it will happen and that we will learn good stuff from it. I don't see anyone celebrating when it does though. People swear, wring their hands, shake their heads, some even cry. But  I think we should celebrate. That we didn't get to where we intended to be is not important. We may well have been striving for the wrong things, or looking at it the wrong way. It was not going to work and we found out early. Surely this is good news.

The idea I think, is to focus on going forwards, without being attached to the outcome. The pain, the anger, the fear, the emotions that are so often felt during failure are those that come from that.

If we can be excited about the journey, about what we are actually doing rather than where we are expecting to end up, then we can really let go of the attachment to the outcome and enjoy this unique process. The beauty in this is that when we do succeed, the outcome is a true celebration rather than an expected situation that we take for granted.

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")

SxSW workshop: Agile Experience Design

As some of you know, Cathie Hagan, Megan Cook and I recently ran a workshop at SxSW entitled: "AXD: Agile Experience Design". This was a good mix of skills, as Cathie is from the BA practice and Megan is a bit of a hybrid between BA and XD.

What we did:

We were allocated a 60min slot to run a workshop on Agile Experience design. There was a diverse audience of designers, developers, managers and company owners. Some were familiar with Agile, many were not. We wanted to teach some fundamental principles of design in Agile teams and to allow people to experience it for themselves.We designed the "Play Doh Zoo" game (inspired by the Lean Lego game).

We split people into teams as they came into the ballroom and then those teams were split into construction workers and designer/planners. An extra group represented the customers. We prepared packs for each team full of play doh, pipe cleaners, pop sticks, tape and more tools. We gave them foam boards to build their zoo on. We used whistles to signal the end of iterations, and we led them through a retro highlighting the learnings we wanted them to take away. We will post more information about how to run this game soon.

Roy closed our session with a stirring and inspiring speech and you can see his notes here. It definitely inspired the crowd, and helped people see that we are much more than just another software consultancy.

How it was received:

As the whole ballroom descended into chaos, I was quite sure that we had pulled it off. A client tapped me on the shoulder and told me with a wide grin, that this is exactly how it feels when we come into their workplaces. People were running around, fully engaged in the game, and shouting enthusiastically at each other.

Lots of people came up to us at the end and said that they really enjoyed themselves, and that they learned a lot. It's clear that it would have been great to be able to do an hour Q&A session after the game, as we spent at least that long answering questions. A couple of people felt that we didn't give time to answer their questions and some were disappointed because they thought this was a panel, although it was clearly listed as a workshop. You can't please everyone, and we take this on as feedback that next time it would be good to also run a panel at SxSW.

How we would do things in an ideal world (briefly):

Agile is about continuously evolving your product, this is BOTH delivery and design. You need to build what you can with what you know. That is, start with some of the known areas, use your design patterns. For instance, registration forms are a well know space use the best practice here, get the team working and spend your research time and energy in the truly innovative areas of your product (hint this should happen in parallel).The key is getting the product out as soon as possible so you can validate that what you are actually building (rather than conceiving) is the right direction.

The benefits of this approach are many. Firstly you can validate your direction. Secondly your client (product owner) is happy because they achieve ROI earlier, and they can really see the product evolving, rather than less engaging documents they can play with the real thing. Finally your team will be happy as they will be able to start making them feel more confident that they can reach their deadlines and more engaged.

The other important point is to be collaborative while design. Not just with the business stakeholders either, make sure you can include your team. The developers will invariably have a deeper product knowledge than you and their fresh perspective may uncover fresh opportunities that would have never been thought of without their inclusion. Also collaborating is the easiest way to to get buy in, as the design becomes communal property rather than seen as something imposed.

For a good impression of what we did, take a look at Adam Kleinberg's excellent write-up.