6. Working with…

So far, we’ve described a rather idealized user experience design process, but you’ll find that real projects don’t run so smoothly. The design phases, neatly divided here into chapters, are fluid. You’ll find yourself flipping between phases, returning to supplement earlier work, and roaming through the project in your own way. This is natural. Although every designer follows his own skeletal design process, successful designers tweak their processes depending on context: the medium, the budget, the constraints, and their own personal style.

We’ve also presented the process in relative isolation. Colleagues, culture, and politics naturally make things messier. The human angle is critical to undercover UX design, and working well with others will prove as important as applying your design skills.

The easiest way to get along with others is of course to get to know them. There’s no substitute for spending time with people. Understand your colleagues’ personalities and outlooks and you can anticipate how they will respond to your work. You might even make some friends along the way.

However, getting to know people this well takes years, and you can’t wait that long to get started on your undercover UX mission. Fortunately, while individuals vary, certain groups within a business tend to share similar traits and attitudes. We caution against making sweeping assumptions about your colleagues, but considering their likely motivations, possible causes of conflict, and ways to arouse their interest in design will help you drive UX adoption.

* Working with Developers

The fields of design and development are yin and yang, complementary yet opposed. They rely on each other, and thus either support or damage the quality of each other’s work. Poor execution in development can ruin the experience you’ve worked so hard on.

Your relationship with developers is one of the most important you’ll form, but too often the relationship is characterized by tension and distrust. Fortunately, it needn’t be this way.

The Developer Mindset

Good developers are hardwired for efficiency. In their working practices, as with their code, they minimize effort wherever possible. Don’t mistake this for laziness. Developers work in a medium that rewards efficiency, and they look for the same rigor in the world around them. However, some developers may not appreciate that others don’t think the same way. Empathy is not always a developer’s strongest suit. Some developers will create an elegant code model, and then claim that this is all you need for a usable site. Designers know that revealing the innards of a system is rarely a sound choice, but it can be difficult to convince resolute developers. Even if you are able to communicate the UX benefit, developers may still resist compromising the code structure for what they see as minor improvements, giving the defense “it doesn’t work that way.”

Developers take pride in creating code that performs, scales, and most important, works. But strong developers also have a pragmatic desire to make the business’s ambitions happen online. Herein lies the perennial tug-of-war of web development: quality versus business pressure. Development teams are the punching bag of the business, forced to make last-minute changes by oversights or poor business decisions. To stay sane, developers have built up defense mechanisms and resist anything that prevents them working at their best. Faced with lack of involvement, project bottlenecks, or ambiguity, developers can take a defensive and even obstructive stance when estimating workloads and feasibility.

Most developers also harbor a keen dislike for arbitrary decisions. They will typically demand rationale before accepting a decision. You should therefore invite developers to design reviews and offer to answer their questions as they build the site. Many developers view building a site as a matter of finding creative technical solutions to business problems, and they’ll gladly contribute their thoughts on how the site’s design shortcomings can be addressed.

Getting Along with Developers

You will find it easier to convince developers of the value of UX if you view them as partners, not adversaries. Adept developers already appreciate the importance of user experience, and they’ll make excellent partners for your undercover UX efforts.

That said, be aware that developers don’t need UX designers. When the pressure to deliver is on, developers will route around any perceived bottlenecks, yourself included. The remedy is to make yourself indispensable to the development team, and make their lives easy in whatever ways you can.

First, involve developers early in the design process. Include technical representatives in your stakeholder research, and invite them to collaborative design sessions, usability test reviews, and so on. Not all will attend, but those who do could very well become more receptive to your ideas and spread the UX message throughout their team. Solicit developers’ opinions on feasibility early, and listen carefully to their responses. Finding out too late that your beloved design is technically unrealistic is hugely frustrating. Since developers are well versed in the capabilities of the system, they can quickly kill off nonviable ideas, and may suggest a better alternative.

Be ready to compromise on some details and fight for others. Given developers’ time constraints, they often question whether visual nuances like rounded corners are necessary. If you believe these elements will have a strong impact on UX, explain your case, but be aware that by sacrificing purely aesthetic choices, you may free time to focus on more important UX specifics.

Sit near developers if you can, so you can be in regular contact about deliverables, ambiguities, and progress. As you sketch out ideas, ask developers for their feedback, and discuss the format and fidelity of your final deliverables. Be sure to communicate design decisions, and subsequent changes to them, through design reviews or annotations to your deliverables. Without this communication, developers may be tempted to ignore your designs, thinking them arbitrary. In return, ask that they show you development work in progress so you can comment on any subtleties missing from the execution. Since developers often work at high speed, you might need to prompt them to share what they’ve built so far.

Developers spend much of their time coding defensively, ensuring the site can cope with unusual scenarios and a wide variety of user inputs. Therefore, pay attention to special cases such as error states and the behavior of the site for visitors without JavaScript. If site content is generated from user actions or input, what happens before this content exists? Have you fully described how results pages should work when there are no results to display? Have you explained how to paginate long lists? Have you defined hover states, and do your deliverables explain how to handle text treatment like bulleted lists? Inexperienced designers frequently overlook these details, leaving the developer to either make an educated guess or refer back to the designer.

