Agile UI Design: A Fundamental Miscalculation in UI Design Excellence?

Posted by uidesigner on Mar 25th, 2009 | 15 comments

I’ve been banging my head against a wall trying to figure this question out for some time now. Can existing in an agile development cycle truly create the best ui design? I’ve worked in Agile development environments. I’ve worked with structured project management. I’ve worked in locations where I am the project leader. If there is one thing I have discovered it’s that any process can be carried out so far to one end of the spectrum that quality and more importantly usability, and maintainability go right out the window.

How can a process that’s aimed at creating user stories and defining what the user “wants” be so misdirected? What happens when the process comes before the product? Can you really sacrifice usability for more features and rapid development?

What is this Agile You Speak of?

For those that have not worked in an Agile development environment let me give you a brief summary. Agile is a process that is truly geared towards test driven development. There are many forms of Agile. Some of these methods include, SCRUM, XP, LEAN. XP. While these different versions have slightly different implementation models they all are focused around developing and delivering slices of user stories (features) in an iterative process.

There are many books you can find out there on Agile Methods. Some of the leading industry experts include: Mike Cohen and James Shore. You can find a ton of information on everything from product owners, TDD (test driven development), user stories. What you can’t find is how the UI and the design fits into the process. In fact, in many books on Agile., UI is given 1 page or less.

Great Now Tell Me Where Does the UI Designer Fit in This Process?

This is a tricky question to answer. How can the end user experience be so outright ignored? More importantly in such fast development cycles how can a UI designer stay above the water? Is there someway to apply an iterative Agile design process to the UI development cycle. What are these guru’s of Agile missing?

I’ve read many books on the subject of Agile. My last count was somewhere in the neighborhood of six- seven. And would you believe out of all these books not one of them addresses any processes from a UI, Interaction design perspective. In fact many of the books just give the following worded mantra in some form or fashion “Leave the UI out till the end.”

In my quest to answer these questions I spoke with many prominent UI designers as well as designers within other jobs, corporations, in-house designers. No one can come up with a singular defined method of how a UI designer(s) works in an Agile cycle. There are tips, there are ideas, even some potential “best” practices, and external methodologies. Yet, designers for the most part are not factored into the developmental process. We are left to fend for ourselves. And if we don’t speak up we will be hit by the development bus.

Great Design Just Happens Doesn’t It Regardless of the Process or Technology?

Wait a minute! If you have actually developed software you should know that with PHP, JAVA, and .Net Programming choices made early on can directly effect the UI. In an effort to couple quick templated controls you often are stuck with manipulating the design to the control, include, etc.. You can find this in most every corporate environment, small design shop, etc. This can be especially true with inexperienced teams that don’t surface UI and allow it to be tinkered with as needed. Take .Net 2003, 2005 and more recently 2008. There still tends to be a tight coupling of design to programmatic elements. The point of this development tool is to help a developers quickly slap together something that is passable, rapid to produce and that “look nice.” Of course, looking nice doesn’t mean usable. If you read this blog you probably are well aware of that fact. I’ve had many arguments about the importance of design.

Great design has to be fostered and nurtured in your UI. It has to happen at an early stage, even if it is expected to change rapidly. The trick is having the skills, knowledge, research, methods, and tools at your disposal in the blink of an eye. If your a UI team of one you have to be lightning fast, organized, visual, and quick to think. If you are a UI manager you have to build and align your team strengths to each other and then unify that vision into one cohesive brand.

For now I’m not going to answer the question, but I want you to think. In what ways can a process aimed at produce working software for the users leave out the fundamental parts the users use? And why would some assume slapping a UI on at any point in the process produces anything but a mediocre product?

For those coming from an RSS there is a funny comic below:

Authors Note:

I’ve had this article in draft mode for some time. I wasn’t going to publish it but felt there were a lot of good points and strong arguments and methods to build upon in my two future articles. With that in mind I figured I would let my audience dissect it and provide feedback.

15 Responses to “Agile UI Design: A Fundamental Miscalculation in UI Design Excellence?”

