2. The Project Ecosystem: Planning for Project Needs, Roles, and Culture

Are you about to start a brand new project? Or are you in the middle of one? Either way, take a moment to consider the dynamics and context of the project—the issues that will affect you and the rest of the project team. What type of sites or applications are involved? Which roles and skills are needed? What is the company culture? Answering these questions will help you define the project and ultimately determine the tools and skills you need to bring to the table to be successful.

Carolyn Chandler

Each project has its own unique challenges. If you’re designing websites or applications, many of those challenges will involve specific features and functionality, such as building a method for a user to share photos with friends and family online or restructuring the information in an intranet so that content can be more easily found and shared.

Around those specific design goals, however, all projects have a larger context that you need to understand and integrate into your planning. This context is the project’s ecosystem, and it includes the environment you’re working within (the company culture), the general type of work you will all be engaged in (such as the type of site you’re designing), and the people you’ll be interacting with (including their roles and responsibilities).

If you take the time to understand the project ecosystem, you’ll have knowledge that will help you throughout the project. You can communicate your responsibilities and ideas more effectively, and you can help others on the team anticipate project needs they may not have considered.

To help you, this chapter identifies different types of projects you may work on, as well as the roles you may play, the people you may depend on and how their involvement tends to vary by the type of site or application being designed. Finally, the chapter discusses some elements of company culture that may affect how you work during the project.

Identify the Type of Site

Although no black-and-white distinctions exist between one type of site and another, some relative differences in site focus and characteristics are identifiable. Understanding these similarities and differences can help you:

• Set design goals for yourself. These are the general problems that need to be solved (such as “explain the company’s business model”) or the attributes that need to represented (such as “demonstrate the company’s responsiveness to its customers”) within the site’s visual design and interaction design.

• Solidify the primary objectives of the project (see Chapter 4).

• Understand which departments or business units may (or should) be involved as you gather business requirements (see Chapter 5).

• Determine the best methods for incorporating user research (see Chapter 6).

• Ask questions about which systems and technologies may be involved.

Your site will probably associate strongly with one of four types:

The next sections take a closer look at each of these types, discussing their characteristics and the impact they’ll have on your challenges during the design of the site or application. We’ll also discuss the most common crossover projects—e-commerce, e-learning, social networking, and mobile projects—which have characteristics of more than one type.

Brand Presence

What do you think of when someone says the word brand? Often the first thing that comes to mind is a company’s logo, such as the Nike Swoosh or the Coca-Cola script emblem. A company’s brand is much more than their logo, however; it’s the entire series of impressions that a particular person has about the company.

Dirk Knemeyer presents some excellent definitions of brand in his article “Brand Experience and the Web”:

Brand represents the intellectual and emotional associations that people make with a company, product, or person. That is to say, brand is something that actually lies inside each of us....

The science of branding is about designing for and influencing the minds of people—in other words, building the brand.

A company can do a lot to influence the associations made with its brand, from running memorable advertising campaigns to expressing brand traits (such as “responsiveness” or “value”) through the features and design of its websites.

All sites within a company are likely to have some impact on a company’s brand, either directly (by presenting a site that customers can visit) or indirectly (by enabling a key service that customers rely on, such as customer support). Brand presence sites, however, are the most focused on presenting the company’s brand messages and values. They provide channels that interface directly with customers and serve as a broad online funnel for those interested in finding out more about the company or its offerings.

A brand presence site is often the company’s primary .com or .org site, such as GE.com. For larger and more distributed companies, they are the primary sites for business units of varying sizes, such as GEhealthcare.com. Distinct product lines also often have their own unique brand presence online. For instance, Pepsico.com has one brand presence; while Pepsi.com has its own distinct presence.

If you’re working on a brand presence site, you’ll probably be designing for a variety of user groups, including current and potential customers, investors, partners, the media (such as news organizations and authors of prominent blogs), and job seekers.

Brand Presence Design Goals

The design goals that are often of most importance in a brand presence project are these:

• Communicate the brand values and brand messages of the company, either explicitly (perhaps a statement about the importance placed on being responsive to customer needs) or through the overall experience upon entering the site (such as ensuring it performs well and prominently offers features that encourage customers to communicate with the company).

• Provide quick and easy access to company information. You want to answer the questions “What does the company do?” and “How do I contact someone for more information?”

• Present or explain the business model and value proposition of the company: “What can the company do for me?” and “How does the company do it?”

• Engage a set of primary user groups and guide them to relevant interactions, functionality, or content.

• Help the company attain goals being set against key metrics, such as the number of unique visitors. Often this is one part of an overall marketing strategy.

Later, in the section “Choose Your Hats,” you’ll learn the various roles that may be involved in designing a brand presence site. For now, let’s take a look at the other types of sites you may work on, including one that has a close relationship with brand presence sites: the marketing campaign site.

Marketing Campaign

Marketing campaign sites are similar to brand presence sites, as both are focused on engaging users with an experience that influences their perception of the company’s brand. Marketing campaign sites, however, tend to be evaluated on their ability to achieve very specific actions within a set focus (such as within a particular time frame or with a targeted audience). Rather than serving as a funnel for channeling interest, they are meant to be the engines that generate interest. From an online standpoint this generally means they are aligned with an overall marketing strategy and may be run in conjunction with other marketing efforts using different channels, such as TV or radio commercials, print ads, and other promotions.

The primary purpose of a marketing campaign site is to create a narrowly focused campaign usually targeting a specific set of metrics. The focus is often narrowed by one or more of the following:

• Time—for example, a campaign centered around an event (such as a conference) or a season (such as the Christmas shopping season)

• User group—such as a campaign targeted to teenagers or teachers

• Product, product suite, and/or a specific use for that product—for example, a site that highlights kitchen appliances by showing virtual kitchens with matching ovens, dishwashers, and stoves

A campaign using a mix of these strategies would be a spring campaign targeted to selling patio equipment, combining time and product suite. Figure 2.1 shows an example of product suite and user group.

Figure 2.1 Texas Instruments used this education-focused microsite to present information on the company’s graphing calculators. The product suite is used primarily by high school and college students in algebra classes. The microsite maintained general ties to the Texas Instruments brand but was intentionally distinct in order to attract a younger audience and organize content and features according to their needs.

A marketing campaign site may be as simple as a banner ad leading to a landing page in the company’s .com site, or it could be a microsite, a small site that often veers away from the branding apparent on the .com site to provide a tailored experience according to one or more of the areas of focus. “Small” is relative here—some microsites have only one page and others have many, but either way the microsite is smaller and more focused than the company’s main brand presence site.

Marketing Campaign Design Goals

For the person or team responsible for designing and implementing a marketing campaign site, the design goals that are often of most importance are these:

• Generate interest and excitement, often by presenting a clear and immediate value proposition (the value that a product or service brings to the user, such as the possibility of quick loan qualification) or some kind of incentive (a special offer, entry in a contest, or entertainment such as an online game).

• Engage a set of primary user groups in order to elicit a particular action, such as clicking through to a specific location on a brand presence site, signing up for a newsletter, or applying for a loan. When this action is performed by a user, it’s called a conversion.

• Help the company attain goals being set against key metrics, such as number of unique visitors. Often this is one part of an overall marketing strategy.

Content Source

A content source site contains a store of information, potentially in several types of media (articles, documents, video, photos, tutorials), and is meant to inform, engage, and/or entertain users.

All sites and applications have some content, of course, but some sites place a particular emphasis on the presentation and structure of their content. The emphasis may come about because the site has such a large amount of content that it poses its own challenge or because specific types of content carry a high degree of importance; they might, for instance, support critical decisions or draw users back to the site frequently.

The primary purpose of a content source site is to increase user knowledge and self-sufficiency by providing relevant content (an intranet, for example). They often also encourage some kind of action, such as sharing information or purchasing a product after reviewing its description.

Content Source Design Goals

A content source site often has to do one or more of the following:

• Present content that is the primary draw for first and repeat visits to the site.

• Demonstrate a company’s thought leadership capabilities, for example, by providing access to ideas and perspectives held by the CEO or other subject matter experts within the company.

• Support critical decisions among the user base.

• Increase a company’s enterprise knowledge, by bringing out ideas that may be buried within individual departments. This may be part of a larger goal to identify more opportunities for innovation.

• Support users who are seeking information in different ways. For example, some don’t know what specific product they need yet (and are more likely to browse), while others may know exactly what they’re looking for (and are more likely to use a search field).

With regard to UX design, some of the tasks that are most common in a content source project are

• Creating a categorization structure that fits the mental models of your users

• Determining how to incorporate a system for organic growth of content (for example, functions such as tagging and filtering)

• Designing an effective search tool

See Chapter 8 for more on content strategy—the planning of content creation, delivery, and management.

Task-Based Applications

Task-based applications can vary from a simple calculator embedded in a mortgage site to a full system handling multiple critical workflows. If your project involves the latter, there will be more roles involved and, most likely, a substantial requirements-gathering process (for more on this process, see Chapter 5).

The primary objective of a task-based application is to allow users to perform a set of tasks that are aligned with their needs and, ultimately, with the client’s business goals.

Task-Based Application Design Goals

Most task-based applications need to

• Enable users to do something they couldn’t do elsewhere—or if they can, to do it better (“better” can mean more efficiently, more effectively, with a higher degree of satisfaction, or more conveniently)

• Support novice users with easy-to-access instructions and visual prioritization of key tasks

• Support intermediate and advanced users with access to shortcut features and deeper functionality

• Reduce the load on the user and make the best use of system resources (for example, reusing data versus requiring duplicate entries)

• Be designed and deployed with attention to the degree of change required of the application’s users—ideally, with a design that facilitates learning and a communication plan that demonstrates the value to the user

One of the biggest challenges of designing a task-based application is to keep “feature creep” under control. As a project is being developed it’s very common for great ideas to come up at later stages of the design, or even during development. User experience design is well suited to guarding against feature creep because user models such as personas can be used to identify high-value features and to keep focus throughout the project.

If a truly great idea does come up later in the process, and it meets the needs of a high-priority user group, and it aligns with the business goals of the site, your team may be able to build a case for changing direction. If an idea can’t make it through that wringer, it may not be worth the delay and cost.

E-Commerce Sites

E-commerce sites can include elements of all four project types, because a site that is primarily intended for e-commerce needs to have its own brand presence, provide content (usually product specs or descriptions of product usage), and facilitate tasks (searching, comparing, writing reviews, checkout). Marketing campaigns are often closely tied into these sites as well and may involve multiple marketing groups within the organization.

Common additional design goals for e-commerce sites are

• Explain the model for the site, if it’s nonstandard. As online marketplaces are constantly being reconceived, this explanation will help set expectations (for example, eBay, Amazon, and Craigslist have very different models).

• Support decision making as the user moves from learning to consideration to comparison to purchase, with helpful content and features.

• Make use of points in the experience where cross-selling and upselling is possible, and place those suggestions in a way that is eye-catching without being disruptive.

• Create a communication flow from the point of purchase through the point of delivery. Communication needs to happen not just within the site but also with other channels, such as integration with delivery tracking systems and e-mailed communications about order status.

E-Learning Applications

E-learning applications are crossovers between a content source and a task-based application. Content for lessons must be generated, which often requires that the team add the roles of learning specialist and subject matter expert (SME) for the topic being covered. The product is task-based in that the user usually follows a flow through the lesson and may also need to track progress or explore related topics. Some hands-on lessons may also require tasks to be completed.

Common design goals are

• Set an understanding of the baseline knowledge needed to start a course and who it is targeted to.

• Provide content in manageable chunks that are paced for comprehension.

• Engage the learner in activities that simulate hands-on learning.

• Communicate performance and progress and, if applicable, suggest next steps for continuing the educational process, such as more advanced courses.

Social Networking Applications

A social networking application is primarily a task-based application, because users need to be able to find and add friends, manage their profile, connect, post, and search. They also contain challenges associated with content sources, however, especially the need for an organic framework that can handle a potentially very large amount of user-generated content. If the site is essentially given its own identity, it will also have the characteristics of a brand presence site.

Common design goals for social networking applications are

• Focus potential users on the purpose and the values of the network.

• Facilitate meaningful user interactions that support, and are supported by, the features presented (such as image sharing, video sharing, and discussions).

• Protect the integrity of the site by ensuring those within the network understand how to control their information and respond to inappropriate behavior.

• Harness and display the power of the community to bring forward features that are only possible with active members, such as popular features and reviews.

Mobile Sites and Applications

On February 7th, 2011, International Data Corporation (IDC) announced that vendors had shipped over 100 million smartphones globally during the previous quarter. For the first time, smartphone sales had surpassed global PC sales, which came in at 92 million.

The explosion of availability and usage of mobile devices like smartphones and tablets has made them an increasingly essential part of company strategy and product planning, and an extremely important skillset for designers to develop.

Unfortunately, many companies still consider mobile an afterthought. More than one company has concluded a list of requirements for a larger web design project with three “simple” words: “make it mobile.”

When to Think Mobile

Thinking about mobile should occur at the same time it does for any digital project: when a user need or problem has been identified and can be addressed via digital means, or when the company wants to build a relationship with their customers. Perhaps the situation calls for a mobile solution and a PC-oriented solution won’t be as effective, leading the team down the mobile channel from the beginning.

If you are already planning a larger website project and know that a mobile channel will be an important aspect of it, consider designing the mobile experience first. Luke Wroblewski began the “Mobile First” rallying cry, based on these key points:

• The growth of mobile usage is explosive. This includes the number of people who have access to mobile devices, as well as the amount of time and number of activities performed on mobile platforms instead of desktops. Your user base may be much larger with a mobile device than with a desktop.

• Starting with mobile design creates constraints that make you focus on the essential data and actions in your product. With the availability of larger monitors for displaying desktop browsers, it’s all too easy to add cruft to your pages (advertisements, “helpful” tagging features, and other elements that can distract users from the actual content or functionality they’re looking for). The limited real estate of a mobile device forces you to consider the primary actions and make those actions stand out. This will help you design a better, larger view later when you have more real estate.

• There are exciting capabilities that mobile devices provide which aren’t as available or effective in PCs. This includes location-based services using precise locations determined from GPS, the greater availability of multi-touch, gestural interfaces, and accelerometer features that are sensitive to device orientation and allow for tracking a user’s movements (a great area for the healthcare industry to develop). Mobile devices also tend to be more deeply integrated with the user’s digital ecosystem, tying together common tasks with communication tools like phones and text messages, as well as scheduling tools. If project planning starts with a PC-based solution, these amazing capabilities are likely to be ignored or under-utilized during the “mobile optimization” process.

Mobile Planning

Once you decide to make a mobile audience a priority, you have another choice to make. Should you

• Build one website that looks good on multiple devices?

• Build a unique mobile website experience, in addition to (or instead of) a desktop site experience?

• Build a mobile application (for example, an iPhone app)?

Let’s look at each of these choices in more detail.

Let’s say you decide that you’d like to focus on creating one site that can adapt to multiple displays. You can do this by focusing on techniques in responsive design (similar terms you may hear are progressive enhancement or adaptive layout), which support the creation of flexible interfaces that expand or contract to make the best use of the real estate available (see Figure 10.6 in the chapter on Design Principles for an excellent example, or visit www.bostonglobe.com yourself to see it in action).

Ethan Marcotte, author of Responsive Web Design, provides an excellent walk-through of responsive design techniques, utilizing

• Flexible grids that expand or contract content based on screen resolution

• Flexible images that decrease in size on smaller screens or increase to a set maximum size on larger screens

• Media queries, which are elements of code that can be placed in a site’s HTML and stylesheet. These queries gather information about a device’s display capabilities and use them to serve up different styles accordingly.

Using these techniques can help you take one common site and adapt the layout to multiple devices, providing a flexibility that covers a variety of resolutions from smartphone, to tablet, to desktop browser.

However, a responsive design approach using a single site may not solve a key issue. Your users may actually have different needs when they’re using a mobile device—or, a mobile device may have capabilities that address their needs more effectively. For example, as mentioned in the previous section, mobile devices will have valuable information about a user’s location that may affect their ability or desire to use functions like maps. You could design one site that plans for both, and hide the code that doesn’t apply, but this can lead to slower-loading pages as unnecessary data downloads.

An alternative approach is to plan for and design a unique mobile experience for your users, focusing on the strengths of a mobile platform from the beginning and removing non-essential content (see Figures 2.2–2.4).

Figure 2.2 Cisco, the official network infrastructure provider for the 2012 Summer Olympic Games in London, created a series of digital products for the games. Here’s their mobile-optimized website. Notice the simple navigation and focus on a single, interactive piece of content (the “Game Readiness” quiz).

Figure 2.3 With the larger real estate available on a tablet, the tablet-friendly version of Cisco’s site provides additional navigation and content features, while maintaining a balanced use of space and avoiding clutter.

