E-Government 111 Introducing UsePCentered Design to an E-Government Software Development Company

by Peter Boersma

Peter Boersma is senior information architect at EzGovS EMEA headquarters in Amsterdam, The Netherlands. He can be reached at peter: boersma @ ezgov.com

zGov (www.ezgov.com) used to label itself “e- E Government Technology Specialists” but now uses the tagline “Transforming the business of gov- ernment.” The company also went through a trans- formation, one that included the adoption of a user- centered 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 gener- alist Web designers, it was becoming a large col- lection of specialists, with titles such as informa- tion 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 knowl- edge and view and distribute the results. Hardly anyone uses these tools after the initial configura- tion, but everyone uses the artifact templates, espe- cially those for high-level software design and pro- ject management. Other rational tools, such as Requisite Pro for requirements management, Rational Robot for automated testing and C ledase 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 arti- cle 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~usabilityj h.pdf). In a second article, “Transforming User Experience Models to Presentation Layer Implementations,” pre- sented at OOPSLA 2002 - Second Workshop on Domain Specijic Visual Languages in Seattle in 2002, Kozaczynski and Thario stated that “a UX model is a visual representation of the screens, screen transi- tions, 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 RUP-

based methodology for the Web design agency Satama (www.satama.com), I was asked to run the workshop that kicked off our own process for standar- dizing 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.

Bulletin of the American Society for Information Science and Technology-FebruarylMarch ZOOS

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. Big- impact deliverables such as high-level screenflows and usabil- ity test strategies were placed in early stages of the develop- ment cycle with incremental improvements, details or spin-offs located in later stages. Slowly a set of “streams” of deliver- ables emerged, and each required specific background knowl- edge. Examples of these streams included usability, infor- mation architecture, content design and visual design, and when combined in the right way they broadly mapped to exist- ing 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 arti- facts, indicated by boxes with their names. The artifacts were linked to each other by a multitude of arrows indicating inpudoutput 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).

Figure 1 : The template for deliverables descriptions applied to Persona

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:

rn The artifacts’ name plus any alternatives (for example, “blueprint for wireframe”)

rn The RUP phase in which it would be created rn The job name of the person most likely to create it rn The artifacts’ goal rn A description of the artifact rn The artifacts’ contents

A list of suggested reviewers rn Relationships with other deliverables (input, output,

rn An indication whether the client needs to sign the arti-

rn An indication whether the artifact is mandatory or

This format helped us specify the artifacts in a clear, struc- tured way. It also allowed us to remove duplication and adopt similar names for similar artifacts.

Over the course of several months we refined both the dia- gram with boxes and arrows and the structured deliverables descriptions. Several times these products were reviewed by fellow UX team members, either formally by sending them sets of descriptions to review, or, for example, by posting the diagram on the wall.

synchronous)

fact off

optional for a project

Osmosis The result of all this work slowly crept into the company,

almost by osmosis. At first the UX team members that developed the diagram and deliverables descriptions started using the accepted terms, our own controlled vocabulary. The whole team then picked this up. Team members had to explain these new terms to their project team members. For new projects, the terms where ingrained in the early project documents (esti- mates, proposals, project plans) because senior UX team mem- bers helped write them. This practice meant that for those pro- jects our work was discussed in terms of the new methodology in team meetings, peer and team reviews, and with the client.

To reach a wider audience, including sales and upper man- agement, we decided to produce marketing materials to pro- mote the existence of the methodology and ease the explana- tion and integration steps. We started with three posters that showed the activities and deliverables of each of the major job roles in the department: system analysts, information archi- tects and visual designers.

The designers of the poster chose a format with concentric circles for client deliverables, intermediate products and activ- ities. Some key deliverables and activities are also shown in a linear process to show how they appear in a project. A visual designer also helped us redesign our original clunky, boxy dia- gram RUP/Streams diagram into a more appealing, colorful, flowing shape that even (almost) matched the corporate house style. The result was printed out as a poster that was hung on a

FebruarylMarch 2005-Bulletin of the American Society for Information Science and Technology