Finally, to truly understand the world of the developer, step into their shoes. Decent HTML and CSS knowledge will open up powerful prototyping options and help you appreciate the possibilities and restrictions of modern web development. It will also give you insight into the complexity of your designs, but be careful not to second-guess developers’ estimates, and don’t make the mistake of asking developers to make a change “because it should only take 30 minutes.” Just like UX designers, developers operate within tight constraints, such as supporting older browsers, using existing code libraries, and accommodating specific technologies. Although HTML and CSS skills will help you discuss development tasks in the right way, the developer is the boss when it comes to estimation.

Taking the time to learn development basics will improve your effectiveness as a UX designer. You will learn to consider the feasibility of your designs, make swift decisions on trivial or impossible ideas, and design in modular fashion so developers can reuse code where possible. Learning the basics also has the pleasant upside of improving your standing in developers’ minds, turning you from a potential nuisance into a genuine ally.

Outsourced Developers

In recent years, many organizations have chosen to outsource web development to inexpensive overseas companies. Like many such cost-cutting exercises, outsourcing creates extra indirect costs. Without direct access to the developer team you will struggle to evangelize the role of UX in good development practice. Coding standards will instead be driven explicitly by the agreed contract and the documentation you provide.

Where development is seen as an entirely downstream function, the only way UX ideas can make headway is if they are baked into deliverables. Work at extreme detail and fidelity, so that the outsourced team has no alternative but to follow your instructions. Companies that outsource development make for a challenging UX environment. These organizations usually regard quality as a lower priority than cost, meaning the potential quality gains from great UX design may not be persuasive.

Moving from Development to UX

If you’re currently a developer, you’re well placed to make hands-on improvements to the site. If you think you can improve on the design you are asked to build, ask your stakeholders how it was reached. The decisions with which you disagree may have been oversights or deliberate choices. If there is scope to try something different, try building it the way you believe it should work—without spending too much extra time—and demonstrate the amended version. Explain why you believe your version is more effective, and the likely business benefits of the change. Lightning-quick corridor usability testing will strengthen your case. Your colleague may tell you to stick to the specification they gave you, but they may also welcome your help and agree to your recommendation. Keep this momentum up, and stakeholders will soon adopt the habit of seeking your advice on UX design issues.

* Working with Visual Designers

UX design can be conceptual. Spend weeks in the abstract realm of user needs, structure, and navigation, and it’s easy to forget that the job’s not done until the design is made visible. Enter visual designers, who give voice to our thoughts by producing detailed designs and graphics for the site.

A good user experience involves many elements that fall into the realm of visual design, such as aesthetic appeal, emotional response, and creating a strong first impression. Visual designers offer more than mere decoration; they can make your design speak with a visual language of its own.

The Visual Designer Mindset

Visual and UX designers lie at opposite ends of the same spectrum. Both are natural problem solvers, but while UX designers focus on the foundations of the design, visual designers concentrate on the visible surface. This role involves juggling many different elements, such as color, visual hierarchy, texture, shape, typography, and composition.

Designers with backgrounds outside the digital realm can bring fresh angles to their work, but unless they learn the medium, they may fail to grasp issues such as accessibility, onscreen legibility, and browser support. Most visual designers also favor a certain style of design and a particular fidelity. Some are most comfortable working with broad brushstrokes, creating vivid concepts and pushing in many visual directions. Others are uncomfortable with this level of ambiguity and are happier paying fine attention to the details of alignment, typography, and the grid.

Getting Along with Visual Designers

The litmus test of visual designers—as with UX designers—is whether they can articulate the ideas behind their design with conviction and rationale. Good designers accept feedback positively and invite others into the creative process. Bad designers view design as an act of solo artistry.

If you’re lucky enough to work with a top-notch visual designer, the partnership can be formidable. You’ll learn a great deal about design and your partner can improve the quality of your work through informal critique. However, if you work with a weak visual designer, you’ll find life more difficult. Work closely to improve the quality of your joint output, but if your ideas are being regularly ignored or squandered, you may have to adopt a more combative stance. Working at a very high fidelity gives a weak visual designer less freedom to make mistakes.

You should of course take the time to learn the language and theory of visual design. It will help you communicate with visual designers and make you a better UX designer, but remember that theory alone doesn’t make you a visual design specialist. Respect the boundaries between the UX and visual roles, and draw the line at the appropriate place for your skills and mutual comfort zones. Visual designers who work best at a conceptual level won’t appreciate being locked down by high-fidelity wireframes. Those who prefer to focus on detail will be uncomfortable working from a rough sketch. Generally, less experienced designers should create clear boundaries of responsibility, while experienced practitioners can step into each other’s worlds more comfortably. If boundaries do become a problem, causing UX and visual designers to tread on each other’s toes, adopt different approaches to fidelity and deliverables. A page description diagram (see Chapter 4) or a rough prototype may be more acceptable than a detailed wireframe, leaving the details of layout in the hands of the visual designer.

