Portal de Periódicos da CAPES

E-government II. Introducing user-centered design to an E-government software development company

2005; Association for Information Science and Technology; Volume: 31; Issue: 3 Linguagem: Inglês

10.1002/bult.1720310309

2163-4289

Peter Boersma,

Multi-Agent Systems and Negotiation

EzGov (www.ezgov.com) used to label itself “e-Government 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 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 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. 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_usability_jh.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. 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 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 deliverables descriptions applied to Persona The artifacts' name plus any alternatives (for example, “blueprint for wireframe”) The RUP phase in which it would be created The job name of the person most likely to create it The artifacts' goal A description of the artifact The artifacts' contents A list of suggested reviewers Relationships with other deliverables (input, output, synchronous) An indication whether the client needs to sign the artifact off An indication whether the artifact is mandatory or optional for a project This format helped us specify the artifacts in a clear, structured 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 diagram 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. 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 (estimates, proposals, project plans) because senior UX team members helped write them. This practice meant that for those projects 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 management, we decided to produce marketing materials to promote the existence of the methodology and ease the explanation 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 architects and visual designers. The designers of the poster chose a format with concentric circles for client deliverables, intermediate products and activities. 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 diagram 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 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 about 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 confronted 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 deliverables. This discussion translated into fewer misunderstandings 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 document 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 software 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, leaving time for the tougher problems that required different approaches. Team members would even explain our deliverables 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 proposals 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 follow-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 deliverables 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 mentioned before, our team was given the assignment to standardize 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. There are several ways in which this process of standardization could continue. Examples, Templates and Instructions. The growing collection 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 documents, 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. Integratio 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 delivery managers have adopted RUP and created their own delivery 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.asist.org) or through presentations at conferences such as Design Engaged and the ASIS&T's IA 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.