UIDESIGNER says:

March 26, 2009 at 12:36 pm

Let it be known that this article is not about agile being bad. It was written to make you think about some fundamental flaws that exist for UI people.
Urs Enzler says:

March 26, 2009 at 3:15 pm

Why not have a usability engineer and designer part-time in the team. This way the UI can be designed in increments along with the functionality behind the UI sprint per sprint. I don’t see any difference between incrementally building “features” and UI.

Just my thoughts though

Cheers,
Urs
UIDESIGNER says:

March 26, 2009 at 4:00 pm

While this is a great idea on the surface Urs. Not all projects, locations, etc, get the luxury of having extra people. Sometimes one person provides the functions of all these roles.

I don’t see much difference either with having these specialized individuals on the team. In many cases you want to have a good ratio of Business analysts, to Project Mangers, Developers to QA, Designers to Devleopers, etc..

Generally speaking if your product owner is not on board with priortizing UI against functional features you are going to hit some rather tepid arguments.

I have lots more articles coming about solutions, methods, and practical ideas I use to combat these issues.

Like I mentioned earlier, this article was sitting in my drafts for a bit and I wanted it to spur some comments, debates, argument, and of course some ideas on how to deal with these issues.

Thanks for the FEEDBACK! I love it when people comment on the things I write!
Sekhar Ravinutala says:

March 27, 2009 at 10:34 am

Like you said, I think the trick is to have the right skills/knowledge and (more importantly) the right tools. E.g., changing the UI elements with Flex is a snap, but could be a nightmare with Flash. With the right tools, I think iterating the UI is actually easier than the rest of the project.
Rick says:

March 30, 2009 at 2:34 am

First off, I have to agree with Urs: you need a UI person on the team if you are going to do Agile development. There’s simply no way around it if functionality changes in a way that impact the UI. The UI is part of the product, and if the product changes progressively, so should the UI.

But there are other ways to make things easier. For starters, designers and developers should have a common language, for instance in the form of UI design patterns. If a decision is made to use a specific pattern to implement a specific requirement, designers can design the interface without having to worry about limitations in the implementation, and developers don’t have to wait for a complete design up front.

A second possibility is to have UI specialized developer on the team. After all, cross-specialization is an extremely important part of most Agile teams. That UI-developer should be capable of rapidly translating the grand vision of the UI design people that may not be part of the development team to real solutions. A sort of UI-design by proxy if you will. It requires trust, training and good communication, but it does help maintain a consistent level of quality.
At the very least to a point where improving the UI afterwards will be a matter of finetuning the details.

Personally, I believe that on most projects, unless your company is as big as Microsoft, there is really no room for dedicated UI designers that merely “design”. UI specialists should be able to implement the interface, in other words, they should be UI-developers, and be an integral part of any development team. In combination with a good separation of concerns in the software architecture, having a common language and placing a high value on excellent UI design, this should be sufficient to ensure the UI stays up to scratch during development, and can be refined afterwards without technological choices becoming a blocking issue.
UIDESIGNER says:

March 30, 2009 at 3:54 pm

Tremendously good comments Rick. I feel this exact way. The common language is essential to having many of the pre-conversations with busines owners and product sponsors. If you can’t agree on the terminology it adds a lot of confusion later on to the developmental cycle.

I push this common language through my workflow process – sketches, mocks, wire frames, and interactive pdf’s and into the actual UI design.

I’m a firm believer in a specialized UI & UX person and a team if necessary.

In regards to the roles a single UX person takes. I think a good UX person is able to understand and weigh simple programmatic problems of implementing complex but easy to use UI in applications.

They need to share the vision with the business units and help them define the “what.” What is the “problem” and ultimately devise UX strategies for arriving at a solution.

I think the development team needs to be aware that the UI needs to be flexible to quickly adapt to change. One big problem is inflexible UI that is too tightly coupled to the code. It can really ruin a UI designer day. I’ve had many of those.