UX and visual designers should jointly own the design process, running design reviews together and regularly asking each other’s opinion on work in progress. When giving feedback on visual designs, adopt the same attitude you request from stakeholders, relying on reason rather than subjectivity. Ask your visual designer why she made the decision in question; the answer may be unexpected and enlightening.

Given every designer’s instinct to push boundaries, visual designers may occasionally underestimate constraints and suggest unrealistic solutions. Your stakeholder and user research will help you bring these ideas down to earth and steer the design down a more plausible path. You may also need to remind visual designers to concentrate not just on the “perfect” state of a page, but also on special cases such as text wrapping on long headlines, empty page states, and how the design scales at different sizes.

Moving from Visual Design to UX

Given the proximity of the UX and visual design fields, it is relatively easy for a visual designer to adopt UX techniques. The combined UX-visual role is broad, stretching all the way from research to the final design. You should therefore be adept with all aspects of UX and visual design, and learn to prioritize your work to avoid becoming overwhelmed. You’ll also need to know the visual design software of your choice inside and out to create both designs and UX deliverables quickly.

* Working with Content Specialists

Until recently, content has been the poor relation of other digital disciplines, downtrodden, forgotten, and under-resourced. Considering content provision someone else’s problem harmed the user experience cause, while bottlenecks, rushed content, and failed projects saw mediocrity triumph.

Fortunately, the pendulum is at last swinging back to its rightful place, where content is seen as a central part of the planning and design process. It shouldn’t have taken so long. Users come, stay, and return for content; and however fantastic your design, bad content will ruin the user experience. It’s therefore in your interest to help your content partners produce their best work.

The Content Specialist Mindset

Everyone thinks they can write. The web content specialist therefore faces difficulties you’re already familiar with, such as explaining the benefits of high-quality professional material over amateur work. The content-creation process and the design process are similar in many ways. Both UX designers and writers respond to an incomplete brief, shape ideas into an initial direction, and refine those ideas based on critique. Your content colleagues will have experienced many of the same pressures as you, and you’ll be able to swap countless war stories of unrealistic deadlines and unhelpful feedback.

Having been victims of bad process for too long, content professionals want the business to adopt new methods that allow sufficient time to audit, plan, write, and edit content in time for launch. Like developers, they dislike redundancy in both their words and their working habits; poorly planned work means more content to create, more pages to manage, and a confused message.

Getting Along with Content Specialists

Your first priority when dealing with content staff should be to improve processes together. Content strategists make natural leaders of this exercise, asking difficult questions about process and strategy. What should the site say? To whom? How often? They will also want clarification on how the organization judges content success. Does the business want to generate traffic? Or inbound links? Or customer engagement, measured through comments, sign-ups, or repeat visits? Pay close attention to the answers, since these strategic goals may be indistinguishable from UX goals. Try to ensure that your undercover UX work points in the same direction.

A writer can cover a topic in a hundred ways, so offer whatever user insight you have available to help them choose the best approach. Qualitative research outputs such as personas, along with any advice you can offer about users’ language and mental models, will help writers plan and produce effective text that appeals to and persuades the site’s users.

Content professionals can provide invaluable input throughout the design process. In the early stages, they can explain content requirements such as the nature of content you must accommodate (text, video, or images), its source (internal, third-party, or user-generated), and any points of written style to which you must adhere. Content specialists make natural partners for your initial content audits, and can act as judges of content quality. As you sketch out ideas, they can clarify the intended message and the calls to action of a page. The content team will also know what metadata surrounds their content—for instance, author, topic, date, and audience—potentially giving you new navigation approaches such as “More articles on this topic” or “Today’s most popular downloads.” Finally, ask writers what lead times they need to produce content of sufficient quality, and make sure they are brought in at the appropriate time. This may be before development starts.

Organizations that invest in content professionals usually provide them with a content management system (CMS). A CMS will introduce notable technical and process constraints to a project. Ask to be trained on the CMS to understand its capabilities, and learn how its workflows are reflected in the business itself. Attempts to bend these constraints, such as a large-scale content restructure, are typically doomed by hefty administration or customization costs, even if the software itself is open source.

Not all organizations have the luxury of a dedicated content team. Content is often written by marketing or communications teams, who are juggling dozens of responsibilities and aren’t web writers by trade. These people may not be able to lead the content cause in the way a professional content strategist might, but they’ll be glad of any improvements you can initiate.

* Working with Product Owners

Products—and their intangible cousin, services—are the things businesses offer their customers. If you’re working on a web application, this might be the business’s primary product. For example, the value of social networking sites, online email clients, and photo-sharing applications comes from the site itself and its features. Most of the time, however, the website isn’t the product itself; it’s a way to see, review, and buy products, which could be physical (books, for example) or intangible (loans).

Wherever the product lies within the business, it needs someone in the driving seat to make day-to-day decisions. In a small organization or startup, this may be the role of the managing director, but in larger companies this responsibility is delegated to a domain specialist. If you’re working in-house, this role is known as the “product owner.” If you’re an external consultant, you probably just call this person your “client.”

Large companies have many product owners, each responsible for a group of products that meet specific needs of specific customers. These groups are often known as “verticals.” For example, a publishing company may produce books for schools, universities, and industries. These verticals are likely to have different needs and different products, and hence have different product owners.

Even if product owners are not directly responsible for the website, they wield strong influence since the website is an important means of accessing the product and explaining its value.

The Product Owner Mindset

Product owners tend to be domain experts. They know the industry, its history, its market forces, and its trends, and use this knowledge to shape the development of the product and their entire organization.

Pressure is a fact of life for product owners, and their heads are often the first to roll in the event of failure. Product owners invest their emotions in their work, and may lose sleep thinking about ways to succeed in a competitive market. This emotional involvement is a double-edged sword. Product owners are deeply committed to the well-being of their product, but they can take criticism personally.

Product owners must articulate clearly what the product does, what need it fills, and why it is the right choice for customers. They should also have a vision of the future of the product. To conceive this vision, a product owner combines market and sales information with experience, ideas, and hunches. The vision may range from compelling and viable to wildly unrealistic, and from widely known to held solely in the product owner’s head.

Product owners typically embrace new ideas if they offer a way to differentiate the product. However, success can transform some product owners into risk-averse absolutists, driven by the fear of failure or losing face.

Getting Along with Product Owners

A weak product owner poses a formidable obstacle, but a smart product owner can bring your UX dreams to life. Get cozy with product owners and you’ll learn the inside track on the business case, competitive landscape, and market trends behind the products that make your business. You’ll also learn their personal motivations. Whether they’re chasing a promotion, a surefire success, or an innovative long shot, part of your role is to make product owners happy, particularly if they’re external clients.

It’s important to agree on a shared vision for the site as well as the product. Your product owner is probably the stakeholder with the most to say about the future, so pick their brains extensively in your research. As you move through the design process, air your own thoughts about the site vision, and try to reach a shared understanding of how the product and the site should look in a few years.

Product owners are often responsible for measurement; how else will they know if their vision has been achieved? Try to agree on objectives and metrics that represent both business success and UX success, so that you can weave good UX into the future of the product.

Your relationship with the product owner will influence your approach to fidelity and critique. Product owners are usually impatient to increase fidelity, since detail better communicates how closely the design will match their vision. Feel free to share low-fidelity deliverables that reflect the essence of the site, but be prepared to push product owners for their thoughts on these incomplete concepts.

As custodians of product features, product owners may also assume responsibility for website features. Ideally, their requirements will be based on a rational understanding of the business and customer environment, but they may be equally driven by a knee-jerk reaction to competitor activity. UX designers and product owners clash when one disagrees with the other’s analysis of the situation. Designers accuse product owners of being seduced by glossy features that are worthless to users, or of blindly copying competitors without considering the suitability of their approaches. Product owners accuse designers of refusing to accept business reality and putting their aesthetic preferences above the good of the product. Both arguments contain a kernel of truth. Stand up for your opinions, but try to minimize conflict by empathizing with a product owner’s viewpoint.

Although product owners may not officially outrank you, don’t underestimate the strength of their positions. They can and will overrule you, and will usually receive management support to do so. Product owners make a bad choice of enemy. Feel free to air your opinions, but be ready to cede minor UX points to stay on your product owner’s good side. Thankfully, good UX work usually appeals strongly to product owners. They dream of a desirable product that people love, buy, and tell others about, just as you do. Given the common ground, you should have little difficulty wooing your product owner. Once your relationship grows, you can amicably lock horns on important issues, and you might occasionally get your way.

Product owners naturally want to get involved in everything, so they can appreciate progress toward their goal. This energy keeps them driven, but it can also turn them into meddlers. Keep product owners away from the kitchen, and explain that they should focus on the “what” and leave the “how” to you. Don’t let them dictate your methods, and encourage them to give their feedback through official critique.

Research is a common cause of friction. Product owners may confuse design research with market knowledge, and their broad understanding of the market—what people are buying, the features that are most in demand, the actions of competitors—may lead them to conclude that more customer research is pointless. To make the case for design research, explain that their aggregate industry knowledge is useful when creating business and marketing strategy, but less valuable for design. Instead, you want to learn about individual behaviors and how the site and product will fit into someone’s life.

* Working with Marketers

UX design and marketing make obvious bedfellows, since traditionally most businesses regard marketing teams as the guardians of both customer knowledge and web strategy. The relationship is accentuated by the similarities between UX and the concept of brand. A misunderstood term, an organization’s brand is far more than just its name, logo, or promotional aesthetic. A brand consists of the associations, both rational and emotional, that ordinary people make with the company. While marketing teams can help to create these associations through advertising and careful consideration of how the company presents itself, brand is deeply affected by a customer’s personal encounters with the company—in other words, their user experience.

Brand equals user experience plus non-user experience; that is, it consists of your customers’ opinions and your potential customers’ opinions. These experiences are shaped by every contact someone has with the business: customer service, commercials, packaging, shipping, and yes, the website. In time you may choose to bring your UX focus to all these customer touchpoints, but for now, know that successful undercover UX work on the site will help to build a better brand.

