Agile and UX - I couldn't have said this better myself

Although... I think I have said almost exactly this a number of times.

If you know me, you know that I usually don't completely agree with Jakob Nielsen. However, in this post about Agile and UX, I really can't disagree with anything he says in the post. I haven't read the entire report (I don't have an extra $148 at the moment) so it is possible that I will eventually find something that I can disagree with.

One of the things that really stands out for me is this quote:

You can't just design individual features; they have to fit together into a coherent whole — a whole that must be designed as well. Bottom-up user interface design equals a confused total user experience (the Linux syndrome)

I am not really a Linux user so I can't speak to the User Experience of Linux in general, but the idea that "Bottom-up" design leads to poor results is just plain obvious. Not to mention in my experience I have seen it happen numerous times. In contrast I have see first hand how a small investment "up front" in design proves to really pay off.

User Experience Designers...Listen up!

A couple days ago I posted a question here (and on some other discussion lists) regarding how usability can fit into the Agile process. I revised it slightly and added some clarification:

What are the best methods you’ve experienced with regard to incorporating quality design & usability practices into Agile software development?

There is some debate in the software industry regarding the scope of UI design work to be completed before Agile software development can begin. What are your thoughts? When is a detailed prototype necessary? When is it not necessary?

I promised to post my thoughts so here they are.

The method that I am currently using involves some upfront design time which I consider the architecture phase. During this phase is when you gather and process all the data about various types of end users and their goals. Throughout the architecture phase, we work on low-fi wireframes and/or mockups that address high level global interaction patterns such as type of navigation, inline editing vs. popups vs. separate edit screens, etc. I liken this to the engineers' decisions to use a particular technology, library or persistence strategy. Some of this stuff needs to be thought out early since changes later are expensive and destabilizing. Because, end user satisfaction is a top priority for our customers, I propose doing usability testing during this phase (and all through development). 

While wire-frames and paper prototypes can certainly be tested, we have found that nothing works as well as a clickable prototype. Someone suggested above that just build the real thing and test that. We have repeatedly seen that a very detailed prototype can be built in 4 to 6 weeks where the actual product can take 6 -12 months. Of course with agile development you have something every 2 - 3 weeks but it does take a while to get to something that can be a true test of the user experience. The level of detail in the prototype and wireframes/mockups is really determined by the complexity of the interaction. If one pattern can be reused, there is no reason to prototype every use case of it.

This process can work very well but requires some commitment of time before development begins. This doesn't have to be a year long effort but depending on the type of application somewhere between weeks and months seems appropriate. Regardless of the amount of time required, this is often labeled "Anti-Agile or Waterfall". 

What lead me to asking my original question was my desire to know how others are doing it from a tactical perspective. Can the process I describe above scale? Is it truly anti-Agile? If it is, does that really matter if the result meets user's needs better? 

If the goal is to deliver really good software, not just really good code, I am ok with being slightly less Agile.

Do prototypes help or hinder the Interaction Design process

Almost ten years ago, Alan Cooper (author of About Face and The Inmates Are Running the Asylum and my personal hero) of Cooper wrote a journal article titled "The Perils of Prototyping". It made me think about today's software and the way in which we designers communicate our vision to developers. I posted a comment on that blog asking this question:

"Do the capabilities of today's tools and the expectations of today's users change the need for prototyping?"

The reason I ask is because it isn't as easy to test interaction design patterns on paper if they require visual transitions, sounds, tactile responsiveness (on touch screens), vibration (think Nintendo Wii).

I have seen numerous times that communicating complex interactions to developers with paper mockups, or even digital mockups, is far more difficult than showing a prototype that actually does what is required. 

I have also heard first hand from developers that say a prototype really helped them with the details. Not only does it display how the software should behave, it provides and idea of how it might be implemented. This might be unique to the fact that the prototype built with Flex was for an application that was also built in Flex. So there was the ability for direct reuse of custom components, etc.

What do you think. Is there value? Can it work in an Agile environment? Or is it still as unnecessary as it was ten years ago? 

Do you really need an Interaction Designer?

