E-Government II: Introducing User-Centered Design to an E-Government Software Development Company

Bulletin of the American Society for Information Science & Technology, Feb/Mar 2005 by Boersma, Peter

EzGov (www.ezgov.com) used to label itself "eGovernment Technology Specialists" but now uses the tagline "Transforming the business of government." The company also went through a transformation, one that included the adoption of a usercentered design approach on top of its existing software design methodology.

When I started working for the company in December 2002, the user interface department was growing fast. Instead of a small number of generalist Web designers, it was becoming a large collection of specialists, with titles such as information architect, visual designer, art director and producer. These new employees, each with their own specific backgrounds, brought with them a surprisingly wide array of new words for what they did, their own jargon. The department's manager realized something had to be done before his team turned into a new Tower of Babel.

RUP Isn't Enough

The company's software methodology was based on IBM's rational unified process (www.ibm. com/software/awdtools/rup/) (RUP), a configurable software development process platform. RUP is iterative (it uses phases & iterations) and role-based (it acknowledges disciplines). It includes tools to change the default process, add corporate knowledge and view and distribute the results. Hardly anyone uses these tools after the initial configuration, but everyone uses the artifact templates, especially those for high-level software design and project management. Other rational tools, such as Requisite Pro for requirements management, Rational Robot for automated testing and ClearCase for tracking defects, were used extensively.

Since RUP was published, several companies in the Web-design world have discovered that it does not allow them to specify their front-end heavy work processes sufficiently. An analysis of the thinking behind RUP shows why. In November 2003 an article appeared in The Rational Edge, the e-zine for the rational community, describing an addition to RUP, the so-called UX (user experience) Model (www.ibm.com/developerworks/rational/library/ content/RationalEdge/nov03/f_usabilityjh.pdf). In a second article, "Transforming User Experience Models to Presentation Layer Implementations," presented at OOPSLA 2002 - second Workshop on Domain Specific Visual Languages in Seattle in 2002, Kozaczynski and Thario stated that "a UX model is a visual representation of the screens, screen transitions, dynamic screen data and user-initiated input events that need to be handled by the system" (http:/ /se2c.uni.lu/tiki/se2c-bib_download.php?id=262). By making special versions of objects and diagrams in UML (Unified Modeling Language promoted by RUP) one creates a UX Model.

This model "integrates usability concerns into the RUP development approach" but is still only "used to describe the technology aspects of the user's interaction with a Web-based system," so it does not model the user-centered design aspects.

Kickoff Workshop and Reviews

Since I had previously worked on creating a RUPbased methodology for the Web design agency Satama (www.satama.com), I was asked to run the workshop that kicked off our own process for standardizing our way of working. We brainstormed about our processes and deliverables, about relationships between the department's deliverables and those of neighboring departments and about how it matched with the company's existing way of working. The result was a wall-sized collection of Post-It notes with hand drawn boxes, arrows and annotations.

A team of three members - the UX department manager, the senior visual designer and I - went to work to structure the results. We decided to stick to RUP's principles of iterative development, role-based activities and risk-avoidance because they match with the way user-centered design works. Bigimpact deliverables such as high-level screenflows and usability test strategies were placed in early stages of the development cycle with incremental improvements, details or spin-offs located in later stages. Slowly a set of "streams" of deliverables emerged, and each required specific background knowledge. Examples of these streams included usability, information architecture, content design and visual design, and when combined in the right way they broadly mapped to existing job descriptions. We developed a matrix-like diagram with RUP phases (systems analysis, information and interaction design, usability and accessibility testing, content design, visual design and information design) on one axis and the streams on the other. Each cell contained one or more artifacts, indicated by boxes with their names. The artifacts were linked to each other by a multitude of arrows indicating input/output relationships.

In this structuring process we discovered a lot of overlap between suggested artifacts. To get rid of this, we started describing the artifacts in a structured format (Figure 1).

The template for this format was set up, reviewed and tested on a few artifacts before it was agreed upon. At that time it had room for the following information: