"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.
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." (Continued via Boxes and Arrows, Joseph Selbie) [Usability Resources]