Agile User Interface Design and Information Architecture from the trenches

  • 3

Agile User Interface Design and Information Architecture from the trenches

Tags : 

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 to change. Often this resistance was a case the creatives not wanting the reality of building enterprise software to hinder the design concepts they were making in Photoshop or Illustrator. When these design concepts met the reality of enterprise architectures on the development floor there were major implementation problems. This dysfunction, along with high pressure, unrealistic delivery dates and long hours resulted in missed deadlines, high stress, low code quality, and 40% annual turnover in IT staff. Being at this company for a short time spurred my interest in User Interaction design (UX) and Agile, and I have since found basic solutions that work when people want to do UX and Scrum. To date (2011) I would say that of all the disciplines needed for creating software and especially web sites, people coming from UX background are often the slowest and most resistant to adopting Agile principles and practices. I think this comes in part from the influence of Allan Cooper’s book “The inmates are running the asylum.” However Allan Cooper, himself a practitioner looking for solutions that work, embraced Agile and Scrum since 2008, if not earlier.

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. We work from business priorities not UI priorities.
    2. Sketch the highest level 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 half an iteration ahead.
    4. Make paper prototypes (sketches, paper menus, paper buttons) to support upcoming user stories for next sprint. Don’t embellish with new features the designer thinks are needed. KISS. Include validation and other acceptance criteria for data fields.
    5. Create and maintain a style guide and reference it as required. Create and use reference page templates as required.
    6. Combine 2,3,4 above into a 1 page design spec. to support the UI needs of a user story.
    5. Review prototypes with PO, QA and lead dev a few days before sprint planning, ensure they think it is good enough and it is testable. Keep notes regarding potential trade offs.
    5a. Check in design docs, version them.
    6. Participate in sprint planing 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/Javascript etc) in dev IDE, pair with dev as they wire it up. Pair with QA to run test cases and implement automated UI testing (see tools like Rspec, Cucumber, etc).
    8. repeat for every sprint.

To recap the UI designer starts half a 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:

  • Create a style guide for the team and have them read it, listen to their feedback and continuously 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.
  • bad idea ui tool

  • AVOID COMPLEX HIGH FIDELITY USER INTERFACE DESIGN TOOLS. They really slow you down and lock in decisions far too early. These decision are often wrong.

Lack of detailed knowledge about the customer needs and technical limitations can result in an unstable UI. This lack of understanding results in an unclear product backlog and user stories coming into the sprint. To cover these gaps the UI person has to go find out the missing details to create the design, which slows them down and results in numerous design changes during the sprint. The UI designer is making 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 requirements, 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. As User Interaction designers it is important to focus on the end result, great software, and to help the team realize that goal. The UI design artifacts: wireframes, clickable concepts, specs, etc. are often over-valued by UI designers. These are tools in our toolbox and are not essential. Choose the tools and the collaboration model that takes the least amount of time and offer the greatest impact on the goal of delivering great software. That goal is best achieved by working side by side with team members building the software. Many are doing it today. However it does require people to change their behavior, and that is likely the hardest thing to do.



February 3, 2011at 7:35 pm

There were some twits about this post. The idea was that the UI designer needs to be part of the Product Owner team. Well, we tried that, and it doesn’t work. At one client we had two POs for 4 teams and another PO who was the UX designer. It doesn’t work. The UX designer wants to control UI, while the POs want to get top priority features done. The UI gains a disproportionate power in this structure, causing changes in priority based on UI designer needs not the business needs. UI is not strategy, UI is not business value. UI is an interface. Major interface innovations occur slower than technology innovations in frameworks and language. How many times do we change the menu layout? The number of functional UIs is relatively low, and many UIs are very similar. UI is not strategy, UI is not business value. UI is user interface.


February 12, 2011at 8:48 am

Here is a link back to the original discussion on Linked in that caused me to write this post. There are some great comments by others including Clinton Keith on how they do this in video game development where UI and artwork are huge efforts. “Pre-Production Sprints to manage the creative process” in the Certified Scrummasters group


February 24, 2011at 3:45 am

Couple of comments. In SOME CASES UI is realization of some very strategic things such as vision for product, brand, quality, competitive differentiation. Take for example iPhone. UI and UX is everything, technology doesn’t really differentiate it, it’s how user is presented with technology. You can zoom and rotate objects with traditionel controls as well… If you are building something you could buy as COTS, you propably shouldn’t be building it in first place. Buy package instead. Investing in own development is against lean in very deepest sense. However, if you want to acheive competitive edge by building something better (usually faster and more effective) that markets can offer, then you propably have to invest whole lot into UI as well. Artwork is another thing, that’s referring to “decoration”.
The process you described is very much what usability and ux practitioners have been doing for ages. That is how it was thought in university… I’ve lived across change to more formal documentation, which was initiated by request from developers and project managers. Same develoers that forced me to do UML twelve years ago swear by SCRUM now and don’t want any detailed specifications. I’ve wished many times that I could replay many of the discussions for them now.