Agile User Interface Design
Building a web application following Agile principles has many advantages over other approaches, but there is the challenge of how to integrate the work of graphic designers, interaction designers and web specialist developers into the rapid, iterative cycle.
Traditionally, where I work, the old process was as follows:
- Idea is proposed
- Interaction Design produce page designs
- Graphic designers create all the required images and mock-ups
- Customer testing performed using static page mock-ups
- Pages get signed off by various departments, including legal
- A signed off spec of the screens and copy is handed over to the web designers and developers to implement.
This is very waterfall, and by the time the developers first see the designs, it is already too late to influence them. When the first screens are produced from the early iterations, the feedback loop that is so important to Agile projects is not taken advantage of, because the spec is cast in stone. What we need to do is make this a more iterative, lightweight inclusive process and not a heavy-weight, inflexible, exclusive process.
Learning from the early mistakes we made when we tried to totally integrate the front-end developers into the overall process, I think that we need to recognise that this creative process has to work as something of a production line, but with iterative cycles to get valuable input and feedback into the system as quickly as possible.
In this Web Application Production Line, we need to make sure that every specialist skill is allowed freedom to work to its fullest without being constrained by other parts of the process. We also need to make sure that all the information is included in the feedback loop so that early decisions made with partial information don't constrain the decisions down the line.
Web Application Production Line
So, how to approach this? The initial idea will come from the business or marketing, or an R&D department. If this idea is too concrete with regard to the final implementation, the rest of the process will be constrained and won't work optimally. Therefore we should limit the expression of these ideas to Outcomes, Constraints and High-Level Stories. This gives the development team the freedom to do their jobs effectively.
The next problem is: what skillset is most appropriate for step 2 of the production line? I think that this is Interaction Design. However, currently, Interaction design involves a lot of Graphic Design and static pictures of page designs. I don't think that this is appropriate at this stage of the process. Its too early in the process to be finalising look-and-feel, graphics, spending time getting details just right on pictures produced in Fireworks or some other art package. We need wire-frames at this stage - no fancy graphics, just black and white wire-frames or pencil sketches that capture the fundamental user interactions with the system. We don't want to spend time getting sign-off from all the interested parties, we want the first cut of the user-interactions defined quickly by the people who are skilled in this area. Then they should communicate and discuss their ideas in person as we move on to the next stage of the process, with the expectation that these Interaction Designs will grow and evolve and be changed as part of the iterative process, incorporating feedback from customers and developers.
One aspect of the signed-off spec that comes out of the Interaction Design step in the current process is that all the page designs and mock-ups have been produced in art packages as if they were for paper designs. Hardly any consideration has been given to the fact that this is a page to be displayed on a browser. Is it fixed-width or a liquid layout? How does it expand with the window? Is the design appropriate for the limitations of HTML and CSS? What about accessibility, load-times, degradation between different capabilities of browsers, different screen sizes? The list goes on and on, but the current spec doesn't address any of these points. Despite this, it still gets signed off and passed to the developers.
In my opinion, the next stage of the process needs the front-end specialist developers (Box 2) (XHTML, CSS with appreciation of UID and Graphic Design) involved to quickly get some basic XHTML documents produced, with maybe some quick (standard?) CSS applied to give the page some structure and the right sort of image. At this point, the browser-specific considerations mentioned above will come into focus and these can be discussed with the interaction designers. However, because the wireframes are so basic, they should not constrain the web designers, and they should have the freedom to augment the early designs with their input and record their decisions in the form of an XHTML document.
This is where you can start your user testing and initial feedback loop. Real customers might not be appropriate, given the rudimentary nature of the pages at this early stage, but within a web development team, there are many people who can give valuable feedback at this point. The Truth (Business Representative on the team), QAs (testers), Interaction Designers and Web Designers are all good candidates to try the early pages and give feedback.
You can go round this initial loop (Box1, Box2) until everybody is happy that the interactions are optimal, the basic layout is acceptable, and the XHTML, accessibility and cross-browser compatibility hit the right level. Then this can be "signed off" by the Interaction and Web Designers as their requirements spec, and put into source control.
The code is the documentation. This static HTML could include comments as placeholders for required dynamic content, and all the various XHTML fragments to support all scenarios that can occur in the page so that the ASP.NET (or JSP) developer can easily understand what he needs to do. Everyone should work on this source-controlled XHTML document from this point onwards.
It os at this stage that the Graphic Designers, the Copywriters, Legal, Brand etc can get involved and, using the XHTML document as the master copy of the spec/design, work to build the finished article with the correct Brand, legally compliant text and the correct images.
Design Work with Planning and Stories
The Car Analogy
I always use a car anaolgy, so see the XHTML document as the body-shell of a car at the start of the production line. It picks up its engine, wheels, interior, electrics and paint job as it progresses past all the various stages. As long as everyone works on the same body-shell and nobody changes the structure of the shell as they do their work, then at the end the car will have all the right features and fulfil the requirements of the initial design. However, if anyone does make a fundamental change to the structure of the body shell, then we have to immediately stop the production line (Jidoka) and fix the problem straight away, with all departments involved in the resolution. The cost of this needs to be measured and recorded to ensure that it is understood what caused this waste and avoid it happening again. We have tried to continue in this circumstance, and it always causes big problems later, and nobody is clear what caused the problem in the first place, so repeat the mistake. Its best to either fully complete the work as you had intended initially including full acceptance testing, or totally back out all the changes made to that point. Its a tough call, but the alternative is far more painful.