Agile can work with UX. I’ll be talking about this a lot more in several upcoming articles. You have to be more alert and better able to change in the stream rapidly. You have to be able to understand musch more of what the user stories mean (vision, value). You have to be able to understand how to adopt, drive, and illicit changes to happen at all levels of the process. You have to champion the right causes.

In essence this article is a precursor to understanding how to not let the process drive you – In this case Agile, but to drive the process in a way that keeps you more involved at all steps but doesn’t drive you insane.

That’s a good segway into the next article I’ll be publishing in a week or two.

Thanks for the feedback!
csom says:

April 2, 2009 at 1:59 pm

I put my vote on hiring a UI expert part-time in the team… just as Urs says. The only diff is that we hire one person having both UI design experience and (light) coding practise.

In my experience application screens, and scenarios can be classified into a small number of basic scrren/scenario types. So right at the begining of the development process, the UI expert designs sample shots covering all typical screens, creates the supporting code (CSS, Javascripts, images, etc.) and documents it through a UI design reference (containing both usage overview, and element specifications).
That is to say the UI expert is responsible both to design for usability, and to create-support-and-maintain the neccessarry UI code.

Excelent:) But do we solve our homework? No.

In my (current project) experience ‘design for usability’ is not the biggest problem. The though problem is ‘functional UI planning’:

How can someone go agile with detailed UI plans? if the customer doesn’t trust in user stories? if he asks for detailed UI plans before we can go into production?

Just as UIDESIGNER says: “I’ve been banging my head against a wall trying to figure this question out for some time now”:)
Larry Roth says:

April 3, 2009 at 1:02 am

Great article and a very interesting comment thread! I think I have a very different opinion from most of the commenters.

From my first reading of Kent Beck’s XP explained book, I had envisioned his iterative development (in early stages) to mean either or wireframming or HTML prototypes–wiring the back end in later after you had agreed to the scope. We now have such incredible tools to prototype, I don’t see the reason to “sling code” until the interface is defined.

The tangential benefit–from my perspective–is a really solid programmer and problem solver can better define the data set to be captured, present and future, based on the agreed interface.

yes, no?
csom says:

April 3, 2009 at 4:49 pm

I would say neither yes nor no. We just follow a different approach:) Namely we try to follow the FDD practise. To put it simply:

1st step: Capture user requirements; define funtions/features; design the shape model (containing both data and UI elements, and whatever layer the application has).

2nd step: Roll out an application framework early targeting basic application elements, including both server side and client side (eg. UI) logic.

3rd step: Go on and produce the software in an iterative manner. In every ~4 week iteration: design the detailed model, implement and hopefuly test it:) At the end of the (2-3 month) milestones deploy it:)

In this approach the UI expert is responsible for the basic UI features: produces/documents basic page templates, stylesheets, widgets, etc. This work is done mainly in the 2nd step, then he switches to ’support mode’.

The specific applicaton functions (including both view, and controler logic) are done in the 3rd step: planned/coded by application designers/developers. The UI expert only assists it.

