Architects and the User Experience

Michael C. Martin

December 2007

Summary: The user experience should be thought of as a process that starts as early as when the project is conceived, and continues past deployment into revision and maintenance. (9 printed pages)

Introduction
Implementing the User Experience
A Collaborative Scenario
Becoming Expert in UI
Conclusion
Critical-Thinking Questions
Further Reading
Glossary

Introduction

My first experiences with "computers" were in a very fixed format: punched cards, punched tape, slow-speed teletypes; and, if you were lucky, you were able to interact with a timesharing system on a glass-tube terminal. Everything was 80-column cards, 80 x 24 character grids, fixed-width printers; or, if you were in a very scientific area, you might have access to a pen plotter. There was nothing very "user friendly" in this environment; it was a bare-bones interface, and you dealt with what was in front of you one screen at a time. The only "users" at the time were we technical types; average people had no contact with a computer, nor did the processes and systems really allow them to.

When I was in college in the late 1970s, all of the education and discipline around software development concerned only the technical, behind-the-scenes activities. A "user" usually dealt with printouts and reports, and never really got a chance to be in front of a computer—with all of the opportunities to punch the wrong button; to think differently from how the programmer or operator did; or to make a choice that made complete sense to the user, but that violated systematic business rules that were embedded in the application. Nowhere did anyone ever "teach" me about what it meant to make the user the focus of anything that was IT-related. Of course, users were never really part of the technical delivery of an application; they were just the endpoint consumer of whatever the output of your application provided them.

The late 1970s and early 1980s brought a dramatic shift, with the advent of "personal computers" and improved departmental computing resources such as minicomputers. People now had the access to devices that would automate processes in their personal and professional lives. For a young salesperson in the local computer shop, the motivating factor (excuse, actually) to sell computers to the curious was, "You could balance your checkbook. You could organize your recipes. You could let the kids do their homework faster." I think that most of these reasons were really excuses to help justify the purchase of a novelty, and to cover up the fact that all that these people really wanted to do was to go home and play Zork. Still, it did mark the start of an important turning point in IT. It was here where the concept of using computers at a more personal level took on a more important meaning. The common person began to see both how IT has been running all of these years (command-line interfaces, fixed terminals, cryptic error messages) and that all of this wonderful computing experience was very arcane and not that easy to use.

Implementing the User Experience

As time progressed, leaps and bounds in improvement were made in how to make the computing experience more approachable and consistent to the "end user." Arguably, the more successful and visible of these commercial efforts today are embodied in the Windows family of Microsoft products, the Apple Macintosh platform, and related windowing-friendly operating systems.

Today, the IT environment is several orders of magnitude more complex than it was back in the 1970s and 1980s. The increase in connectivity to online data sources and movement to client-server computing models brought changes in end-user experiences. With the use of the rich clients on the desktop, and with the browser and the Internet, you can access seemingly endless quantities of information in very rich interfaces—both inside and outside of your organization. Simple boundaries of what was once a well-contained IT infrastructure have broken loose into domains of multiwindow viewing and issues of access, authority, control, and interface.

Expanding the Team for UI

And yet, today, higher schools of learning still focus on the technical side of the IT equation: database theory, object model–driven development, language skills, operating systems, and so on. Not that this is a bad thing (there is only so much that you can cram into four years of study), but it still does not leave much time to dedicate to how you should consider writing software with the user in mind.

Yet, to be good at "user experience," you really must be technical and have an understanding of human psychology, information design, and some level of creative spice. So, you might ask, if you cannot really get this education readily in higher institutions, where do you get this experience and training to help understand what "user-experience" thinking is all about?

In my current job, I work with a team of folks with wide disciplines and talents to deliver Web-technology applications. I am sure that a lot of the "Web boutiques" that are out there have a similar staffing model. Of course, there is the technical side, which has the developers, system administrators, database administrators, and software architects (or, as we call them, "solution architects") acting as technical team leads. The project managers are also necessary, to handle the overall team and customer management of the project.