The Marketer Mindset

Marketers thrive on research and data that add to their customer knowledge. They use this information to identify trends and capitalize on them, creating marketing messages and approaches that people will respond to. So that the scale of this data doesn’t become overwhelming, marketers combine their information-hoarding tendencies with a precise focus. They believe, as do UX designers, that targeting specific user groups is a more productive strategy than trying to serve everyone equally.

Marketers are aware of the persuasive power of content and design, and see the web as an excellent channel for connecting with customers. However, marketers spread their eggs across several baskets. This provides insurance if any channel proves ineffective and allows marketers to try new approaches with little risk.

Since customer awareness of a product and its benefits takes a while to grow, marketing is a game of persistence. Its practitioners need to keep banging the drum, but the results do come, with sufficient time and money.

Getting Along with Marketers

We’ve already discussed in Chapter 2 how to use market research within UX design. Marketing data can form the skeletons of data-driven personas, inform research recruitment strategies, and enlighten you about the demographic and psychographic makeup of your users. However, you should be aware of the limitations of marketing data, and it’s likely you’ll want to conduct your own research. Be careful when explaining this request. Never get into a fight with a marketer about who knows customers better; you’ll lose even if you’re right. Instead, position your requests for more research as a way to supplement marketing knowledge with personal stories and the human touch that helps you design for the individual user.

Marketing team members will want the site to demonstrate the company’s brand values, a set of simple principles and attitudes that encapsulate the organization’s personality. If these values have been embraced by the business, this is an easy task: features, content, and design will naturally reflect the internal culture. More commonly, however, brand values haven’t permeated the organization fully. In these cases, brand values are harder to express. Interview marketing stakeholders to learn how they wish to present the business, and explore the tone used in offline marketing material.

While brand values can help you create design principles and guide your design and content, a company’s brand values are often sadly indistinguishable from those of its competitors. E-commerce sites, for instance, all want to be known as quick, simple, trusted, and comprehensive. Without brave or even polarizing brand values, it can be hard to create a truly differentiated design. It’s easier to stand out by defying convention rather than following it, and a compellingly different set of brand values will help you design a more memorable site.

Businesses often run web redesign projects in parallel with rebranding exercises. On the surface, this can seem like a smart move: both sides can influence the other, and the refreshed website can lend extra impact to the new brand launch. However, concurrent redesign and rebrand projects can create their own difficulties. At worst, these dual projects grind to a halt, with neither team committing to their designs for fear of the changes the other will introduce. These stalemates usually reflect a lack of understanding of the teams’ roles and disciplines. In these situations, pause and revisit the groundwork. Both web design and brand teams should explain their processes, work conducted to date, and any areas of overlap that are worrying them. Try to end the discussion with clarity on the next steps and mutually agreed decisions on boundaries in responsibility. Ideally, each party should stick to their strengths. Few brand experts are also web experts, and web designers tend not to appreciate the many nuances of branding.

UX designers and marketing teams should anticipate disagreement on two specific sections of a website. The first is the homepage. Every design project must balance user needs and brand needs. A site that is too brand-driven will feel more like an advertisement than a useful site, but a site without any brand presence will struggle to explain why it matters. This push and pull is most keenly felt on the homepage. Expect your marketing colleagues to press to have key messages appear prominently, and expect that you will resist this attitude as overly pushy. Compromise and user testing are the only two reliable resolutions to this tension.

The second potential flashpoint between UX designers and marketers is user input. To marketers, sign-up forms are golden opportunities to gather extra data, allowing the business to segment and target users better. To UX designers, any unnecessary question increases the likelihood of user frustration and abandonment. Listen to marketers’ requests and then examine every potential question in detail to find out who will use the resultant data, and for what purpose. If the question is being asked more out of curiosity than for a compelling business reason, make a strong case for its removal. If there are still sticking points, you may have to A/B test a couple of versions of the form to compare the relative sign-up success rates.

Despite these minor differences of opinion, marketers generally hold UX design in high regard. Should you need to convince them further, look for ways to frame UX goals in terms of marketing targets. A good user experience will directly affect customer acquisition, retention, word-of-mouth referral, and loyalty.

* Working with SEO Specialists

At first glance, there appears to be little common ground between the disciplines of search engine optimization (SEO) and UX design. SEO is concerned with getting users to the site by ensuring the site can be found using the right keywords on the right search engines. UX mostly focuses on what happens on the site itself. Perhaps SEO specialists own the user before they reach the site, and pass stewardship to UX once they arrive?

There’s also an apparent philosophical conflict, with SEO professionals and UX designers pulling in opposite directions. SEO specialists want to optimize the site for machines—that is, search engine spiders—while UX designers want to improve the human experience with the site.

Fortunately, the views can be reconciled. Experience is blind to boundaries. It doesn’t begin when a user lands on your site, nor does it end when they leave. UX designers should take an interest in how someone finds their sites, and pay close attention to the seams between offsite and onsite experience. And while a few of the less principled SEO techniques can directly conflict with UX goals, reports of a fundamental schism between the two practices are greatly exaggerated.