Ps.: I said we tried to follow FDD, since sometimes the customer wants something else. Sometime he wants waterfall:( And after all he is the customer.
UIDESIGNER says:

April 6, 2009 at 3:05 pm

CSOM: So in your particular development would you say you actually get around to doing iterations or are more forced to move on to the next project and hope to get back to it in some millenium?

Also how would you rate FDD as opposed to other Agile Development models?

I’m assuming you gather the features (user stories) from your customers. Do you have a proxy to the customers or is it direct interaction?

Side Note: Anyone have trouble with the comment system showing up when you are a registered user, or when you are logged out. I have a feeling there is a bug I’m trying to stamp out.
Jeff says:

April 9, 2009 at 4:13 pm

It is a very good question. I’m not sure it is any different from “How do you Agile without an X designer/expert/guru?” Where X is UI, UX, database, cloud computing, etc. If you need the functionality, you need someone on the team at least part-time who can do the work or at a very minimum keep you from going off into the weeds. Some details can be tweaked late in the process but the broad outlines will affect the rest of the product, i.e., UX will affect database design and diety forbid someone whose only UI experience is with GUI apps doing the early design that will be Webified later. Font family, size, line width and type can be tweaked in the field when you have real users to measure and listen to. Interaction styles must be settled early on.
csom says:

April 11, 2009 at 3:29 pm

My experience is limited to contract based projects with small teams (<20), and varying skill levels. Within this constraints… my current opinion is as follows:

1. I think FDD better fits contract based development then either XP, or SCRUM. “Contract based” usually means fixed price, fixed time and sometimes means strong customer control (especially in govermantal projects). I’ve found XP, SCRUM to be “too agile” for this type of projects. Meanwhile FDD has techniques to reduce risk in such situations(see [1]).

2. Experts say that FDD can deal with varying skill levels and can scale up. Meanwhile XP is targeting mainly seniors, and is designed to work with 2-10 programmers (see [2]). I agree with this opinion:) Namely I cannot imagine a large XP team, where senior programmers works with lower skilled ones and meanwhile the team aligns with the “Collective Ownership” principle.

3. Also note that in usual projects “mixing skill levels” means a more economic/cheerful approach then working with just seniors – since tasks are at different difficulty levels in usual projects. It would be a very expensive approach assigning senior developers to easy tasks. Also senior programmers would quickly quit in such a situation…

4. Most of the projects that I participated in involved new technologies that had been never seen before by the development team. At this point I think FDD lacks any support – thus I would say FDD (without extending it) is better suited for projects where only proven technologies applied. Meanwhile XP has technique for such a situation (eg. spikes).

But this is just my opinion, and again I could be wrong:)

Refs:
[1] http://www.featuredrivendevelopment.com/node/527

[2] http://edn.embarcadero.com/article/29684
Urs Enzler says:

April 13, 2009 at 5:02 am

To clear things up from my previous post:
We have one developer in our team (full-time) that has a level of understanding in UI engineering. This is however not enough to get our UI in a form that has good enough useability. Therefore, we get support from full-time Useability Engineers that work part-time for our project. Our “UI-expert” acts as a proxy to this group.

We do this for every aspect (UI, DB, …) in our project just as Jeff wrote above. We call these people or groups “consultants” to our core team. These consultans can come from within our company or from the customer or are hired externally.

In reply to UI vs. functional features:
We use a design similar to MVC/MVP (Passive View Command: see http://www.planetgeek.ch/2009/04/08/passive-view-command-pvc-pattern/ for a short description) to separate UI (the look and feel) from the logic (user interface logic, business logic, …)
This pattern allows us to have very little blocking issues between functional and user interface feature development. And we can change the UI (look and feel) very quickly without breaking the logic behind it. Furthermore, we can build real functioning skeletons (something like a prototype) to give our customers something to click on. This skeleton consists of the real View and Presenter, but fake Commands and Model.
cuan says:

December 22, 2009 at 5:51 am

Great points from all, one thing is clear, there is no “correct” solution.

Where I am working now, we are really having an issue with moving the UX team to agile, and its really slowing things up.

One approach were thinking about is to have the UX team front load, so they build up assets that the rest of the team can then get on and build.

I have a fundamental issue with this approach in that it fosters and split team attitude (still them and us) and this is not good long term.

I like Urs approach from identifying the technical limitations and take the decisions and approachs that frees the team up to do it properly.

Properly for me is that the team is capable of taking the User Story to Done.
so.. UX,Design,Dev,Test and Release.

Cheers
uidesigner says:

December 22, 2009 at 7:38 pm

Front loading is a solution, but your UX team has to be prepared to toss away ideas onto the cutting room floor. Whatever methods you can use (paper prototypes, rapid pdf mocks, etc.. ) Should be used in order to keep your UX’s team morale up. The problem you will find is a lot of great ideas at the time don’t always end up coming to fruition because of the rapid development / and change cycle.

I think a lot of people and teams get hung up on the UX done side of a story. They need to focus more on done “right.”

Thanks for taking the time to comment!