Figure 2.4 Cisco’s desktop browser version has the full view, with an additional column for sharing features on the left. Attempting to put all these elements in an iPhone version, or even a tablet version, would have been overwhelming—but these stages show a nice progression for each device’s real estate (http://www.ciscolondon2012.co.uk/).

If this is the direction you choose, you’ll need to make a choice of designing a mobile-optimized website, or a mobile application. Mobile apps, like those native to iPhones, Androids, and Blackberrys, have

• Currently, a better user experience than mobile websites (in general). With the constraint of devices, app designers have a greater degree of control over how their products are viewed and the interactions that result. The common app platforms (iPhone and Android, for example) have guidelines that help ensure a greater degree of consistency in interaction. As HTML5 and other web development tools close the gap, however, the differences between app and web experiences may become less pronounced.

• An easier method for monetizing the product (if that’s your goal). Purchasing an app is generally easy when it’s part of a store like iTunes. Providing users with the ability to purchase a web-based mobile site involves more involved integration, which you may need to take on yourself.

Mobile-optimized websites bring

• A greater degree of reach. Those developing apps are limited to specific platforms, like Apple’s iOS, and need to build multiple versions if they want to provide access via other platforms. A mobile website, on the other hand, can be viewed on any device with the appropriate web browser.

• In most cases, a more cost-effective solution. Because one mobile-optimized website can reach many more people, the cost may be substantially lower. In his excellent article, “Is Developing a Mobile App Worth the Cost?” Aaron Maxwell estimates that you can reach nearly five times the number of people per dollar invested, by going with a mobile-optimized website instead of multiple mobile apps (www.mashable.com/2011/02/24/mobile-app-dev-cost). There are companies that provide software that promises to help you build one app and deploy it to multiple devices (see www.verivo.com, for example). Tools like this come with their own constraints, so be sure to explore them before going down the path of an app.

Whichever path you choose, be sure to pick your target devices and platforms before you begin to walk down it. Those choices will constrain your design and impact your testing plans.

Mobile Design Principles

The great number of mobile devices can make design decisions somewhat daunting. However, the very fact of their mobility gives them some common principles that can help you focus. Julie A. Ask, VP at Forrester Research, has spoken often of these aspects of mobile solutions that give them such importance and convenience for users:

• Immediacy. Mobile devices are readily available and ideally provide immediate access to information that meets user needs. Following scores, looking for breaking news, and searching for answers to questions that come up in dinner conversation are all common activities that benefit from a focus on immediacy in product design. Consider the content or features that your users will need quickly, and then be sure to provide clear access and fast retrieval. Alerts, when used in a way that’s respectful of users (and can be turned on or off by them), are particularly effective when tied to location-based information (like nearby places or friends), or schedules.

• Simplicity. As mentioned previously, the smaller screens of mobile devices force a focus on a small set of clear options. They also lend themselves well to quick, linear tasks. Designing for simplicity allows users to treat their mobile device like a toolkit, fitting their unique needs when they need them. Ensure tasks completed on your mobile solution are simple, short, and effective.

• Context. Mobile devices have context on a user’s location, communication history, and past behavior. These elements can work together powerfully to anticipate user needs and provide relevant information, just-in-time. Solutions that take advantage of this are connecting people to their environment in ways that can feel like magic.

Context in particular is one of the most exciting ways that mobile devices differ from desktop experiences. Mobile devices literally go out in the world with their users—where they work, where they play, where they commute, and where they wait.

People who would never bring their laptop out when standing at a bus stop kill the time by using their phones or reading on tablets. These golden opportunities to provide useful, delightful, and engaging experiences will be missed by companies who do not consider the real-world context of their users. When designing for mobile, consider these in-between times, and explore your mobile devices users’ differences in need, attention, concentration, and physical interaction as their context of use changes.

Gestural Interactions

Gestural interactions are those that use natural user movements, like swiping and pinching with the hand, instead of (or in addition to) traditional interactions with mouse and keyboard. They require a touchscreen interface, and other hardware and software that can interpret one or more user touches and specific actions users will make.

Gestural interactions aren’t limited to mobile devices, and there are amazing interactions possible with full-body gestures, such as those with the Xbox Kinect or Nintendo Wii. However, the most common use of gestural interfaces can be found on mobile devices like smartphones and tablets, and should be a part of your considerations when designing a mobile solution.

Gestures are their own type of language and it’s still a bit like the Wild West out there when it comes to which gestures should have which responses. It’s exciting when you can create gestures that mean something to your users, but if you’re looking for guidelines that provide the beginnings of a standard, there are gestural patterns that are emerging with a good deal of weight and momentum behind them (Figure 2.5).

Figure 2.5 The simply beautiful Touch Gesture Reference Guide (created by Craig Villamor, Dan Willis, and Luke Wroblewski) provides a visual catalog of some of the most commonly used gestures for touch commands. The guide also features an outline that shows how popular software programs support touch gestures. Additionally, the guide is available in the form of handy flash cards. (www.lukew.com/ff/entry.asp?1071)

When designing gestural interfaces, make sure your interactive elements, like buttons and anything else that can be manipulated, are large enough for the digits needed to use them (one finger for pushing, two fingers for pinching, multiple fingers for a swipe, and so on). Testing is essential to understanding if your product responds in the natural way expected by users.

Identifying the type of site or application you may be working on during a project is only the first step. Next, you should consider the different roles that are often needed and how their involvement may vary based on the type of project.

Choose Your Hats

When you become the UX designer on a project, you often end up having to play several roles. Whether they’re formally defined within your client organization or not, the roles you will play depend on the type of project and the makeup of the rest of the team, as well as a client’s experience with each. It’s good to know which roles you’re already comfortable taking on and which you think you can learn on the job. It’s also helpful to find out what expectations others may have about the responsibilities covered by these roles. With this understanding, you can represent yourself more clearly from the beginning of the project.

What are the most common roles expected of a UX designer? Each client company you work for may have different titles for those roles (or no name at all, if it’s not a formal job in the organization). In general, you can expect to encounter the big three: information architect, interaction designer, and user researcher.

Information Architect

An information architect is responsible for creating models for information structure and using them to design user-friendly navigation and content categorization. During the design of sites and applications, common responsibilities include creating detailed site maps (discussed in Chapter 11) and ensuring that categories and subcategories of information are distinct and user-friendly.

Understanding Expectations

Within the UX field, distinctions are made between the roles of the information architect and the interaction designer (discussed next). At a particular company, however, there is seldom a common distinction between the two roles, at least when it comes to what is stated as a need for a particular project. For example, you may end up on a team with the title of information architect because that’s the historical term for the role, whether or not that truly fits your responsibilities.

Should you correct the project team if the title you’re given doesn’t match the main role you’re taking on? If this is a shorter term project (say, four months or less) and the title you have is widely accepted within the organization, with clear responsibilities outlined, it may not be worth the potential confusion you’d be introducing to try to change it. If there is no widely accepted title, however, and you think there’s a chance you’ll need both roles to be represented—potentially by different people—then it’s worth making a distinction early in the project when you’re planning your involvement and communicating your responsibilities.

Essentially, for more task-based applications it makes sense to emphasize the role of interaction designer, and for more content-based projects it makes sense to emphasize the role of information architect. But what may make the most sense of all is to use the term familiar to the client organization and ensure the team understands how you’re defining the role with regard to the responsibilities you’re taking on. This definition is something you’ll want to make clear in the statement of work (see Chapter 3).

The responsibilities of an information architect can also blur with those of a content strategist (see below, under “Other Roles”). If these roles are represented by different people on the project team, be sure to discuss how you’ll be collaborating at the beginning of the project.

Interaction Designer

An interaction designer is responsible for defining the behavior of a site or application in accordance with user actions. This includes flows in the site across multiple views and interactivity within a particular view. During the design of sites or applications, common activities are to create task flows showing interaction across pages or components within the site (see Chapter 11) and to create wireframes showing in-page interactions such as dynamic menus and expandable areas of content (see Chapter 12).

Understanding Expectations

If you’re working on a small team or on a project that isn’t highly focused on creating new task-based functionality (for example, if you’re working on a brand presence site that mainly includes some content categories, a contact form, and a sign-up form for a newsletter) interaction designer may be the main role responsible for capturing the project requirements (see Chapter 5).

If you’re working as the interaction designer on a project with a high level of new functionality, most likely you’ll have a separate person on the team in charge of outlining detailed requirements (for example, a business analyst or product manager). The process of gathering and detailing functional requirements can be helped greatly by the skills of a UX designer, and documents such as functional specifications and use cases are affected by experience design. Be sure to sit down with the person in charge of gathering requirements to discuss how you can best work together.

User Researcher

A user researcher is responsible for providing insights regarding the needs of end users, based on information that is generated from, or validated with, the research that person conducts with users. There are many types of activities that can fall into the category of user research, and they can occur at several points in the project timeline. (See Chapter 6 for a description of common techniques, such as user interviews, surveys, and usability testing.)

Understanding Expectations

The client company’s appetite for user research can vary immensely, based on the importance placed on it by the project team or the project sponsor. The fact that you’re talking to a project sponsor about UX design before a project starts shows that someone on the client team knows it’s a priority to ensure that user needs are represented. But as those who have worked on their share of computer-based projects know, introducing research can also introduce anxiety among project team members—sparked by concerns that user research will create a bottleneck, increase risk (What if we find something wrong, and need to make big changes to fix it?), or disprove the value of a particular idea that has gained a lot of momentum. The expectations for user research can vary between business stakeholders and the project team, so be sure to clarify expectations for the role with both groups.

The client may also expect the user researcher to provide insights based on site analytics—tools and reports that communicate patterns of use on the site, such as frequently visited pages and common points where users leave the site. Some of the most common analytics tools are from Google (www.google.com/analytics), WebTrends (www.webtrends.com), and Omniture (www.omniture.com/en/products/analytics).

You may find yourself taking on all three of these roles: information architect, interaction designer, and user researcher. Can you balance all three, or are you biting off more than you can chew? In part that depends on the size and timeline of the project, but the type of project also has an impact on how much involvement each role is likely to have. Table 2.1 (on the next page) describes how UX design roles can vary by project type.

Table 2.1 Common Responsibilities of the UX Design Role

Other Roles You May Play or May Need

Several roles don’t typically fall under the role of UX designer, but their responsibilities often overlap with the UX design role—especially if you’re working on a project where no one is officially playing the role and you have skills to bring to the table.

Some of the more common overlapping roles include

• Brand strategist or steward

• Business analyst

• Content strategist

• Copywriter

• Visual designer

• Front-end developer

The following sections look at each of these roles in more detail and discuss how they may vary depending on the type of site being designed.

Brand Strategist and Brand Steward

A brand strategist is responsible for building a relationship with key markets through the definition and consistent representation of the company’s branding elements, which can include anything from brand values (such as “responsiveness”) to guidelines for copy and messaging to specifications for logo treatments, colors, and layout. This role often entails creating or representing branding guidelines and understanding how they apply to different projects. It may also involve knowing or defining the target audiences of importance on the project you’re working on. For the most part, you’ll probably work with a brand strategist but won’t be taking the responsibility on yourself.

The brand steward doesn’t necessarily set the guidelines but is responsible for ensuring that they are followed appropriately during the project. This responsibility may be given to the UX designer or visual designer on a project.

If the company’s brand attributes, values, and guidelines have already been well defined and the site is expected to follow them, your role as the project’s brand steward will mainly be to ensure the result is in line with those guidelines. Your touchpoint outside the project would most likely be a member of the marketing department who is available on a consultative or review basis but is not on the team full time.

The brand steward role may be more active if the site is meant to extend the brand somehow—targeting a new market, for example. It’s most involved when a completely new brand presence is being created or when the company is making a dramatic change in its brand, effectively rebranding itself. For example, CellularOne rebranded itself completely to become Cingular, a major effort for an established company. In that situation you should either be very experienced in brand development or establish a clear and close relationship with the person at the company who is.

Key questions that will help you understand expectations around a brand-related role are these:

• Do brand guidelines exist already?

• If so, how closely do they need to be adhered to for this project?

• Who is responsible for setting or maintaining brand messaging, brand look-and-feel, and tone of content (such as casual or professional)?

• Are new audiences going to be targeted that aren’t covered by previous brand definitions? If so, who is responsible for ensuring the brand guidelines are still appropriate to those audiences?

• Will there be naming or renaming activities? If so, how should I plan to be involved? (An example would be creating a name for a new tool that will be heavily promoted.)

For projects that don’t have a large potential impact on customers’ perception of the brand, such as the development of an internal application, brand steward involvement may be as light as an occasional check-in to ensure the brand is being well represented.

Business Analyst

A business analyst (sometimes referred to as a business systems analyst on IT projects) is responsible for identifying key business stakeholders, driving the requirements-gathering process (see Chapter 5), and serving as the primary liaison between business stakeholders and the technology team. He or she is also the primary owner of detailed requirements documentation, such as functional specifications and use cases, if needed.

The role of business analyst or product manager may not exist on your project at all or it may be one of the most important roles through the design process. Task-based applications and content sources often have this kind of role; brand presence projects and marketing campaigns may not. A task-based application is most likely to need this role. The more features and the greater the complexity of the project, the greater the needs will be for a dedicated person and for documentation of functionality.

Although a business analyst is not typically considered a member of the UX team, small UX teams are often asked to fill the role, so it’s important to understand where these responsibilities lie. Business analysts drive the capture of business requirements, serving as the liaison between the technology team and the key business stakeholders. If there is a business analyst on a project, that person and the interaction designer are often joined at the hip. If it’s the same role, the person responsible may have a lot of documentation to keep up with!

To understand expectations in this area, ask who will be responsible for outlining the scope of the project, facilitating the discussions around requirements, and documenting requirements throughout the project. For small projects or those that are not heavy in functionality, the project manager sometimes will take on these responsibilities. Either way, if it’s not you, you’ll still know who you need to stay close to in order to ensure your deliverables are in sync.

Content Strategist

A content strategist is responsible for understanding business and user requirements for content in various media (articles, documents, photos, and video), identifying gaps in existing content, and facilitating the workflow and development of new content.

Content-related efforts are often underestimated. A client may have a large amount of content that’s wonderful in one medium (such as print brochures or videos), but that content may not be appropriate for the project you’re working on. Also, there are sometimes unspoken expectations that people within the client organization will generate content—expectations that may come as a surprise to those people when the time comes to populate your product with descriptions, news, and help topics! If high-quality content is a key business driver in your project, make sure you know who is responsible for the following:

• Setting content guidelines for the new product (type of content, tone, amount)

• Assessing the appropriateness of existing content against those guidelines

• Developing new content. This will vary based on general project type. For task-based applications, it may include instructional copy, error messages, and help topics. For content sources, it may include articles, news items, and blog posts.

• Serving as the stakeholder–technical team liaison to communicate the limitations and possibilities of the content management system

• Defining different content types as well as each one’s metadata (the information that ultimately makes searching and cross-referencing more effective)

• Planning for the migration of content, which involves creating templates for different content types and making sure content is tagged and loaded properly when it’s moved into the site’s content management system. (This is another area where the effort required is often underestimated.)

Copywriter

A copywriter is responsible for writing the text on the site that frames the overall experience. In some cases, this copy remains fairly unchanged from day to day. It typically includes site and page introductions or in-page instructions. A copywriter may also be involved in the ongoing creation of dynamic content, such as news stories or copy for marketing campaigns.

Copywriting is one of those gray areas that often falls to a UX designer, especially if wireframes are being created (see Chapter 12). You may initially put in sample text to serve as placeholder for copy such as a site description or in-page instructions, but someone eventually needs to populate it with the final text that will be seen by users—and because many projects don’t have a dedicated copywriter, this task may default to you.

You’re less likely to be asked to take on the copywriter role for high-profile areas of brand presence sites or marketing campaigns; in those situations each word may be given close scrutiny. But if you’re working on a task-based application that needs short instructional messages, error messages, or other types of information that don’t necessarily fall into a clear content bucket, you may end up inheriting that writing task (or it will fall to the developer by default). Ask upfront if a copywriter will be available, and ask again when you’re wireframing if one hasn’t been found. If the job does fall to you, be sure to include that effort when you’re planning your activities during the project. And be forewarned: This is a responsibility that’s often left out or underestimated.

Visual Designer

A visual designer is responsible for the elements of the site or application that the user sees. This effort includes designing a look and feel that creates an emotional connection with the user that’s in line with the brand guidelines. For example, a banking site often needs to appear stable, trustworthy, and accessible. The visual design can give this assurance through visual elements such as colors and imagery. That promise will then be kept (or broken) by the interaction design of the site and other touchpoints with the company (such as a call center).

Let’s be frank: A lot of people out there call themselves visual designers, web designers, or graphic designers, and a lot of sites have poor or only passable visual designs. There is a big difference between creating an effective, immersive, and emotional visual design and just getting by. Sometimes getting by is enough to meet the project objectives, and sometimes it leads to project frustrations and delays when the project sponsor is unhappy, or early users are not engaged with the design.

On the other hand, it can also be easy to focus too strongly on creating an impact with the visual design, allowing the usability of the design to suffer. If you’re being asked to take on this role and are unsure of your abilities to create the right impact for the client, take a look at the company’s current site and the sites or products the clients admire from a visual standpoint to assess your comfort level.

Visual designers often take a very central role in brand presence projects and marketing campaigns, having the primary role responsible for communicating the company’s brand effectively.

For content source projects, they may focus on creating content templates that can be applied to many pages (for example, a template for an article). For task-based applications, they may provide a style guide that can be applied to common interaction elements, such as navigation areas and tools (which calls for a high degree of collaboration with the interaction designer).

Front-End Developer

A front-end developer is responsible for building the technical structure behind the page designs and flows, as well as interactive elements within the site, such as rollover menus, expandable areas of content, and interactions with multimedia elements like video. This work often uses technologies such as XHTML, CSS, Flash, JavaScript, Ajax, and Silverlight. Front-end development focuses on the elements of the site that tie directly to what the user sees, as opposed to the systems on the back end that provide the underlying platform (such as databases, content management systems, and the code needed to build the functionality behind complex features).

If you or members of your team are taking on the role of front-end developer, close collaboration with the rest of the development team is important to understanding expectations and responsibilities. Other important questions include which back-end systems will need to be integrated with, the method used for generating HTML, the need for flexibility in page structure to accommodate customized “skins,” and the expectations concerning technologies such as Flash. If a prototype is being planned (see Chapter 13), ask who is responsible for developing the prototype and what level of functionality is expected. A prototype meant to simply communicate possibilities can be created quickly in an application such as Flash, but a fully functioning prototype that needs to pull real data (for example the account information a user just entered in a form) will need to be done in close collaboration with members of the back-end development team.

Worried about taking on all these roles? Unless you’re working on a very small project—or at a very small company—you most likely won’t be taking them all on yourself. The key is to understand which of the roles you are able and willing to take on, as needed, for the particular project you’re working on. For the rest, you can get the support you need on the project team by building a network within the client company or by recommending additional people to fill the needs. Let’s take a moment to talk about ways you can do this.

Building a Network of User Advocacy

For those areas that you’re not sure you can or want to take on, it’s time to start looking for help. There are three main ways you can go about doing this:

• Recommend additional team members be added, if the need is apparent enough.

• Educate yourself in key areas where there are gaps—if the new responsibilities are manageable and you have the time to dedicate to them.

• Build a support network within the company to help you at key junctures.

Let’s take a closer look at how you can build a support network.

There are most likely some key resources in other departments within the company that can help you be successful. You’ll need to gauge how much time you can rely on from these people, because requesting outsiders’ time can be tricky with projects that are primarily owned by one department. If you don’t want to ask for a large amount of their time out of the gate, just ask if you can partner with (or consult with) them to ensure the best result for the major responsibilities for that role. Once you’ve done some partnering you’ll have a better understanding of the amount of interaction you may need and whether you need to make a more formal request for his or her time.

Each company will have a different structure and different names for its departments, but here are some common places to look for partners:

• For the brand strategist role, ask if there’s anyone within the marketing department who can serve as your touchpoint. This may also be a source for visual designers and content strategists.

• Visual design and content strategy partners may also be found in program or product management or in the research and development, operations, or corporate strategy department, where you can often find business analysts and product managers.

• The IT or engineering department is often your best bet for front-end developers and others who can help you get access to and insight into tools for site analytics.

If you have recently been hired by a new company and expect to be working across departments, one of the best things you can do out of the gate is to identify key people who could be partners and schedule some interview time with them to understand their roles and experience. It starts you off with a network that you can often rely on for a long time and gives you the opportunity to explain your responsibilities (and user experience design in general). You can also ask a great question at the end of the interview: “Who else do you think I should talk to?” The answer can help you find people who may not be apparent to your main project manager or client contact.

If you’ve been at a company for a while, you can still initiate an interview schedule like this. In that situation it’s best to tie it to a particular milestone (such as the start of a new project) or a corporate objective that has some urgency behind it, to ensure high participation.

Make sure that your manager knows what you’re doing to avoid looking like you’re going around him or her. Good communication is key to understanding expectations about roles and building trust.

Another key to gaining trust within the company is to understand its culture, the often unspoken expectations of how a company works, such as those created by past project experiences (positive or negative), etiquette regarding organizational hierarchy, and acceptable work logistics (such as working from home).

Understand the Company Culture

Culture is a little like dropping an Alka-Seltzer into a glass—you don’t see it, but somehow it does something.

—Hans Magnus Enzensberger

A company’s culture may not be consistent across all of its regions, business units, or departments, but you can usually identify key characteristics that will affect you and the project or projects you’re undertaking. The following are some aspects that are good to keep in mind as you scope projects and navigate potentially tricky political situations.

History

We all know the quote that those who cannot remember the past are condemned to repeat it, and project work is no exception. Understanding how a project or team has gotten to its current state of need can help you understand the challenges you may face during the project.

Let’s cover some of the questions you can ask to understand the history that may affect a project. Although some of the answers to these questions may seem dire, keep in mind that something has triggered the need to bring you in on the project, so a project can have a rocky history and still be successful. Perhaps you’ll be a key component of that success! However, if many of the problems discussed below seem to apply, and you don’t feel you’ll be able to help address them, it may be a red flag. In that case, consider an overall evaluation of whether this project is positioned to succeed.

• What is an example of a past project that seems to have been considered a success, and what seems to have made it so? What is a past project that seems to have been a failure (or particularly painful), and why did it fail?

Asking these questions (either directly or in a more subtle, conversational manner) can help you understand a couple of things: how the person answering defines success, potential risks to your project, and any biases or expectations that will be carried through to this project, as well as approaches that worked well.

• Has the company worked with and released a designer on the same project or team?

If so, try to find out what didn’t seem to be working and how the client expects your approach to be different. If you can ask more than one person at the company this question, it will help you understand a lot about unspoken expectations. If you get two very different answers, it could mean the designer’s responsibilities weren’t well defined and you may need to ensure there’s a lot of communication about your responsibilities throughout the project.

• Has the project team been working on the project (or related materials) for what seems like an unusually long time without finishing?

If so, this could be a sign that key client stakeholders are not on the same page or are not being involved at appropriate times, causing multiple stalls, direction changes, or lost time due to multiple iterations. It may also mean there is not a clear leader, someone who can say no (or at least effectively prioritize) to keep the focus on business objectives. If you’re in a position to influence the communication on the project, it may help to create guidelines for participation to help move the project forward.

• Has the company created designs without the previous participation of a UX designer?

This can be a mixed blessing. On one hand, you’re dealing with a team that understands the need for design and has attempted to fill the gap. On the other, you may be given a design that you feel does not meet the project goals for the user experience. This can be a delicate situation to navigate. It’s often best to approach the creator of those designs with the tone of a respectful mentor or helpful consultant, pointing out the good aspects of the design first, then discussing user experience goals and how they may be better achieved with a different approach. The creator is likely to be a valuable member of your support network, so it’s important not to burn the bridge here, but to redefine your roles in a collaborative way to keep the enthusiasm alive.

• Does the main sponsor or project manager seem particularly anxious about the project?

There are many reasons this could occur, especially if some of the factors above are in play. Anxiety could also be due to market pressures that it would be helpful for you to understand. For example, has the company stock price been dropping? Has a particular competitor made recent alarming strides? Is the business operating in the red? Again, these situations do not necessarily mean you shouldn’t take the project on; after all, they’re the kind of situations that often get a project funded in the first place. But if you have a significant concern that the company won’t be able to pay its invoices, that’s a risk you’ll want to weigh.

Hierarchy

Geert Hofstede has an excellent model outlining differences in culture, what he calls “cultural dimensions,” that often affect the way people interact and communicate. One of them is the concept of power distance, which is the extent to which members of a society (in our case, a company) understand and accept the distance between people of different levels of power. For example, if members of a company’s executive team are viewed as particularly powerful and potentially unapproachable, a company may have a large power distance and its employees may be more focused on the hierarchy. If the company encourages a democratic sharing of ideas and questioning of vision, it may have a relatively small power distance.

Neither extreme can be considered good or bad in itself, although generally in the United States most employees seem to prefer the appearance of a small power distance in their workplace. What’s interesting to note is that this isn’t necessarily an indicator of how successful a company is. Apple has a relatively large power distance (if you consider the aura around Steve Jobs), and Google has a relatively small power distance as part of its culture, but both companies are known for being innovative leaders.

What is important to note is that the power distance within the client company will have an impact on how you successfully navigate the political waters during the project. This aspect will become particularly important at key points in the project: during requirements gathering (discussed in Chapter 5) and at key milestones such as sign-off points (discussed in Chapter 4). If you’re working at a company with a large power distance, take some extra time to understand reporting relationships before scheduling meetings such as stakeholder interviews and reviews, and consider involving more people at intermediate levels during your communications.

Logistics

In addition to the larger aspects of culture mentioned above, it’s also helpful to understand some of the elements that are more logistical in nature, so you can better integrate with current work methods or introduce change in a thoughtful way.

For example, it’s helpful to understand the general pace expected within the company, including key release dates or deadlines that will affect the project (creating a software application on a yearly release schedule would probably have a different pace than a microsite supporting a seasonal campaign, for instance). Will your team be expected to work late hours to meet looming deadlines?

Expectations regarding remote work versus on-site work are good to understand as well. If heavy on-site time is expected, you’ll need to plan for travel and resource setup there. If remote work is acceptable (or encouraged, which is common when working with global companies), it’s important to understand methods and tools of communication. For example, is use of instant messaging applications acceptable? What web conferencing tools are in use? Are there methods of including international stakeholders that have proven effective in the past?

It’s also interesting to understand the “paper culture” at a company. Some companies favor electronic media for most things, in which case a good projector and a consistent Ethernet connection is important. Others are very paper-centric, in which case you’ll need to make sure you bring enough copies to a meeting to make it productive. You may be able to change the culture of the project if you think another way is more effective. But it’s good to know that you’re asking people to change so that you can smooth the transition—and potentially understand why a particular approach isn’t working as you expected.

Pulling It Together

Now that you’ve explored the terrain of the project, you should have a better understanding of the project ecosystem: the environment you’re working within (the company culture), the general type of work you will all be engaged in (such as the types of sites you’re designing), and the people who you’ll be interacting with (including their roles and responsibilities).

This information will be valuable as you outline your role in the project and get ready to begin in earnest. If you’re working as a freelancer or subcontractor, it will provide a base for writing a proposal covering your work on the project (see the next chapter, which discusses UX proposals). If you’re working as a member of a larger team and are not directly involved in writing the proposal, you can take your new knowledge into the project kickoff—the first meeting of your team. For a basic guide to running a good meeting, see the chapter, “A Brief Guide to Meetings,” available on the companion website. Or if you want to get straight into the kinds of questions to ask when the project gets started, see Chapter 4, “Project Objectives and Approach.”