Great Design and Agile Development

Tue, 21 Nov 2006 09:08:06 GMT

I was recently part of an internal panel here at Microsoft where we talked about the creation of user experiences for Agile development processes. We had some great discussions going, and I had a lot of fun having some public debates with various people. I'm not one to shy away from vigorous conversations - in fact, I kind of enjoy them. My wife thinks I should do something with that, like get a law degree or something. But I digress.

Here's my standpoint on Agile. I don't believe that Agile methods enable teams of people to produce world-class design for most types of software development projects, and that the various methods can't successfully scale very well to large ones. If you've got a product that is already well-defined in terms of branding, design principles, customers/users, and vision, Agile may work for you. However, I would argue that having all of those would already put you ahead no matter what process or methodology you use.

There's an assumption with Agile that a programmer's time is worth more than anyone else's. It does everything it can to reduce coding down time. Unfortunately this puts a tremendous amount of pressure on designers, program managers, testers, and everyone else in a multi-disciplinary team to scale up. In the case of user experience people, a friend on mine whose judgment I highly respect estimated that it would take about 2x to 2.5x the number of user experience resources to adjust successfully to Agile. This guy's a UX director at one of the world's largest software companies, and he's been around the industry for much longer than I have, and he's just an all-around smart, well-read guy. He's not one to exaggerate. One reason for this estimate is that many UX activities can be done serially, so a fewer number of people can do them and they roll from one thing to another. With Agile, you would need to do many of the same things in parallel, so you would need more people to do them.

Another person who is quite well-known in UX circles told me that UX folks can be successful by adjusting. He's had success with doing shorter, more targeted UX activities that could fit within the month-long Agile period. I don't disagree you could do some things well in this way. In some cases the reduced timeline could provide some necessary pressure to find efficiencies in a team's process. However I don't believe that you can be strategic when all you can do is think in one month cycles, especially if you're starting something big and brand new that requires a high level of design to be successful. Yes, you can be nimble and find ways around the problem. It's still a problem.

A number of people told me that Agile would help or has helped their teams overcome issues that they've had, like executive management not being in touch, devs not talking to PMs, testers being out of synch, etc. What that tells me, however, is that the team has a fundamental problem with their team culture, and without addressing that the team is doomed to fail. Now if a process can help the team change its culture, great. But simply following a process for process' sake isn't a recipe for success. Don't confuse culture with process.

At the end of the day, a team needs to have a culture that is design-led if they truly want to deliver world-class user experiences and products. I don't believe that Agile is a tool best suited to this task.

A friend of mine made this analogy. Communism, in theory, is good too. See how well that worked out. ;-)

What's the Problem?

Sun, 22 Oct 2006 03:45:27 GMT

Haven't written in a while. It's been busy on the Xbox 360 and Zune homefronts. Soon enough everyone will get to see what we've been working on for the past few months.

The subject of this entry isn't meant to refer to the state of either of these products. It's a short summary of one of my favorite design approaches. You're probably wondering what the hell I'm smoking or that I'm a hideously difficult person to work with. If you knew me you would know the answer to both of those questions.

I believe that one of the most difficult aspects of design isn't in the creation or production of the end product; it's in the definition of the problem that the end product is designed to solve in the first place. Through experience and observation, I would also contend that the lack of clarity on the problem at hand is one of the most common causes of the disagreements and issues that plague any project, and it's even more lamentable because it is also one of the most preventable.

Here's a simple real-life example. It may seem innocuous, but hopefully it gets the point across. Names and details have been removed to reduce the chances of someone wanting to hurt me.

George is working on the sign-up process of one of the many projects we're working on. On the final page of this process, the user is presented with a clean layout with minimal text of one short phrase for each option, and on rollover an additional sentence appeared beneath each one. Unfortunately, users in a usability test were having a lot of trouble understanding what these options meant and some people on the team were also voicing their concern. After some discussion a set of new page layouts were put together to help address the problem. It was decided that the rollover behavior was unnecessary so each option always appeared with a phrase and sentence below it. George asked me to help select the new layouts from the six options.

I started asking some questions. Apparently a few weeks back one of the proposals for this page contained three distinct boxes, one for each option, which contained a short paragraph and a couple bullet points describing in some detail what each option was. However in subsequent reviews, Fred (a senior visual designer) expressed a strong dislike for this approach since it looked cluttered and messy - too much text. Fred was able to convince other people that a clean, minimalist approach was better. So the decision was made to reduce the options to the three phrases with a single additional line on rollover. Which leads us back to the usability results and new layouts.

So, what's the problem?

Going back to the original reviews with Fred, it seemed to me that George and Fred weren't solving the same problem. Unfortunately, they came to a decision on the solution but never agreed on the problem they were solving! From Fred's standpoint, the problem was clearly an issue of visual clutter; obviously the opportunity to reduce text and present a clean layout was the solution. George, on the other hand, was trying to address the user's lack of information about each of the three options they were presented with. These two problem statements aren't mutually exclusive, but because they never came to an agreement as to what the problem was they weren't able to provide a comprehensive solution.

On to round two, here we are again with new layouts and mostly the same text. Again, it seemed that no one had really asked what the problem being solved was. I read the usability report. Users weren't understanding what the options meant, and I wasn't convinced that any of the new layouts solved that problem any better. The problem was to give the user clearly understandable options while providing a visually pleasing and clean page layout. There was a relationship between the three options that was important but completely obscure in the first version and the subsequent layouts. We seemed to have solved the latter half of the problem, but not the first.

So we completely rewrote the text for the options, and spent a good amount of time rewriting and editing until we finally got to three phrases with respective single sentence descriptions that could fit in nicely with any of the proposed layouts.

Looking back, the first missed opportunity was when George and Fred were initially talking about the original options. If they had only asked what problem they were solving, they could have synthesized both of their concerns and come to a solution that addressed them both. The second opportunity was in the redesign, where again the problem wasn't clearly stated so the solutions were again incomplete.

Next time you find yourself in a situation where people seem to be arguing in circles or the discussion devolves into a series of critiques on each person's pet solutions, ask yourself if everyone is actually solving the same problem. The programmer may be trying to improve performance, the tester may be trying to reduce instability, the program manager may be trying to ship on time, the usability engineer is concerned about usability, the graphic designer wants to keep things clean and beautiful, etc. These aren't mutually exclusive problems, but individually the solution to each one can be vastly different and these people will never agree. To move forward it may devolve to seniority, who yells the loudest, politics, lack of time, or lack of resources.

I have found it very helpful to ask early on, "What problem are we trying to solve?" When you are able to articulate that and agree on it as a team, it makes it much easier to provide the right solution and reduce the friction between the people involved. Let me know if this technique works for you - it seems simple, but I've found that people don't do it often enough.

Wildchicken: Management

Great Design and Agile Development

What's the Problem?