Search companies want the same thing as UX designers—a web full of great sites that meet users’ needs—and search engine algorithms can be seen as an attempt to quantify the user experience of the site. What is the site about? Is it easy to navigate? Which pages are the most valuable? Who thinks this site is good enough to link to? Tellingly, Google’s self-professed number one principle is “focus on the user and all else will follow” (www.google.com/corporate/tenthings.html).

The SEO Mindset

The SEO industry attracts opinion like no other, and is lauded and vilified in equal measure. In recent years, charlatans have leapt onto SEO’s success and undermined the discipline through low-quality work and underhanded “black-hat” SEO techniques (see sidebar).

However, don’t be put off by the few bad apples. Avoid blanket prejudice and assume your SEO partners are the good guys. Quality SEO work shows excellent return on investment and gains serious traction in business.

Like UX designers, serious SEO specialists want good websites with findable, valuable content. It’s easier for an excellent site to place highly in search engine results than a mediocre one. All an SEO professional asks is that sites be designed and built with consideration for the needs of search engines. A search engine spider is in essence your lowest-tech user. It does not understand JavaScript, cannot interpret images, and blindly follows links until it gives up and goes elsewhere. If this user can’t use the site, your site will have search engine problems. SEO specialists therefore prefer well-defined site architectures, good metadata, and extensive links between content.

SEO professionals fear not having any influence over large architectural issues such as major redesigns, in which one careless mistake can undo many months of effort. In situations like this, the SEO team typically gets the blame anyway and is stuck with the difficult task of picking up the pieces.

Getting Along with SEO Specialists

Involve your SEO colleagues in information architecture work. They will want to see sitemaps and user flows, and will frequently suggest improvements or areas where your proposals could damage the site’s SEO potential. It’s generally desirable to create a unique page for every category and product (if that makes sense from a UX perspective), but watch out for structures that create large numbers of duplicate pages, which can carry an SEO penalty. Try to link extensively to key pages, perhaps using simple navigation items such as a footer or breadcrumbs, and fix broken links as soon as possible since they harm both UX and SEO.

The humble URL plays a large role in SEO. Start discussions about URLs early, since they’ll also affect information architecture and development strategies. Technical platforms and content management systems will have a strong influence on your URL structure: discuss your needs with developers to see what is possible. Generally, search engines prefer fairly flat hierarchies that include keywords in URLs. For example, http://sitename.com/products/x1-allegra-energy-saving-lightbulb is likely to be a better URL for SEO purposes than http://sitename.com/content/catalog/2010/bulbs/energysv/x1. Once you have agreed on a URL convention, include the intended URL as an annotation in your wireframes to ensure consistency. Watch out for dynamic sites, which can make developers’ lives easier but cause major difficulty for SEO specialists.

The quality and structure of developers’ code will also have an SEO impact. You may prefer to stay out of this conversation altogether, but if you are confident in your skills you may be able to offer insight on the page’s HTML markup. Spiders respond effectively to well-structured code, and give extra priority to page elements such as headers. To further help the visiting spiders, include alt attributes on images, and provide descriptive text for links.

Although UX specifics deep within the site are less relevant to SEO specialists, they will be interested in “seam” pages such as landing pages. Knowledgeable SEO input can help you craft better landing pages by explaining the keywords users entered to find the page.

Content decisions also have a natural SEO impact. Wherever you consult with your content colleagues, consider inviting a search specialist along. As well as knowing what a page should say, and to whom, it is helpful to know what search keywords people will use to find it. Writers may be concerned that SEO employees will ask them to stuff their content full of keywords to improve SEO performance; fortunately this practice is now deprecated and considered borderline black-hat. Well-written content naturally contains the right keywords, although your content team may wish to introduce a couple of alternative phrasings to catch searches for less common terms. Pay particular attention to page titles, which should be straightforward and descriptive.

Your organization’s SEO and search engine marketing (SEM) strategies can reveal a great deal about the user experience you should design for. What keywords will the site compete for? Do these represent the “long tail” of less popular search terms, or more expensive and competitive phrases? Are visitors likely to be looking for something specific, or browsing out of uncommitted curiosity? Consider whether your site design will suit the sort of user you expect to arrive from search engines, and whether SEO goals make sense in light of your design research. Consider adding keyword phrases to your personas, and suggesting useful keywords based on your site search analytics.

Due to the mutual benefits between the two disciplines, you may be able to smuggle UX improvements under the guise of SEO (with the search team’s permission, of course). However, driving traffic to the site is like pouring more water in the top of your funnel; it may simply amplify any UX problems you have and make your site’s leaks more obvious. It might be better to make the case for making UX improvements before turning up the search engine volume.

* Working with Senior Managers

Managers come in many varieties. Most commonly, you will deal with middle managers overseeing a specialized department, such as marketing or IT. They have disparate skills and outlooks, driven largely by their area of expertise. To understand them, look elsewhere in this chapter; we focus here on senior managers and executives.

Your interactions with managers of this level may be brief, but they count. Senior managers have the power to crush your fledgling UX movement—along with your morale—but they can also promote the cause in a way you only dreamed of. Help a senior manager to fall in love with UX and your quest is almost won.

The Senior Manager Mindset

We all know that executives are busy. They juggle many aspects of the business, of which the website is just one. They must shift their attention between pressing tactical concerns and complex strategic matters, without letting any issue blind them to another. It’s a pressured role. Their superiors, the board, and shareholders expect them to make the decisions that assure a company’s success.

A senior manager’s most precious resource is timely and concise information. They appreciate their employees getting to the point and presenting options backed up with supporting evidence. They dislike people making important decisions without their input, and equally they dislike being pestered over trivial decisions. However frustrating your undercover UX mission, resolve your difficulties without recourse to a senior manager. Airing your grievances will label you a troublemaker and undermine your cause.

Getting Along with Senior Managers

Make your interactions with managers as painless as possible. Give them the information they need to make a decision, and no more. Executive summaries are so named for a reason; give senior managers extensive reports and they will flick through but not read. Present managers with facts rather than speculation—customer research, analytics, and testing data will prove invaluable when explaining user experience issues.

There’s little point approaching a senior manager with only problems. After explaining the current situation, present potential resolutions and explain the benefits and downsides of each. Anticipate your executive’s likely questions and prepare concise answers, and your efforts will be appreciated. Become known as a diligent employee who gets to the point and does their homework, and you will be in an excellent political position. Earn a manager’s trust and they will consult you more frequently for advice, allowing you to slowly introduce them to UX. Like the rest of us, managers can be inspired by new ideas, so once you have a good relationship with a senior manager, try to pass on a little of your passion. Point out how other companies have solved long-standing problems through design and technology, in the hope that you will spark within your manager a lasting interest in UX design.

A manager’s time and information constraints mean there’s no need to expose the inner workings of your design process. As the economist Theodore Levitt said, “People don’t want to buy a quarter-inch drill, they want a quarter-inch hole.” Managers are largely unconcerned with how you achieve results, and an earnest explanation of the theory of UX will fall on deaf ears. Only explain the detailed UX design process to a manager if they ask (a sign that you may have piqued their interest). Senior managers will also show little interest in your deliverables unless they can directly see how they will affect the end product. Where you do need to seek their opinions on your deliverables, present as high a fidelity as you can.

This advice extends beyond deliverables to all your UX dealings with senior managers. While you may be motivated by value-led goals such as making better products that people will love using, senior managers care most about business performance. To make a convincing case, frame your UX discussions in terms of business benefits, such as:

• Reduced risk. UX practices such as research and usability testing can help reduce the risk inherent in all projects. Ask the senior manager, “How important is it that this site works right?” and use the response to make the case for reducing risk by spending a little more time consulting with users.

• Enhanced user knowledge. Executives appreciate the importance of understanding customers, since research reveals opportunities for more effective marketing, better product differentiation, and innovative product development. Senior managers can feel so wrapped up in the goings-on of the business that they feel isolated from genuine customer knowledge. Explain how your UX research techniques will teach the business more about current market and social trends, and help the business achieve better results from its web strategy.

• Better compliance. Regulatory compliance can be a powerful motivator. In some cases, poor user experience can cross the line of legality, invoking the threat of legal action. Accessibility concerns in particular are now heavily regulated, and related legal challenges are forcing even the largest companies to take action. If you notice an area where UX design could alleviate the risk of legal difficulties, make an urgent case and you may find your request is accepted with few questions asked. Not only can you reduce the threat of legal action, but also by designing for universal accessibility you ensure that the company’s services are accessible to all, increasing the company’s potential market.

• Time and cost savings. This argument may appear counterintuitive to senior managers who see design as a bottleneck that slows down development. However, robust research can reduce the time spent refactoring code later, thoughtful design can reveal straightforward development approaches, and thorough testing can resolve the ambiguity that often dogs the latter stages of a project. Time to market can be the factor that makes or breaks an innovative service. While there’s no such thing as a free lunch, you can save money if you eat a hearty breakfast.

You should know how to relate every weapon in your UX armory to a business benefit. If you can’t, spend some time working this out, and write down your conclusions. The benefit need not be directly quantifiable; brand perception and customer loyalty, for instance, are frequent outcomes of UX design. This exercise not only arms you with compelling ammunition for requesting UX work, but also attunes you to ways you can highlight the success of your work. Managers value employees who make a difference. Try to start your projects by showing some quick, noticeable results, and only then embark on the details of the full project. Measure the success of your quick wins, and if you save or earn the company money through UX, tell management. If you’re shy about your achievements, you’re only starving the decision makers of information that can help your cause. There’s no harm giving executives something to brag about, and it spreads the word of your UX success.

Senior managers will frequently make decisions that disappoint you. There’s a chance you didn’t state your case well enough, but it’s more likely that they had more information than you, or were subject to conflicting pressures. Don’t be disheartened if it takes a while to get senior managers talking about UX, and don’t get too carried away if you think you’re starting to make progress.

* Working with Agile

Finally, we come to not a role but a way of life. Over the last few years, the Agile mindset has taken hold in many digital businesses, and it is now a factor in many designers’ working lives.

Agile was born as a reaction to the heavy-handed and often impractical demands of so-called “waterfall” projects, in which businesses create software in discrete phases: research, design, build, and test .

Waterfall projects require design work to be completed before the site is built.

Agile replaces this serial process with a nonlinear method that encourages collaboration between departments and rapid, iterative design and development . Rather than specifying a system’s behavior in full before it is built (known in Agile circles as “big design up front”), Agile proponents select certain user journeys and develop the system iteratively, both building new sections and revising previous work.

Agile projects involve design and development working in parallel.

The growth of Agile has caused problems for some designers. The method’s origins lie in internal developer-led projects that paid little notice to design. However, contemporary Agile practitioners are eager to redress this balance, and introducing high-quality design into an Agile environment has become one of the largest intellectual and practical challenges facing the UX field.

The main cause of friction is that UX design and Agile reflect two different mindsets. UX designers are predictive. We want to make great systems by understanding users and their needs, and designing the right system for them. Agile adherents are reactive. They accept that change is an inevitable part of any project, and choose to develop quickly and accommodate rework where necessary.

Agile projects put extra pressure on design since they demand quick turnarounds; often only a week or two for each iteration. Some designers therefore claim Agile circumvents their processes, leaving no time to conduct research or agree on a coherent vision with stakeholders. Agile environments can also become heavily developer-led, leaving designers disempowered. These accusations are true to an extent. Agile methods make for a substantially different design environment than that of waterfall methods, and Agile designers must find ways to work quickly, take the odd shortcut, and push in UX techniques wherever they can.

Fortunately, that’s what this entire book is about. Every undercover UX technique is compatible with Agile methods, and we contend that designers have nothing to fear from the Agile mindset. Undercover UX design requires a quick, results-driven approach that embraces occasional ambiguity in the knowledge that iteration will smooth out the kinks. The only appreciable difference with Agile methods is that Agile brings development into this iterative cycle. Instead of iterating on deliverables, designers iterate on a real site.

Agile brings the many people working on a project into more visible contact. It advocates cross-functional teams in which every employee understands each other’s role and solves problems collaboratively. This open communication makes it easy to assert the benefits of UX design, and gives designers unrestricted access to the partners—developers, product owners, visual designers, and more—who can make UX ambitions a reality. The old “us versus them” mentality won’t fly in an Agile world.

Tips for Agile Design

The first thing to realize is that Agile is chiefly a mindset, not a process. The mindset commits to building software early, to testing marginal decisions by putting them live and watching what happens, and to free communication based on conversation instead of documents. The techniques that surround Agile—such as pair programming, daily Scrums, and user stories—are merely artifacts of this mindset. Try to become comfortable with the Agile way of life rather than focusing on specific techniques. Just like our undercover manifesto, Agile prefers a good product today to a great product next year, making perfection even less realistic. Instead, strive to make pragmatic design decisions, and take comfort in the knowledge that you can rework areas that don’t perform well.

Although Agile projects don’t allow much time for up-front research, you can negotiate a decent preparation window by starting with an “iteration zero.” This is a short phase at the start of the project that precedes any development. Developers often use this time to set up development environments and work on back-end functionality like setting up databases. Use this time to conduct some quick interviews or surveys so you can create some simple personas. Present these to your team at the end of the iteration zero, and substitute your personas into your user stories.

The iteration zero will undoubtedly leave many questions unanswered, but you can conduct more research once the project is underway, using the dual-purpose session discussed in Chapter 5.

The Agile mindset eschews all but essential documentation, preferring direct communication between team members. Choose your deliverables carefully, omitting any that aren’t entirely necessary; make low-fidelity your default; and consider your deliverables to be fluid documents. Although you won’t be designing the entire system in advance, you’ll typically design the coming iteration’s work while supporting developers as they build the current iteration. Try not to fall behind and become a bottleneck or, equally important, get too far ahead, since your work might be wasted. The design effort required for each iteration will vary, which can make time management a challenge. Agile iteration plans are usually based on developers’ estimates of upcoming work; try to establish a similar estimation process for your UX work. Nevertheless, some iterations will prove particularly frantic.

To ensure a coherent vision throughout the project, you should appraise continuity from time to time. Review the site at regular intervals (try to squeeze in quick user testing, too), and judge whether the site experience is consistent across the site. Agile is iterative, not just incremental, so if you notice UX problems with previous versions, raise them with the team and put the user story back into the backlog so it can be revisited.

Popular though it may be, the Agile mindset provides no guarantees. Successful Agile needs experienced teammates who not only excel in a fast-paced environment but also collaborate effectively with other specialists. Fluidity is essential. In Agile teams more than ever, you cannot act as the sole custodian of UX. Although you should be the final decision-maker on UX design issues, you should involve the whole team in the design process, using the collaborative techniques discussed in Chapter 3. The best Agile teams are multidisciplinary and multiskilled. At these levels you may even spend some of your time coding, writing copy, doing visual design, and so on. The future of Agile will see everyone pitching in and playing well with others.