There is an idea in the Agile world that the most effective software teams are those made up of generalists. From a development perspective I have found this to be, for the most part, true. However, in most of the places where people make the argument for generalists you never hear any mention of the UI. If you are wondering why that is, so am I. In many cases the design of an application is considered to be a technical problem. "Should we use AJAX or Flash?", "How do we hook that front end up to the data?", "How will it perform?", "How easy is the technology to work with?", "Do we (developers) have the skills with this technology?". These types of questions all have a crucial problem. They are all developer focused questions. None of the questions above even remotely consider the end user... those are the people that USE your software, not necessarily the ones that BUY your software.

Things fall apart here because UI is not a technical problem. If you think in technical terms you get a technical solution that works well for technical users. For example, if you ask most developers how to build an app that allows users to manage their timesheet, you are like to get something like this.

A database to store entries for each users.
A screen with a grid on it where users enter hours for each task for each day.

How to build a better Time Tracking application
The problem here is that we got what we asked for. A screen that looks like the developers version of a timesheet. An Interaction Designer may have come up with something different. Why? Because instead of focusing solely on the task of entering time into a database, they would focus on what the user really needs in order to track time. Thinking "outside the db" allows us to investigate how to best meet user goals. In this case, you may find that many people enter all their time at the end of the week. They may keep track on paper the hours spent and translate that into the application on Friday, or occasionally on Monday morning. A more efficient approach would allow the user to bypass the paper step and replace the whole process with something that meets their goals better. We may find that users write down the time they start a task and then when they are done write down the end time. We may also find that an equal number of people write things down at the end of the day. I bet that we would not find many users that log into their online timesheet and enter time spent on each task immediately after completing it. Even worse some users probable don't keep track at all and just make an education guess at the end of the week.

Realizing that the goal is not to "enter" time, but rather to "track" time makes a big difference. Building an application that allows the user to indicate that "I am about to start on task X" and when done say "I am done for now with task X and I am now starting on task Y" removes the added step of tracking time and then entering time into their timesheet. Building in a way for a user to say, "I was out of the office yesterday working in my hotel room, but I worked on X for 2 hours" would also add tremendous value. Using the same application offline allows the user not need to know or care about the technical difference between being "on the network" and "off the network". Have it sync up automatically when the user gets back on the network and you will really have a seemless experience to the user.

So how do we justify the need for an Interaction Designer?
Usually people who make decisions want to see how their decision affects the bottom line. The value of a well-though user experience can be quantified. Imagine you plan to sell you timetracking software to large organizations of say, 50,000 employees. Every week each employee needs to track their time. If you can reduce the time it takes to track time by 15 minutes. 15 minutes x 50000 employees x 52 weeks = 39,000,000 minutes (650,000 hours) per year savings. How much does that cost the organization a year? Even if you only made it 2 minutes faster, you would have a big savings. This isn't even considering what I call the "Extended Cost of Confusion". Extended Cost of Confusion can be more difficult to track however we probably see it every day. You try to use some application and can't figure some function out so you ask the colleague sitting next to you. Best case, she spends 5 minutes showing you how to do it. Worst case she spends even more time trying to figure it out, can't either and now you are both stuck and have spent valuable time. Add on top of that, the cost of calling the help desk or customer support and it can really add up quickly.

But what about the generalist? Can't they learn how to create better experiences?Maybe, but do they want to? And will they ever be as proficient as the person who won't, in the back of there mind, be concerned about how difficult it will be to implement.

For an analogy, think about going to your primary care doctor who is analogous to a generalist. Say, for example, you have suddenly gone blind in one eye. Who do you want to take care of you? The generalist? or an Opthamologist?

Here's another example. Imagine you want to re-design the interior of your house and make something very peaceful and serene. You a contractor to come in and replace some windows, install bamboo floors and paint your walls. Do you want this same person picking out the fabric for your sofa?

But an Interaction Designer will cost money and take timeYes. He/She will. However, what is the cost in dollars and time of building your product and finding out that it doesn't meet the needs of the people using it? What does it cost to rebuild an application? Will you get it right the second time?

Obviously not every product has the same need for Interaction Design. However, almost all products have SOME need for it. If your product is going to be used by humans, make sure it is designed for them to use from the beginning.

So, do you really need an Interaction Designer? What do you think?

Recommended reading: Can programmers do Interaction Design?