Skip to content

Balancing the creative exploration process and Agile Leanness

January 28, 2011

Having been working in an Agile & Lean environment since I joined ThoughtWorks, I have well and truly drunk the kool-aid. Working in a team where a working prototype is preferred over comprehensive documentation has meant that I can optimistically hope that I will never have to annotate another wireframe again. The freedom from never-to-be-read documentation and the rapid speed at which UX work can be done when given this freedom is invigorating.

However, all is not perfect in paradise, I’ve encountered a few challenges in this new utopia:

  • Explaining to Devs that lo-fi prototypes are more a communication tool and than a finalised deliverable
  • Finding a balance between being Lean and following the creative process of exploring alternative ideas and solutions
  • Being allowed the time to go through the creative exploration process, when a Dev team waiting for to you to finish so that they can start.

Lo-fi prototypes are not a final deliverable

Working in an Agile team, the role of a UXer becomes about leading the team on a journey to find and build the best solution. “Big Upfront Design” is a dirty word and throwing deliverables over the wall usually results in something being thrown back at you (with stuffed toys seeming to be the objects of choice by Agile dev teams).

There is still plenty of user research, analysis and UI/interaction design done along the way, but it is the thinking that is done together as a team that is important, not creating in a shiny, polished deliverable at the end of it all.

The problem is that despite my love of going documentation free, I’ve still encountered resistance from Devs. While they don’t like big shiny design deliverables, they can be just as sceptical about the rapidly produced paper prototypes. While we are philosophically aligned on a documentation free, collaborative approach, there is still scepticism about the practical methods. I’ve spent many hours arguing about the use of paper sketches for prototyping when someone could ‘code it in the same amount of time’.

This problem that was nagging at me, until I came to a moment of clarity recently when I read The Problem with “Iterations”:

To developers, “iteration” means incremental release of working code.

To designers, “iteration” means a chance to do something again.

The mindset for Devs is that each iteration builds upon the existing code base. Once written, code is an asset that has a monetary value. Therefore you would be crazy to throw it away. That would be a waste of the time you just spent on it.

For UXers, each iteration is a chance to explore an idea, try it out, put it in front of users, learn about its strengths and weaknesses, discard the bad bits and build upon the good bits, and potential discover new breakthrough idea.

By using non-production quality tools such as paper it becomes throw-away. You know that at some point it will be discarded so you don’t become attached to it. Thereby allowing more creative freedom to explore the idea with it.

This is why we use paper/lo-fi prototyping. It’s a way to do it quickly and cheaply. It’s part of a process of getting to the solution. It’s not a final deliverable, but a communication tool that can be used to capture the learnings from one step of project (design) and take them in to the next (coding).

The key to using them effectively is to not throw them over the wall. There shouldn’t be a wall at all. Working in an Agile team, the role of a UXer is to lead the team on a journey to find and build the best solution. Done well, UX design is collaborative and inclusive. Every team member and stakeholder has a valuable input in collaborative design.

Allowing time for the creative exploration process

We view UX design as an iterative process, which is to be repeated and improved with each iteration. We expect and embrace the idea of Failing-Faster and incorporate it in to our work practices.

Similarly, an essential part of the creative process is to try a design idea, explore and play with it, and then see where it takes you. Sometimes it can lead to a breakthrough idea, sometimes a dead-end. You never know what you will find until you try, but chances are along the way you’ll learn something that leads a better end solution.

In collaborative design workshops I always have to stress that there is no such thing as a bad or stupid idea. Yes, they might be completely unrealistic as a final solution, but often it’s talking about the crazy ideas that inspire the best ideas.

The challenge becomes being able to secure the time to do this creative exploration.

Taking the time isn’t such a problem if you’re working on a new product that doesn’t have an entire company supporting and working on it. However, if it’s an existing product that has been designated “X” amount of time to do a “design refresh” the product managers are less inclined to follow a UXer down a path of exploring possible alternatives for that elusive UX breakthrough. Deadlines and launch dates are always the number one enemy of UX design time.

Balancing Leanness & Creativity

I’ve surprised myself by just how much UX methodologies can be paired back to basics and still be effective.

A significant amount of time can be saved by doing the thinking together as a team on post-its on a wall. It can then saved for posterity by simply photographing them and leaving them there (it’s also a great way to make a collaborative team space).

Research can be conducted, analysed and personas can be created in a matter of days if you have a team working together collaboratively in a war room, and you aren’t concerned about having polished deliverables at the end of it.

It’s easy to be a UX purest and insist on rigorous methodologies, but at the end of the day, doing the most user-centred design you can in the time available is better than not doing any at all.

The challenge has been to find the balance between being Lean, while not compromising the creative exploratory process at the same time. It’s always frustrating to complete a heavily time-boxed project, only to be left knowing that you could have produced a much a better if only you had a time to do another iteration.

So what are the solutions?

  • Engaging stakeholders and the Dev team: Get them involved in the creation of the alternative ideas in the first place, then they’ll be bought in to the ideas and insist of seeing them explored. Collaborative design and sketching sessions are an invaluable tool for this.
  • Rapid production: Ensure that you have the production skills to quickly sketch/create your ideas. Know you’re preferred tool(s) and make sure you use it effectively without getting caught up in deliverable fetishing*. Create a conducive workspace, put your headphones, find your flow, and start cranking out some ideas.
  • Lightweight research: Skip the formal research techniques and go guerrilla. Be as lightweight as possible. Run three research sessions every Friday, if not more often. Make sure the design & dev team participate/observe the research directly and put those insights straight in to action in their work, rather than having to wait another week for the analysis and write up to be done.
  • Rapid iterations: Combine your rapid production skills and lightweight research together to get through iterations quickly. The more the better. Don’t get caught up on formal processes. Design, test, learn, and repeat.
  • Manage expectations up front: Don’t promise the world. Be realistic in what you commit you. But most importantly, explain the process and what the expected outcomes are. For most stakeholders, UX design is a mystery that seems like a combination of snake oil and magic. Open the kimono, explain the process and most people will be most receptive to the end result.
  • Don’t be scared to ask for more time: Negotiate up-front to get space in the project plan for some exploration. Have resources planned accordingly. Be firm on getting that extra bit of time you think you might like to have in an ideal world. One week can make a massive difference (1-2 iterations) when it comes to working through an idea. Don’t cut yourself short just to try to appease you project manager. Half-way through the project, if you really think the solution needs more time to be thought through properly, ask and fight for more time. Requirements change as new learnings come to light. Sometimes you find out that a previous assumption was flawed and needs to be re-considered. You’re better off addressing problems early before they become baked in to the product, it is cheaper for the company in the longer-term.
  • Be disciplined in sticking to your own timelines: If you need more time, ask for it. If not time-box. Do whatever you can in the time you have. It is an important skill to learn how to build a base solution that is achievable in the time you have, and then be able to flesh it out more if you end up with some breathing room. Don’t be overzealous in your goals. Start simple and then build outwards.
  • Communicate the progress: Do regular Friday showcases to keep stakeholders up to date and aware your progress – fast or slow. This is a key tool to managing expectations.

* Deliverable fetishing: To excessively tweak a deliverable in search of pixel perfection to the point where you move past just an attention to detail and begin wasting valuable time.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: