Current Issue
User Experience Group Development and Integration - 26 February 2007
by Mike Rundle
Read this article in Chinese
(translated by Liang Zhang)
According to Peter Merholz, founder of the information architecture and usability team Adaptive Path, decentralized user-centered design (UCD) departments (brought about through poor organizational structure) are one of the main hurdles in front of good design (2004). With Product Managers being the only coordinating bridge between product groups, “design by committee” tends to be the only way for large UCD decisions to be made, and this tends not to improve the user experience (UX) but rather stifle it. With research done at the User Interface Engineering group, it appears as though the larger the organization’s user-centered design practice, the poorer the usability of its associated web-based user interface (Merholz 2004). This would appear to be a misleading statistic, however Merholz continues to explain how this happens by reasoning that the larger the UCD budget, the more likely the company is to break off the user experience team into a different group rather than work harder at UCD integration. By forcing the user experience group to be the “interface cop” before anything gets released, instead of being fully integrated within the product’s engineering lifecycle, Merholz states that it forces projects to go over budget and beyond the allotted time, and causes the company to ultimately lose money (2004).
User-centered design methodologies are not to be tacked on at the end of a product’s development lifecycle, but rather fully integrated within its development at every stage. Deborah Mayhew describes the usability engineering lifecycle in her book of the same name, and states “usability engineering provides structured methods for optimizing interface design during product development.” (Mayhew 1999). The trouble with pushing all projects through the user experience team right before they are shipped is that without UX help through all stages of development, there may be massive usability holes that are simply too large to be bandaged up. There comes a point when usability errors in a given interface cannot be fixed at the visual design level and may need a fully reengineered information architecture. These types of errors will force a product to miss development deadlines, which may cost the company millions of dollars in lost revenue (Garrett 2002).
When a company wants to make a certain segment of the organization better, usually they “throw more money at it” and hire more employees. The problem with doing this for a UX team is that people with overlapping skills and ideas usually end up hindering user-centered design rather than helping. Conflicting design decisions will soon turn into a design by committee situation that won’t help the consumer nor expose individual expertise (Brown 2004). User experience groups need to be flexible, agile, and scalable, and should only expand if the projects they work on are sufficiently large. The following is an overview of skills and disciplines needed for a successful user experience group:
The user experience group is an agile, interdisciplinary team formed by people who will always be looking out for the user when developing new products, and are also versed in the intricacies of various user-centered design methodologies. Instead of relying upon engineering and product specification teams to weave UCD methods into their development cycle, the user uxperience group would be called in to assist on many projects at any given time, and at every stage of development. This new user experience group would not sit atop the product development lifecycle, but would be integrated inside of each phase and would give “go” or “no/go” decisions at each milestone. The user experience of each product is completely in the hands of this versatile group, and in order to be proficient at this role, the competencies of each person in the UX group need to be well known. This new type of user experience integration is shown in the following diagram:
The major phases of a design project are shown here as the discovery, design, and delivery phases. According to the user experience group Interaction Design, each phase can also be broken down into smaller segments (2004):
The people in the user experience team structure outlined above can handle all of the major and minor stages in the UCD product development process. Before we can analyze how this user experience team fits within the overall context of the organization, the definitions of each role within the team need to be clearly defined.
Information Architecture — According to Louis Rosenfeld, author of Information Architecture for the World Wide Web, information architecture involves “the design of organization, labeling, navigation, and searching systems to help people find and manage information more successfully.” (2000) Information architecture, or IA, is high-level information design which lays out how a user will ultimately access information and knowledge from a system. An information architect can be thought of as the “system engineer” of the user experience team, which means that he or she is responsible for how content is grouped, what page elements need to visible or accessible at any given time, and other high-level responsibilities. The information architect works directly with the User Experience Group Director in order to translate business and user requirements into system prototypes, usually delivered via illustrations or diagrams of the system or process. A good information architect usually has a background that is slightly more weighted towards engineering rather than design, and fields a pragmatic view of information design rather than a creative one.
Graphic Design — The graphic designer takes branding and style requirements from either the external consulting agency associated with that company’s branding, or an internal design team, and develops the visual look and feel of an interface. He or she should have a background in communication oriented design rather than fine art, because at this position’s root, a graphic designer in the UX team is responsible for information getting from the interface to the user rather than the “creation of imagery”. The graphic designer (or visual user interface designer) is responsible for the final presentation end of an interface, and takes user interface design prototypes from the UI designer in order to develop final design prototypes. This is an interdisciplinary position,where the graphic designer will need to communicate with the marketing and sales team in order to project the company’s branding and style guidelines across mediums and products.
User Interface Design — The user interface designer develops wireframes and interaction design prototypes based on the work of the information architect. They will design what information is most important, how it is grouped visually with other information, and design how information will be accessed and flow throughout the system. The UI designer takes task scenarios and case studies from the human factors researcher, and applies qualitative and quantitative research to the user interface. The user interface designer also works directly with the visual/graphic designer in order to produce the full frontend interface. The teamwork of these two positions is vital for the user experience of the end product to be as usable as possible.
Human Factors Research and Usability Testing — These two competencies can be combined as one position if the funding for the team is insufficient, but in either case, this is the user champion position. A human factors researcher is adept at identifying the various usability and ergonomic problems associated with a given product or interface, and can give concrete and actionable advice to solve them. They are responsible for user testing, user scenario development, contextual research, and user interviews, and pass these results to the information architect and user interface designer in order for both to form good overviews of the system. The human factors researcher is the lead of the discovery phase of the design process, because the research generates the backbone upon which the full user experience can be crafted. This is not an entry-level position, but requires years of experience in human-computer interaction and ergonomic work, usability testing, ethnography, cognitive psychology, and psychological research methods.
Mike Davidson, Associate Art Director at ESPN in Seattle, believes that the ideal user experience group is its own unit between design, marketing, and development. “It functions best when it has no biases. On the design team, it has a bias towards the cosmetic and the aesthetic. On the development team, it has a bias towards cleanliness of code, and on the marketing team, it has a bias towards sales and revenue.”† The difficulty with a new user experience group is the positioning of it within the context of the entire organization. There is a correct and incorrect way to move the UX team to its own unit, and usually companies are doing it the wrong way by segregating the team from the product’s development lifecycle. The goal of moving the user experience team to its own unit is to do what Davidson says, and to eliminate bias that doesn’t push the user’s needs first.
The integration of user centered design practices within organizations is a relatively new subject, and this may be the reasoning why so many companies continue to get UCD so very wrong. If a company is not constantly aligning the development of its products and interfaces with the needs of its end users, then another company will, and they will consequently develop a better product than the first organization. It makes perfect sense: develop products that are inherently easier to use than your competitors, and there will always be a market for you, but the difficult part is redesigning your organizational structure to account for this new paradigm shift in product development.
Works Cited
Brown, Kyle. “Design by Committee.” C2. Aug. 2004. 21 Oct. 2004
<http://c2.com/cgi/wiki?DesignByCommittee>
Garrett, Jesse James. The Elements of User Experience. New York: New Riders Publishing, 2002.
ayhew, Deborah. The Usability Engineering Lifecycle. San Francisco: Morgan Kaufmann, 1999.
erholz, Peter. “Organization in the Way: How Decentralization Hobbles the User Experience.” Adaptive Path. 5 Sept. 2004. 20 Oct. 2004
<http://www.adaptivepath.com/publications/essays/archives/000351.php>.
osenfeld, Louis. “An Interview with Louis Rosenfeld and Peter Morville.” O’Reilly. 1 Jan. 2000. 23 Oct. 2004
<http://web.oreilly.com/news/infoarch_0100.html>.
hubin, Hal. “The UI Design Process: Delivery Phase.” Interaction Design. 2004.
24 Oct. 2004 <http://www.user.com/design3.htm>.
Quote from an Instant Messenger conversation, October 27, 2004.
Mike Rundle works Business Logs. You may also know him from 9rules, his other company, where he is the lead design guy. You can get in touch with him at mike [at] businesslogs.com, or 9rules.com.
He have lived most of his life in Upstate NY (Utica to be exact), lived in Chicago, Virginia, North Carolina, and New Jersey, and might be living in any number of places soon.
He is neither a designer nor a developer, but a person who exists happily in their happy medium. His interests include how people interact with their environment, and the communicative exchange that takes place at that junction. This leads him right into my main area of expertise — the user experience and interface design.
Comments made
Possible Related Articles:
Greg Scowen
I had an experience that is well described by this article while contracting to a large tertiary institute recently.
As more and more people were added to the UX team, and as management of that team failed to fulfill their role, the release date of the product was extended month by month. Before too long design decisions were being made (or not being made) via council meetings where 15 people got together in a room and had off-topic discussions that led nowhere.
Ironically enough when my contract came to an end (and their budget didn’t allow renewal) they were not much better off than when they started. Although I had introduced a lot of very helpful initiatives, these went through cycles of bureaucracy that never came to a close. I will be watching their product release with interest.
Edward Garaña
I found this post to be very well written and insightful into how user experience teams can become marginalized within companies if not properly setup.
I have been working in an interdisciplinary team like you described for a while now, and I will agree that it’s a very delicate balancing act to keep the UCD process integrated into the project life cycle on a consistent basis. It’s also incredibley hard to stay objective and customer focused and not get pulled down into the fray of the “short term goal” business objectives.
The one thing that I have learned over the years is to pick your battles wisely. If you try to fight to win all the user experience battles, even the very minor ones, people will begin to view you as a roadblock and begin to find ways around the UCD process.
Fight the good fight, but save your heavy ammo for when it really counts.