wall near our workspaces. This overview was quickly picked up by some members of our sales team to show potential clients how our UX team worked when the market started asking abu t methodology. Nowadays, when new employees are shown around the company to introduce them to the team, we will take them to our wall with the poster and explain how we work. Unfortunately the large physical size and considerable detail of the posters prevent their being legibly reproduced here.

These marketing activities helped all involved parties to see the connections between the deliverables they were con- fronted with in documents and face-to-face discussions.

How did all this affect our work? The answer depends on how close you were to the core development team.

The user experience team members learned to speak the same language by collectively discussing our ways of working and our deliverables. This process started with the kick-off workshop, continued during the review process of the diagram and deliverables descriptions and continues to this day when we discuss how to combine smaller artifacts into project deliv- erables. This discussion translated into fewer misunderstand- ings about the contents of a document, the kind of activities expected and the required input. It increased the consistency of our work. Because each project’s deliverables were chosen from the same total set, we could reuse previous documents as examples or templates. This re-use in turn allowed us to docu- ment our work faster, leaving more time to study our design’s completeness, quality and effects on others. Our fellow project team members, who ranged from soft-

ware developers and quality engineers to delivery managers and fellow estimate writers, were also confronted with a more consistent vocabulary coming from the UX team. They would recognize deliverables from previous projects, even when none of the UX team members were the same. The content was similar too, as were the requests for input or comments. This was true for projects in the Amsterdam office as well as for inter-office projects.

Project managers could confidently draft large parts of new project plans in more detail and with more accuracy, leav- ing time for the tougher problems that required different approaches. Team members would even explain our deliver- ables to clients in workshops.

The EzGov employees who because of their role were most detached from our activities would hear about our efforts through others. Sales engineers read our estimates and pro- posals and would sometimes ask for descriptions of activities or work products proposed in these documents. As a result elements of our deliverables descriptions such as the goal or contents were used in the final proposals, as were high-level descriptions of our methodology.

To be consistent, they also brought these stories to the fol- low-up sessions with interested clients, either as textual description with voice-over or using the diagram. To make

the circle complete, our clients would ask for these deliver- ables in the kick-off meetings with the team members.

It didn’t take long before management heard about our standardization efforts. Along with the reorganization men- tioned before, our team was given the assignment to stan- dardize our way of working and increase our use of RUP. In check-up meetings our manager told his manager about our standards for user experience (StUX) model. He was then asked to present the results in a company-wide management update meeting, which helped the introduction of our methods in other offices.

Future Developments There are several ways in which this process of standard-

ization could continue. Examples, Templates and Instructions. The growing collec- tion of deliverables that follow our standards allows us to select a few as best practices and use them as examples for new employees or others that wish to see the documents. These examples can also be developed into templates for new doc- uments, extending the descriptions of their contents in the standards to give realistic introduction texts and ready-to-use intermediate products. Instead of this model contents, we could give instructions as to how to come up with the actual contents, either in the template or in a separate document. These instructions would allow junior employees to build on the work of their senior colleagues. Integration with Other Disciplines. Just as our methodology is based on RUP - extending it in some places, replacing parts in other - so EzGov’s other departments have tweaked the process to their benefit. After all, that was the intention of Rational’s developers. These departments could follow the same route and describe their way of working in similar, proven ways. The first signs are already to be seen - our deliv- ery managers have adopted RUP and created their own deliv- ery management process. Assuming they use the same way of promoting their way of working, all departments might end up with their own, compartmented posters and deliverables description documents. Of course these products would have to be mapped to each other to show the global picture, as well as be rearranged when a new reorganization is necessary. Adoption by Other Companies. Beginning with our clients, other companies were slowly exposed to our way of working. Some of our clients had adopted RUP prior to working with us, and they now may be inclined to adopt our changes too. Employees of other companies may have heard about StUX through mailing lists such as ASIS&T’s SIGIA-L (www.asistorg) or h u g h presentations at conferences such as Design Engaged and the ASIS&T’s ZA Summit. The result may be that those companies will also adopt our way of working, and if we can all share in the results (examples, metrics, suggestions) we can also share the improvements, And, at least in the case of EzGov, that’s when citizens around the world benefit.

Bulletin of the American Society for Information Science and Technology-FebruorylMorch ZOOS