As far back as I can remember, the Development and Project Management teams have been consistent members of any IT project. However, new to this talent mix is a collection of talent that is quite unique to the software-development realm: These are the creative directors, media specialists, and information architects. It is very rare these days for my group to have a project in which not all of these disciplines are represented on a project.

As our projects go, there is usually a close triumvirate of core leaders that are on all projects: the project manager, solution (software) architect, and information architect. I am going to guess that you, the reader, are already somewhat familiar with the technical side of development; so, I am not going to go too deeply into talking about the roles of project manager or solution architect. However, it's the other roles of information architect (IA) and creative director (CD) on which I do want to shine a light, because these roles have proven to be the strong advocates of user-centered design on the core team.

A Collaborative Scenario

Let me give an example of how we work together. I'll use a fictitious company name for this example of one of my real-world experiences. Let's call them the "Adventure Works Horse Buggy Rental Company."

The current revision of the Adventure Works Web site follows the very technically correct process of asking for information that is relative to making a reservation. The previous software developer made it a point to strictly follow the application programming interface (API) that the owners of the reservation system provided for putting a front end on. That way, there would be no logic faults in the online process of making a reservation. The Web site was published to the world, and now people could rent horse buggies wherever their travels took them—at least, technically.

The first users of the site were very frustrated, and they complained loudly to the customer-support group. This confused the Web developer, because there were only four sequential screens that were required to make a reservation, and these four screens followed the flow exactly as the reservation system API told them that they had to. All that users had to do was to fill in a screen that specified:

1. When and where they were renting the horse buggy.

2. When and where they were going to return the buggy.

3. The make and model of horse buggy that they wanted to rent.

4. How they were going to pay.

Pretty simple—right? All use cases were taken care of, and all test cases passed. Why were the users frustrated?

Happy Paths Meet Business Rules

Well, it turns out that business rules got in the way. One of the problems was that, given a particular season of the year, there might not be a location from which to rent. For example, everyone goes to Martha's Vineyard for summer vacation and needs a horse buggy to get around; but, in the winter, there is no one vacationing. So, they move the horse buggies to a more favorable renting location, like Orlando. However, in the application, Martha's Vineyard was a valid location from which to rent, no matter what the season was.

With the same issue, but in opposite seasons, someone might want to go for a sleigh ride in Aspen in the winter; but there would be no call for horse buggies in Aspen in the summer, causing the local horse-buggy-rental location to shut down. Also, even though there might be a selection of 15 different horse buggies on the Web site, only certain models were available in certain locations during certain times of the year; and not all locations could carry all models or all special equipment. For instance, if you were renting in Florida, having a ski rack on your buggy did not make business-rule sense, because it meant that the ski rack was for snow skis. Selecting a ski rack for a car in Orlando (because you were thinking water skis) gave you a business-rule error, with little to no explanation of why your choice was not valid.

As you can see, the permutations and combinations of what happens in the real world were not very well represented on the happy paths of the use cases (the straight-through path in the use-case description, with no exceptions) that were used to construct the site in the first place.

So, on the site, users would have to answer all four screens in sequence before they would get a "submit reservation" request button. If any one of the four conditions failed, they would have to restart the process from the beginning. This turned out to be more of the rule than the exception, because there was no method within the application to help guide the customer along the right path. Most users of the Web site became extremely frustrated with the site and never rented a buggy again.

The head of marketing within Adventure Works travel group was also very frustrated—knowing that the competition was doing big business on the Internet, and that the IT team within Adventure Works said that the Web site "works just like the reservation process." It made sense to everyone within Adventure Works; also, they had been doing this for such a long time, that there could not be a problem with the internal application! No one really had a good idea of why the site was not as successful as everyone thought it should be.

A Collaborative Rescue

Our team was called in to the Adventure Works Horse Buggy Rental Company, and we were asked to see what we could do to improve the process. The normal process of gathering technical, functional, and nonfunctional requirements ensued. Alongside of the technical team, the information architects worked with the customer to help understand users, personas, business processes, and exceptions to how the rental process really worked. Current and past users of the Web site were canvassed for their opinions on what mattered to them the most. We even talked to the guy behind the rental counter, to get the "real skinny" on what happens in a horse-buggy-rental process.

