Agile UI Design
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
Between Kent Beck’s post on Capital Efficient UI Design and attending UI conferences in the past, 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.