Tag Archives: UI

I spent a couple of days with the web crowd last week at Web Directions in Atlanta. Design matters on a website, where attention to user engagement can mean the difference between a flop and a million dollars.

I live in the software world, mostly around agile software development. When I talk about agile (and I think this is generally the case), I talk about benefits to the business and benefits to the team (though creating great teams has a business payoff as well).

Why Agile? Heart Reasons and Head Reasons

We talk about a close relationship with the customer or product owner. I don’t know about you, but I’ve met lots of customers who know what they want, but not what they need. And I’ve met product owners who don’t know much about interface and interaction design. I don’t say that to blame them.

Hierarchy of User Interaction (Aarron Walter)
Aarron Walter (@aarron) had a little graphic that crystalized what I’d been thinking.

Agile methods manage business risk. They can bring back enjoyment and pride in work for development teams. For the people who use our software, they make work life maybe less frustrating, because the software isn’t buggy, and maybe a little easier because the software does what it’s supposed to do. But I think we are aiming too low. Can we also make software a pleasure to use?

I’d like to collect some more information. How has your team incorporated UX/ID into short iterations?

Between Kent Beck’s post on Capital Efficient UI Design and attending a UI conference this week, I’m prompted to write down a few thoughts on incorporating UI design into development iterations.

Establish critical design standards at the beginning and work out the details as the software grows. Look and feel, when to use drop down menus, when to us pop-ups can be decided early. But it’s not necessary (or desirable) to have a wireframe for screens that won’t be worked on for months. Too much can change.

Use design critiques to increase the entire team’s understanding of UI design principles. Design critique asks these questions: What was the intent of the design choice? How well does the design choice meet that intent? Is the intent appropriate for the situation?

The goal isn’t to make everyone into an expert UI designer. But when everyone understands basic principles, communication about UI design will be smoother and more effective. And the devs (or PO) will be less likely to go off and do something–with the best of intentions, but not enough understanding–that makes the system harder for the people who will interact with it.

Engage in micro iterations on screen design. Work in rapid feedback cycles. Change only one thing at a time, so that the effect of a change is clear. Looking at the actual design rendered first in simple sketches and then on a computer screen (and there are tools to do this now) reduces miscommunication and misinterpretation.

Design global navigation last. Before designing global navigation, design screens with only local navigation–how people do the work of that screen. Then, as parts of the system are ready to release, create an application map that shows hub and spoke relationships, selection screens, modal screens and links and build just enough global navigation for the current feature set.

Iteration demos to confirm acceptance criteria are necessary, but not sufficient. End of iteration demos confirm that a small slice of functionality works as anticipated. But it doesn’t tell you how much about the experience of someone using the system to do work. Watch people using the software to understand their environment, work, and experience of the software. UX experts recommend that each team member spend 2 hours every six weeks watching people use the software the team members write.

These aren’t the only was to help UI design fit into an iterative development cycle. But they are a start, and we need to start somewhere to bring user experience into agile.