While the technical team was busy formulating use cases and gathering API documentation, the information architects, creative directors, and lead solution architect created site-navigation flows and storyboards that would walk one of five selected "typical user types" through the site to validate that all of the functionality and flow was there.

One key perspective to remember here is that the team worked in concert. The creative director would come up with a very new and different way of thinking about the reservations process, expressing something that was technically exhausting to develop. Initially, the marketing director at Adventure Works really liked the idea, but the architect had to help point out that it would take a long time to ensure that the vision would work according to the design. To get the project back in check and reduce complex coding, the software architect would work with both our creative director and the Adventure Works marketing director to come up with an achievable alternative idea.

In another conflict of creative friction, the technical team would take the happy path on the application only to have the information architect pull the reins back and point out where it did or did not make sense for the user to follow a specific path, because of either common-sense usability or business-rule violations. We leveraged the creative friction to keep each other in check, to best produce the most usable, rich, and technically correct application possible within acceptable project parameters.

Prototyping and Testing

Considerable time was spent hashing out the "correct" way to have the user make a reservation, given the constrictions of the results of the rental-request process. One of the things that the team came up with was a way to manage state within the reservations process, as something that was going to be managed by the Web site.

Paper "prototypes" and storyboards were created to walk through the known scenarios and validate the various permutations and combinations, with all of the contributing audiences involved. As soon as these were complete, and we got as much input as possible from the folks who "really know what's going on," we created a working prototype application that faked a lot of the backend API calls to simulate what really would happen in a browser.

The prototype application and the created artifacts were shown around the company—receiving input from the reservation-system administrators, customer-support folks (the ones who would get the calls from frustrated users), buggy-rental counter people, and key customers whom the Adventure Works marketing department had identified. Feedback was taken and re-swizzled back into the key parts of the design.

Just to reaffirm that we came up with the right design, we then presented some test-key end users with the prototypes and static designs, and got their feedback. We used focus-group–type information-collection events, as well as individual interviews that were led by both the IA and quality-assurance (QA) team members. One last time, we used the input of end users to polish the rough edges of the designs and use cases, and started the coding phase of the project.

The resultant published work was really impressive. It managed reservations state in a stateless manner; allowed the user to pick any one of four tabs to enter information, in any sequence; and also did some basic parameter checking, to make sure that the reservation-request packet that was sent back to the system would not violate any known rules of messaging. Depending on either the user input or the system-reservation request result, conditions of "success" or "failure" were indicated on the tabs by a green check mark, a red exclamation mark, or a yellow triangle. This way—in case that a change of any of the parameters of a reservation request was successful or not—the user immediately knew which tab to go to (to change information to satisfy the reservation request) and could make edits without having to start over. Any invalid request would give the user a human-readable error message, allow the user to correct only that one section that caused the error, and resubmit the complete packet until a reservation was successful and ready to commit.

These user-experience design artifacts were used over and over again to help keep the technical development team, creative team, and customer in sync through development and all the way through testing and acceptance.

The reservation tool was published onto the next revision of their Web site, and the result was a 500 percent increase in successful reservations over the next six months.

Put the User First

Now, the moral of this story was that we put the end user first in the design and thought process of the site, and we really paid attention to both what the end user needed and how the end user was to experience the site. While we did concentrate on the technical delivery of the application itself, we "led" the process from a user's perspective.

The payoff was that the loyal users of the Adventure Works Horse Buggy Rental Company started using the site more and more to reserve, and moved from higher-cost rental-entry points (reservation agencies, 1 800 customer-support lines, and so forth) to the Web as a lower cost alternative. The company then started using the Web as another advertisement platform—showing the users specials, encouraging customers to rent more, and up-selling them to either other promotional specials or better buggies.

Becoming Expert in UI

Going back to my original point: As I was coming up through my IT career, there was no formal or informal training on how really to take the user into consideration for the projects on which you were working. We were well-prepared technically, but actually going through the process of "walking in the user's shoes" was not part of our skill set. While some colleges are now taking the lead by integrating a few courses on user experience within the computer-science discipline, others are deferring to get into this level of specialization until the Masters level or higher.

