The Case for User Interface (UI) Designers on Agile Projects

Let me say right out of the gate that I like what UI designers add to the success of a project. Still, there are reasons why some in the Agile community would reject the use of UI designers out of hand. After all, isn’t a key goal of Agile to stop the dinking around and jump into actual code as soon as possible?

Over the course of my career I have had projects with and without UI designers. Where I have had UI designers on the team, it has run the gamut from one for a few weeks early in the project, to having multiple who handle design and business analysis throughout the duration of the project. Based on these experiences I have formed my opinions as to what works and what doesn’t.

The Value of a UI Designer

It is first useful to consider the value added by a UI designer.

• Cohesive look and feel – I’ve noticed with Agile projects in particular that, without a UI designer, an application can morph into an eclectic mess that lacks continuity. Sometimes this is due to differing developer preferences, sometimes due to the customer requesting different things from different developers based on the different screen or their mood on that day, etc. The UI designer adds real value in this case, since they work with the customer through a variety of screens to create a cohesive look and feel.
• Risk mitigation – UI designers also add value by taking on each of the most complex forms. This can save a lot of time because, once they have customer feedback and approval, development can grab the UI and move forward on development with confidence. Some Agile proponents would say that developers should “embrace change” and handle the UI design themselves. While I agree that refactoring has its place, I simply believe that 1) We all know that the look and feel will be refactored repeatedly; 2) It is cheaper to go through these loops with design prototypes, rather than after you are already knee deep in code.
• Elegant usability – The UI designer is aiming to provide a great user experience. They study this as a discipline. I find that having an expert in this area generally makes for a quicker path to a top notch design. For many this is a no-brainer, but for some Agile proponents, getting a top notch design isn’t the point. Let’s get an app that works first! I would agree, but would additionally argue that usability is an integral part of a working application. An app with a poor flow, inconsistent screens (different button names and locations, etc), etc. is not an effective application. Developers, customers, and end users all take to a professional looking app much more readily. After all, who wants an ugly app?
• Templates – Design results in a nice stack of templates that developers can pull from. For example, the system may end up with hundreds of data entry screens, but the UI designer need only knock out a few for developers to easily pick one and tweak rather than reinventing the wheel each time. I find this to be a happy medium between having a UI designer do all designs, and making developers do all of their own designs.
• Checks and balances – The argument could be made that some developers are also excellent UI designers, so why not have the same person be developer and UI designer? On the one hand, if this works for you, great. I’ve seen this work pretty well, but in general, even for smaller projects, I find it invaluable to involve a UI designer, even if just for a small burst. It is nice to have the checks and balances of a UI designer who dreams big, and a separate architect who balances this with sound architecture that may involve modifications to the design. If one person plays both roles, it is human nature to short-change one of the two roles, i.e. limiting design to whatever is easiest to develop, or else creating a pie in the sky design that is really cool but unnecessarily expensive to implement.

Ideal Use of a UI Designer

So yes, I believe that a UI designer can be a valuable resource for a project. However, I also believe that there is a point in a project where a UI designer has diminishing returns. What is the ideal UI designer engagement? Well, that varies from project to project, but here are some general guidelines.

I find it ideal to engage a UI designer shortly after completion of the initial phase (Elaboration, Pre-Project, etc). At that point you have your project scope and have a decent idea of how the application should work, and should have a good idea of the risks. The UI designer's engagement on the project should ramp back down shortly after development begins. For the remainder of the project, it is wise to retain the UI designer on a part-time or as-needed basis to address the subsequent one-off design challenges that arise over the course of the project.

While on the project, the UI designer should have the following goals:

• Mitigate key risk areas – The key areas of risk should be identified, i.e. complicated or unique screens, then the UI designer creates prototypes until they get an approval from the customer.
• Knock out the core screens – If screens are one of the high-volume grand-central-station type screens, then these should also be designed.
• Design the flows – If there are any required flows throughout the system, this should be designed to ensure you have something that the customer likes, and so that development can create a feasible architectural design.
• Create a demo – A demo is about the best communicator of project requirements to upper management. Let’s face it, how many decision-making managers ever really read the requirements documentation or architectural designs? By contrast, how many pay attention and ask relevant questions when viewing a demo? The demo shouldn’t be anything too clever, but rather should piggyback on the screens already designed, with a few links between them to demonstrate the flow through the system.

UI Designer Limitations

It is important to engage a UI designer where they can add significant value, but avoid stretching their limits or keeping them fully engaged on the project longer than makes sense.

• Business analysis – I have seen UI designers brought on to projects as joint business analysts / UI designers. Again, some can do this, and if it works for you, great. However, my thoughts on this are much like my thoughts on making the developer also take on the UI designer role. Maintaining the checks and balances between the business analysis and interaction design disciplines is very helpful, because otherwise one or the other is typically short-changed.
• Designing every single screen – I have seen more than one project where development could not begin until the UI designer had completed their prototype, even if it was another run-of-the-mill data entry screen. This crosses the line from saving time to creating a needless bottleneck. Let the developer grab a template and run with it, and let the UI designer take on the next big design challenge.