Agile User Interface Design and Information Architecture From the Trenches

3 March 2011

Robin Dymond
Innovel, LLC

I was a Technology Director in a large web design company 6 years ago, and they failed to adopt Scrum. There were numerous management dysfunctions; however the Creative managers were the most resistant. Primarily, it was a case of not wanting reality to hinder the pretty designs they were making in Photoshop or Illustrator with the reality of building enterprise software. Of course there were huge issues when these artifacts met the reality of enterprise architectures on the development floor. This dysfunction resulted in missed deadlines, high stress, low code quality, and 40% annual turnover in IT staff (and pretty graphics). Being at this company spurred my interest in UX and Agile, and I have since found basic solutions that work when people want to do Agile. To date, I would say that of all the disciplines in creating software and especially web sites, UX people are the slowest and most resistant to adopting Agile principles and practices.

Here is the way I work with UI Designers and Information Architects who want to work Agile:

1. The product backlog and its priorities drives all the work. So we work from business priorities, not UI priorities.

2. Sketch the highest level UI for the site. No drill downs into buy flows, just top level.

3. Look at the backlog and start thinking about what the team will need for UI 1/2 an iteration ahead.

4. Make paper prototypes (sketches, paper menus, paper buttons) to support upcoming user stories for next the sprint. Don’t embellish with new features UX thinks would be cool. KISS. Include validation and other acceptance criteria for fields. Reference style guide as required. Reference page templates as required. I call this a 1 page design spec.

5. Review prototypes with PO, QA and lead dev a few days before sprint planning, ensure they think it is good enough and that it is testable. Keep notes regarding potential trade offs.

5a. Check in design docs, version them.

6. Participate in sprint planning with rest of team.

7. Work with team on implementation, clarify details of design (dimensions, locations, behavior, etc.). Work with QA on test plans for new UI. Help build UI (HMTL/CSS/PHP/etc) in dev IDE, pair with dev as they wire it up. Pair with QA to run test cases and implement automated UI testing (Ruby/WATIR, etc).

8. Repeat for every sprint.

To recap, the UI designer starts 1/2 sprint ahead of the team, helps the Product Owner with UI issues, and creates very lightweight and flexible prototypes as input to sprint planning. The rest of the work is done within the sprint. I have found this is “just enough” lead time to have thought through UI issues without creating solutions in a vacuum away from the team.

Additional tactics to include:
• Create a style guide for the team and have them read it, listen to their feedback and improve it.
• Create templates: every page is not a unique creation. Refer to those templates in prototypes and design spec.
• Break dependencies between UI/layout and business logic at beginning of the iteration. Agree on data/fields/controls at beginning so business logic can be rendered to a very simple layout free page.
• Test your paper prototypes with users by asking them to do certain operations and then observing the resulting actions. Don’t worry about big usability testing at end, do it often and informally with people who are easy to access and know enough about that business.
• AVOID COMPLEX HIGH FIDELITY USER INTERFACE DESIGN TOOLS. They really slow you down and lock in decisions far too early. These decisions are often wrong.

The root cause of an unstable UI design is usually a lack of detailed knowledge about the customer requirements and technical limitations. The product backlog and its user stories and acceptance criteria are probably not in very good shape. To cover these gaps the UI person has to go find out a lot of detail to create the design, which slows them down and results in numerous design changes during the sprint. The UI designer is likely having to make up for lack of knowledge or lack of effort on the part of the Product Owner. Fix this root cause by getting the Product Owner to improve the product backlog so the designer and the team have better user stories and acceptance criteria coming into the sprint. User Interface work is simply another form of software requirement, as are software architecture, features, and test plans. All of these activities can be done in a “just in time” and emergent fashion and result in consistent architectures and usable interfaces. Many are doing it today. However it does require people to change their behavior, and that is likely the hardest thing to do.

Article Rating

Current rating: 0 (0 ratings)


Margie Coles, CSPO, 3/16/2011 6:03:00 PM
Hi--I agree with most everything you have advised. To the contrary, though, I think it would be helpful to differentiate between UI artifacts to guide specific development targets and overarching information architecture to provide a vision and roadmap for a larger set of sprints or even a number of envisioned releases. Unfortunately, the UI "planning" (for example, a style guide) does not always take into consideration the breadth of domain, content, features, or user pathways that will need to be ultimately and cohesively integrated. With some initial IA planning, and a recognition of IA as well as UI planning, a lot of Agile headaches could be avoided.
James Peckham, CSP,CSM,CSPO, 3/23/2011 3:47:57 PM
I think you make some great suggestions and it creates some insight. This is workable for a truly 100% agile environment. Many environments are hybrid with quite waterfall legal, compliance, and marketing departments who have much influence over the presentation. (Definitely in banking where I was).

Somehow there needs to be an agile-esque way to handle UX that still allows marketing, legal, and compliance to feel 'happy' about their long term planning and gives them somewhere to look at some of the glass prior to approving the project.
Vijay Krishnamoorthy, CSM, 3/25/2011 11:44:04 AM
Agree with most of what you have said - esp. the paper prototypes and the sentence emphasized in bold letters. One addition what could add value though is that during project kickoff (some may call this sprint 0), we can have a full persona and environment profile done along with a skeleton style guide and a very high level IA as stated by Margie. This would set up the big picture and context. Detailed scenario and task analysis, Information Architecture refinement, etc. can however be done just in time along with the stories / features / low fidelity designs. Also a Polishing sprint can be planned pre-release to create any high-fidelity refinements.
Gagan Rana, CSM,CSPO, 4/4/2011 8:46:30 AM
Nice article.

I work as a Agile Business Analyst on Web Projects.

In my experience, UX artifacts are sort of requirements/user stories which should be covered in 'Just Enough' details i.e. they should be in Ready state, before we take them into Sprint Planning meeting. Be careful, that 'Just Enough' do wary with all organizations and context. Absolutely planning ahead is the key for UX or any requirements to 'Just Enough' detail.
Nhan Vu, CSM, 4/18/2011 2:25:57 AM
I have background in different positions, marketing, UI design, developer, project manager and scrum master. And I agree with most of your points. The UI mock-up, draft is quite important for all stakeholders, team members and PO. It visualizes the basic idea for the business logic and the interaction. I like the idea the "polishing sprint". I work in small teams and tried it that way. My priorities for the User Stories is business logic with high value first. Try to do complex features at the very beginning.

Thanks for sharing!
Greetings from Saigon,

You must Login or Signup to comment.