When my colleague Patrick Goffin wrote his recent (Fr)agile blog post, it sparked some lively discussions here. What was particularly interesting was how our different backgrounds influenced our view of the advantages and disadvantages of agile processes for creating great user experiences.

My perspective comes from managing a number of software products and software development groups through the transition from waterfall to agile approaches. In these roles I created and owned the product concept and was responsible for its realisation in the delivered product. And I found this much easier to do in agile rather than waterfall projects.

Earlier integration and test helps create better user experiences

I have seen several large waterfall projects crash and burn because components were integrated and tested far too late. By the time serious problems were found the release deadline was looming, most of the budget had already been spent and the people needed to resolve the problem had moved to other projects or even left the company.

The imperative on agile projects to "deliver working software frequently" should drive them towards frequent (continuous?) integration and test. So they can catch problems before they grow too big and while they still have the time and resource to do something about them. This also requires some leadership within the agile team to prevent difficult tasks being continually pushed into later iterations.

I found this early integration really valuable in creating a consistent interaction style and visual style across a large product, as components produced in early iterations could act as exemplars for later components. And it is now giving UXers the chance to inject some 'undercover' or 'guerilla' user testing to expose usability and usefulness issues, and get them resolved earlier.

To really drive this home UXers should push to get basic user testing included in their team's 'definition of done' and push to get the challenging user journeys built in early iterations.

Self-contained teams produce better products faster

For me, the second great benefit of an agile approach is having a self-contained team with all the skills needed to create the product and the authority to make its own decisions. This saves so much time and avoids so much frustration.

Many years ago I worked in an organisation that had separate teams of testers, developers, architects, product managers, analysts, writers, etc., with all the delays, whingeing and brick-throwing that you might expect. Bringing all these people together into agile teams has been painful, but ultimately incredibly rewarding. And bringing UX people into the mix is painful, but can bring the same rewards.

The product roadmap provides the big picture

Common complaints about agile are the poor quality of the incoming stories or use cases and the lack of a clear overall vision to tie them all together. In most of my jobs I was lucky enough to be able to maintain a longer-term roadmap for my products. And I saw the benefits this had for projects.

The product roadmap set out a clear vision for each new product or release. What it would provide to the business and to our customers, what it would contain, what design principles would guide it, etc. So when it came to building a new feature, while there was still detailed design work to do, the purpose of the feature was clear and its place in the big picture was clear.

The roadmap also helped to drive through broad improvements to usability, performance, reliability, etc. If all you have is a backlog of functionality-focussed stories, these vital efforts too often get squeezed out.

So UXers should push their way into the product planning process, or push to create one if none exists. This is where you get to do your design research and concept design, and where you get to create the big picture that carries through the project.

Agile does not mean 'no documentation'

The Agile Manifesto states that "we have come to value … Working software over comprehensive documentation." I heartily agree with this. When you are creating a software product or system, documentation is a means to an end. And working software is that end.

But somehow, for some teams, this has been warped into no documentation, no specifications, just code. As well as leading to the lack of a big picture that I described earlier, this also cuts the legs out from under the UXers on the team. As Hannah Donovan has said, "Your super power is that you can visualise things in your head and you can draw them." If we can't draw concepts, service blueprints, storyboards, wireframes, illustrations of design principles, etc., then how do we 'talk' to the rest of the team. Do we just wave our hands? Or try to explain everything in a tweet-sized story?

So while UXers should not expect the rest of the team to wait while they create a complete and comprehensive specification of every aspect of the design, UXers can and should produce drawings to communicate both the big picture for the product and the more detailed design of specific components.

A good way to think about this is the transition from always using a language like UML to create a complete specification of a software product before building anything, to using UML as a sketching language to help team-members communicate their design ideas, while they are building a product.

Understanding the UML as Sketch idea is a good way to understand and explain how UX outputs can fit into an agile project, and how UXers can make them in bite-sized chunks.

So …

While this is a personal take on agile and UX rooted in my own experience rather than any research, conversations with Johanna Kollmann and others from Agile UX Meetup suggest that I'm not completely wrong.

What do you think?

1 comment

According to the latest IMRG Capgemini e-Retail Sales Index UK, e-commerce sales grew by only 5% in January 2010, in comparison to January 2009 . At the same time, some retailers have posted large year on year online increases, House of Fraser and Faith have both posted sales growth of 91 and 128%. Online only retailers saw sales drop 2% through 2009 while Multi-Channel retailers have seen growth of 10% according to the IMRG.

These figures tell us a number of things;

• Retailers with strong brands can still gain sales by entering the online market – customers expect them to be there, so even late entrants such as House of Fraser can make progress.
• The greater your brand reach, the greater your chance of making sales in a tough market. People expect to have choice and convenience. Online-only brands will struggle unless they have a true point of difference in a fiercely competitive market.
• Retailers who really understand their customers will succeed in a fierce market.

