4 tensions between Agile development methods and User Experience Design

In last month’s workshop on Agility and User Experience, Declan Whelan identified four tensions that teams may struggle with when integrating agile and UX. The crowd split into groups to discuss these tensions and explore some ideas for managing them.

Many thanks to @ericamhc for taking the following notes from each group’s brief presentation — and for sharing them with everyone here.

Tension 1: Advocating for users vs. stakeholders.

First recognize that stakeholders = users. Each are important and must be satisfied to achieve business success.

Investigate and express people’s assumptions about business goals and user goals. Connections will be clearer when both of these elements are understood well.

Explicitly connect user needs to business goals. Avoid advocating for user needs that don’t serve business goals, because they won’t be considered valuable. This doesn’t mean that “usability” should be sacrificed: it means that we need to express the value of improved usability in terms of business goals.

Consider employing user stories (and other methods such as personas) to represent users as “real people”. While you need not formalize these tools, you can sketch them up to help the team connect product and feature ideas back to the needs of users.

Encourage stakeholders to observe usability tests. This brings to life how important usability is to customer satisfaction — and ultimately to metrics such as return on investment.

Tension 2: Balancing technology vs. usability

Take inspiration from popular and effective interfaces that demonstrate strong technology and usability. Our example was Google Maps: while your interface need not mirror these examples directly, they can provide ideas and concepts of what works well and what can be improved upon.

Make key functions simple, especially when constraints of budget and time exist. Focus on the most important and most often-used tasks to ensure they are as simple as possible.

Make interface methods transparent and instinctive. Strive to reduce cognitive load by understanding how people think. Resources: Don Norman’s The Design of Everyday Things and Steve Krug’s Don’t Make Me Think.

Encourage developers to observe usability tests. This can be a valuable feedback loop in the agile process. Usability tests are excellent for highlighting the impact of interface design issues.

Tension 3: Designing up front vs. just in time.

When considering whether to produce documentation at the beginning of a project or just-in-time as you go, consider drafting high-level mock-ups broken into smaller components. Components should be easy to edit and update in response to changing priorities and lessons learned. Take advantage of existing frameworks or tools, even low-fidelity choices such as whiteboards and magnetic interface elements.

Keep teams in physical proximity so discussions are easily joined by other members. This encourages frequent communication and collaboration, which is essential when up-front deliverables aren’t provided. Consider using Skype or other web meeting tools in case you cannot physically be close.

Try building low fidelity mock-ups and prototypes. Consider what tools will meet your needs in the simplest and quickest ways. Paper prototypes and quickly-sketched personas can be very effective, even if they’re never formalized as artifacts. Consider whiteboard sketches, Post-Its, JavaScript frameworks… whatever you think will work. Some people feel that wireframing tools such as Visio may be too detailed and not creative enough for exploring exciting new interface ideas, so don’t let your tools restrict you.

Tension 4: Specifying what to build vs. how to build it.

Keep the vision of what you’re building in mind: focus on the Cathedral, not the bricks. Define the “what” at a high level before deciding upon details of “how” (technologies, designs, etc.). If possible, complete the vision for your Cathedral before the Agile development process begins.

Open communications right from the beginning and make an effort to keep those communications open. Camaraderie is key. Team-building exercises can be instrumental in helping members to communicate, whether they’re designers or developers.

Consider use cases, user stories, and other very lightweight deliverables. However, spending time on them too early or making them specific in terms of tasks can prevent team members from learning as they go throughout the process. These must not restrict you or take up too much time. Jeff Patton suggests a tool called story maps, which can help teams keep their sights on the bigger picture even as they get busy with bringing the details to life.