Learn by Doing

So, to answer the question that I'd posed earlier—"Where do you get this experience?"—you must stretch a little by researching and engaging the skills of people who are well-versed in this area, and learn by doing.

Take Courses

If you are lucky enough, you might have a university nearby where you can take an advanced degree in information design, which might involve the departments of Computer Science, Psychology, and Mass Communications.

Go Online

Search online for user-experience, information-architecture, and user-interface topics. There is a lot of relevant comment, opinion, and articles in this area; so, finding good material now, outside the boundaries of traditional academia, is much easier than it ever has been.

Experience

The good news is that for those of us who have been around computers for a bit, user experience (UE) and user interface (UI) are very visceral: They either feel good or they do not. There are many great examples of what good UE and UI look like, and many more bad examples. So, making the analog comparison and having good examples to emulate should be easy to do. For more information, see the Further Reading section.

Using Tools

The other part of the UE process is soliciting good and relevant feedback from your users. Today, the tools exist, so that you—as the technical lead for a project—can put up a collaborative tool and allow your users to give you direct and immediate feedback on what works for them and what does not. Of course, being responsive to the audience and addressing their needs quickly are key parts of this audience interaction. Being able to tell them definitively that their issue is reproducible, valid, and valuable in a rapid manner goes a long way in gaining the loyalty of your user base. Also, using configuration-management tools and bug trackers that are visible to the end users allows them to see when their issues might be addressed. All of this contributes to a successful communication loop with the end user, and enhances the user experience greatly.

Conclusion

The UE should be thought of as a process that starts as early as when the project is conceived, and continues past deployment into revision and maintenance.

Critical-Thinking Questions

· Have you identified candidate users and types?

At the start of the project, do not just focus on getting raw requirements. While you are gathering requirements from the people who are responsible for the project, make sure that part of the requirements-gathering session involves identifying candidate users and user types. You can then take the characteristic of the users; mock-up the processes that they might want to perform on your application; and ensure that your application presents users with the right flow, interaction, and activities that are necessary for them to reach their end goals.

· Which parts of the application will be the most heavily used?

In the early design phases of your project, identify these areas of your application (think "heat map"), as well as the most technically complex ones. Do the use cases for these sections accurately represent 80 percent of the user conditions that could happen?

· Do you know any UE experts?

Engage others who have experience in the UE field, if only for the first third of your project—usually, the most design-heavy part of the project. As in all software development, catching UE/UI issues early in the design process is proven to be more cost-effective than trying to fix them while the application is in the final test stages.

· Can your mother use your application?

If you are really going for the widest base of users for your application (think something deployed on the Internet, as opposed to something deployed internally to your company), perform the "mom" test. If the system is simple enough for your mom to use, you probably have hit the target.

Glossary

Creative director (CD)—The person whose job it is to help bring visualization and creative vision to the project. Creative directors help bring about creative ideas, and they have a good knack at synthesizing visual information correctly.

Happy path—The central narrative of a user flow within a use case. It is usually the path that has no exceptions to be handled.

Information architect (IA)—A hybrid business analyst, and the person who has deep knowledge on user flows, navigational designs, information systems, user-interface application development, and human psychology. Information architects are responsible for synthesizing the processes and needs of the business that is sponsoring the project. IAs are responsible also for: understanding (and acting as an agent for) the types of users that eventually are going to be using the output of the project; being able to communicate that vision correctly back to the software architect, to help steer technical decisions; and helping to keep the creative design within achievable boundaries. If you are familiar with the Rational Unified Process (RUP) phases, most of the activities of the IA are within the Analysis and Design phases. In a nutshell, IAs are very technically-savvy business analysts.

About the author

Michael Martin is an Executive Consultant with IBM Global Services in Atlanta. For over 25 years, he has worked in the IT industry for IBM, Apple, GE, Attachmate, and DCA in the roles of developer, technical support, software architect, department manager, director of software development, and consultant.

This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.

Contents