Gone, thankfully, are the days when the user experience and the user interface were an afterthought in the website design process, to be added on when programming was nearing completion. As our profession has increasingly gained importance, it also become increasingly specialized: information design, user experience design, interaction design, user research, persona development, ethnographic user research, usability testing—the list goes on and on. Increased specialization, however, doesn’t always translate to increased user satisfaction.
My company conducted a best practice study to examine the development practices of in-house teams designing web applications—across multiple industries, in companies large and small. Some teams were large and highly specialized, while others were small and required a single team member to perform multiple roles. We identified and validated best practices by measuring user satisfaction levels for the applications each team had designed; the higher the user satisfaction scores for the application, the more value we attributed to the practices of the team that designed it.
We did not find any correlation with user satisfaction and those teams with the most specialized team members, one way or the other: some teams with the most specialization did well, and some teams did poorly. What we did consistently observe among teams that had high user satisfaction scores, was one characteristic that stood out above all the others—what we began to call shared, holistic understanding. Those teams that achieved the highest degree of shared, holistic understanding consistently designed the best web applications. The more each team member understood the business goals, the user needs, and the capabilities and limitations of the IT environment—a holistic view—the more successful the project. In contrast, the more each team member was “siloed” into knowing just their piece of the whole, the less successful the project.
All of the members of the best teams could tell us, with relative ease, the top five business goals of their application, the top five user types the application was to serve, and the top five platform capabilities and limitations they had to work within. And, when questioned more deeply, each team member revealed an appreciation and understanding of the challenges and goals of their teammates almost as well as their own.
The members of the teams that performed less well not only tended not to understand the application as a whole, they saw no need to understand it as a whole: programmers did not care to know about users, user researchers did not care to know about programming limitations, and stakeholders were uninvolved and were considered “clueless” by the rest of the development team. These are blunt assessments of unfortunate team member attitudes, but we were surprised how often we found them to be present.
We also observed that the best teams fell into similar organizational patterns—even though there was a blizzard of differing titles—in order to explore and understand the information derived from business, users and IT. We summarized the organization pattern in the diagram below. We chose generic/descriptive titles to simplify the picture of what we observed. In many cases there were several people composing a small team such as the “UI Developer(s)” or the “User Representative(s)” often with differing titles. Also fairly common were very small teams where the same person performed multiple roles.
Fig. 1 — Teams tend to organize in similar patterns in response to the information domains they need to explore and understand
Even this simplified view of the development team reveals the inherent complexity of the development process. The best team leaders managed to not only encourage and manage the flow of good information from each information domain, but they also facilitated thorough communication of quality information across all the team members regardless of their domain. Here’s how they did it.
Five Key Ways to Promote Shared, Holistic Understanding
1. All team members—all—conduct at least some user research
Jared Spool once wrote that having someone conduct user research for you is like having someone take a vacation for you—it doesn’t have the desired effect! On the best teams, everyone, from programmers to stakeholders, participate to some degree in user research. A specialist on the team often organizes and schedules the process, provides scenario scripts or other aids to the process, but everyone on the team participates in the research process and thus has direct contact with actual users. There is no substitute for direct contact with users. Interviewing living breathing users, ideally in their own home or work place, makes a deeper impression than any amount of documentation can duplicate.
2. Team members participate in work and task flow workshops
Designing applications to support the preferred work and task flow of the users—providing the right information, in the right features, at the right time—is one of the hallmarks of applications that get high user satisfaction scores. The best teams devote enough whiteboard-style collaborative workshop time to explore work and task flow (including in the sessions actual users when possible), until all team members truly understand all the steps, loops and potential failure paths of their users.
3. Team members share and discuss information as a team
A simple practice, but one which is often overlooked, is taking the time to share and discuss findings and decisions with the entire team. Too often teams communicate information of significant importance to the project through documentation alone or through hurried summaries. Even if it is not possible for the team to participate in all user research or in mapping out all work and task flow on a whiteboard together, at a minimum, the team should go through the results of these processes in sufficient detail and with sufficient time to discuss and understand what has been learned.
Direct participation is the most effective way to learn and understand. Full and relaxed discussion with team members is the second best. Reading documentation only is the least effective way for team members to retain and understand project information.
4. Team members prioritize information as a team
Not only is it important that all team members be familiar with information from all three domains (business goals, user needs, and IT capabilities), but it is especially significant that they understand the relative importance of the information—its priority.
My company developed what we call a “Features and Activity Matrix”, based on our own experience designing applications, and from the practices we observed in our study. The features and activity matrix accomplishes two things:
- The features and activities matrix allows team members to prioritize the proposed features and activities from the perspective of their own domain through a process of numeric ranking. Business ranks according to the importance to the business, IT ranks according to “doability” (measuring budget, resources and schedule against each proposed feature and activity), and the user representatives rank according to their assessment of what will make users most satisfied.
The numeric ranking for each feature or activity, from each domain, is then averaged to arrive at a consensus prioritization of every feature and activity proposed for the application. If, as is usually the case, the team is already aware that they cannot do everything that has been requested or proposed, this is a very effective way to determine which features and activities are not going to make the cut and which ones have the highest importance.
Fig.2 — Features and Activities Matrix. Note that we used a ranking scale of 1-5, 5 being the most important.
5. Team members design together in collaborative workshops
Once information from all three domains is gathered, analyzed, shared and prioritized, the remaining—and most powerful—practice to promote a shared, holistic understanding is to conduct wireframe-level, whiteboard-style, collaborative design sessions. Your session participants should include a solid representation of users, business and IT but not exceed roughly 12 people. In these workshops teams can work out together the basic layout, features and activities for most of the core screens needed for a project. These sessions can, and should, require multiple days. We have found that between 10 and 20 core screens can be considered, discussed, iterated and designed in 4-5 days of workshops.
Make sure everyone is fully engaged: business cannot be half committed, and IT cannot say that they will determine later if the screen can be built. All team members should be prepared to make real-time decisions in the collaborative design session. Inevitably there will be a few things that simply cannot be decided during the session, but the greater the shared, holistic understanding that already exists, the fewer things that will require processing and final decisions outside the session.
A well prepared collaborative design session both promotes and leverages the team’s shared, holistic understanding of the project. Even though they are time consuming, collaborative workshops eventually save time because the team ends up needing less iterations to refine and finish the design. Collaborative workshops also insure higher quality; there are fewer missteps and errors down the line because of the shared understanding of the design. Finally, collaborative workshops create great buy-in from business and IT. It is far less likely that some—or all—of the project will undergo unexpected or last minute changes if the goals and priority of features is clearly established during the design process.
Whatever the size and structure of your team, and no matter how many or how few specialists it has, your outcomes will be better if everyone shares a holistic understanding of the work at hand. Taking the extra time as a team to develop a shared holistic understanding pays off in greater efficiency in the long run—and most importantly—in greater user satisfaction and overall success!