I have spent many years working in marketing departments of retailers and in stores, and I have never spoken to a retailer who would ever say they don’t know their customers. They must do – customers walk through the doors in their hundreds of thousands each week. They speak to staff at tills, on shop floors, by phone, via e-mail, on doorsteps and in focus groups, every day. Market Insight teams carefully examine basket data from tills, loyalty cards and web analytics. There has never been more data on what people are doing in stores, online or over the phone.

For many years retailers have prided themselves on their ability to second guess what a customer will respond to. How they should lay out a store, what to merchandise by the till, the front door, on the home page or at a category level on a website. They think about which tools will be useful, which image is right and which promotion is best.

Ever better, retailers carry out multi-variate testing to find out what works best, they test press ads, TV ads, e-mail campaigns and direct mail shots. They can prove which version works best, and back the winner.

But do they know why?

In the course of my retailing career, I put together successful promotions, advertisements and product launches. I was even involved in some that were not so good. For all I would be able to tell you why I thought they worked or had failed but I could never actually prove my theory. Did we hit upon a lucky idea, or find the secret formula? If so, could we re-create it for a new product, different category or new season?

The answer to this question lies in talking to customers, observing their behaviour and listening carefully to what they tell us. When done properly, this can give real insight into the most important question: why?

Can I repeat that, yes, like many retail professionals my experience and skill meant I could get it right more times than I got it wrong, but is that enough when we face tougher trading in 2010 than most of us have ever seen at any time in our careers?

Do you know how much it costs to talk to your customers and what the returns could be? Here at Flow, we do and I know you would be surprised.

2 comments

Working with users during the design process will untie project knots and boost team productivity and focus. But there always seems to be an excuse for not testing. Here are 4 ways to counter the excuses and make usability testing happen.

Excuse 1: “It’ll slow us down”

Finding users, building prototypes and working through hours of research takes time. Why not spend that effort on writing more code?

Counter argument. You say: “Our business objective is to reach profitability as quickly as possible. To do that, we need to understand what our customers really need and make sure we’re all agreed on the direction. A usability test might take some time in the short term, but it will help us reach our overall business goal quicker.“

Usability testing, like many UCD tactics, is an investment. You put in time and money, but you get back a product that sells better and costs less to support. But usability testing is also beneficial during the design process…

1. Design the thing better, quicker: Trying to design a product for target users, without ever meeting any, is like pulling teeth. But if you just watch a few users using a prototype, a competitor product or their current system, they’ll tell you what you really need to know quickly, effectively and (comparatively) effortlessly.

2. Manage the politics more easily: Successful designs come from teams all pulling in the same direction. Usability testing results will reduce squabbles, give confidence to management and get people to focus on improvements rather than feature creep. Even the most sceptical team members can’t ignore videos of 5 or 10 real people battling with their software.

3. Get a team energy boost: Seeing ideas succeed makes the team feel positive. Seeing them fail motivates people to sort things out.

Excuse 2: “Our product is already perfect”

You and your team will become so deeply familiar with the product you’ve designed that you will think it is perfect.

Counter argument. You say: “We believe the product is perfectly easy and useful. But can we prove it? How many problems exist that we’re not aware of? What impact might they have? Developers may think their code has no bugs, but we still hire testers to prove it. What evidence do we have that our design is perfect first time?”

This behaviour is often referred to as “drinking your own Koolaid“. It means you’re doubly ignorant…

In a thought-provoking piece a few years back called The Five Orders of Ignorance, software engineering expert Philip G Armour says,

“The hard part of building systems is not building them, it’s knowing what to build — it’s in acquiring the necessary knowledge… A functioning system is the by-product of the activity of finding things out.”

Excuse 3: “We already have lots of feedback”

Listening to customer feedback via email, call centre or the web is vital. Analytics and search log analysis is great, too. And it can seem like you’re getting all the user input you need.

Counter argument. You say: “We’re only getting feedback on major issues and from committed product users – lots of other people encounter our product and never feed back. So we’re getting a skewed perspective. Usability testing will let us observe and discuss all sorts of things that customers and non-customers would never actually feed back about. It will also explain what to do about the strange patterns we’re seeing in our web analytics. This extra insight will give us a competitive edge, because it’s not obvious stuff that our competitors also know.”

Excuse 4: “This concept is not ready to test yet.”

It’s easy to tell yourself that you’re not ready to work with target users yet – that your ideas haven’t settled down to something stable and complete which users will approve of.

Counter argument. You say: “Don’t worry if it’s not ready. We’ll test what we’ve got, and won’t worry much about the areas where we know things aren’t finished. It can give us reassurance that we’re heading in the right direction and stop us from spending loads of time designing a blind alley.”

The truth is, your ideas will never be stable and complete until you’ve had the input from users. Until then, they are just hypotheses. Better to test your hypotheses when they are young and flexible, rather than when you’ve spent weeks on refining them, and publicly declared them as “finished and ready”.

How to run that test

Doing the perfect usability test is no doubt hard. But doing a useful test is really easy…

As Bruce Tog says, without iterative usability testing “you’re going to throw buckets of money down the drain”. So just get out there and test.

2 comments