Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

February 03 2014

14:30

Designing Digital Strategies, Part 1: Cartography

As digital products and services come to comprise an increasingly important part of our everyday life, the division between the digital and the physical begins to blur. We can, for instance, see a washing machine on TV, read reviews of it online, purchase it on our phone, and have it installed by our local shop—all without leaving our computer. The sum total of these processes functions as a single, continuous experience. Designers can more prudently frame the experiences they create by incorporating ecosystem thinking into their process.

In 2011, the newly appointed CEO of Nokia, Stephen Elop, wrote:

The battle of devices has now become a war of ecosystems, where ecosystems include not only the hardware and software of the device, but developers, applications, ecommerce, advertising, search… location-based services, unified communications and many other things. Our competitors aren’t taking our market-share with devices; they are taking our market share with an entire ecosystem. This means we’re going to have to decide how we either build, catalyse or join an ecosystem.”

An ecosystem is the term given to a set of products, services, and people that function together in a symbiotic way. As an interaction designer working at a consultancy, I often meet clients who want to integrate all sorts of functionality into their digital solutions—email, Facebook, SMS—without really considering if that inclusion will actually add value for their users. Rather than unilaterally connecting all possible digital channels and launching a “family” of related products and services, designers need to determine ways in which ecosystems can act together in service of their client’s business goals.

Nike’s “plus” products work together to create something greater than the sum of their parts.

Designers do this through the creation of a digital strategy. Despite the fact that numerous voices suggest their creation, however, the actual details of creating one remains elusive. That’s where this two-part series comes in. In the first part we’ll review the elements that comprise an ecosystem as well as how to create an ecosystem map (a useful tool for facilitating a shared vision) by way of digital cartography. In the second part, we’ll see how ecosystem maps can be used to to develop digital strategies, helping companies fit together the various pieces that shape their digital puzzle.

The basics

The word ecosystem comes from biology wherein it describes a network of interacting organisms and their physical environment. From a technological standpoint, though, an ecosystem is better described as a network of people interacting with products or services. As Dave Jones defines them, ecosystems include:

  • users,
  • the practices they perform,
  • the information they use and share,
  • the people with whom they interact,
  • the services available to them,
  • the devices they use, and
  • the channels through which they communicate.

Ecosystem thinking, likewise, is the inquiry method used to analyze and understand ecosystems, both the problems they pose as well as the business opportunities they might present. Instead of focusing on a single product or service, however, designers who practice ecosystem thinking evaluate user behavior at the intersection of various inflection points. They ask:

  • Who are our users?
  • What practices do they perform?
  • What information do they need? (and where do they seek it?)
  • With whom do they interact?
  • What services are available to them?
  • What devices do they use?
  • Through what channels do they communicate?

Answers to these questions provide designers with all of the raw data they need in order to better understand the ecosystem in which they’re working. Turning that data into actionable information is the job of ecosystem maps.

An ecosystem map is simply a graphical representation of the relationships examined via ecosystem thinking. Ecosystem maps are closely related to other diagrams with which designers are likely familiar, including service blueprints, experience maps, and concept maps. They differ from these diagrams, however, in that ecosystem maps are optimized to aid in the creation of digital strategies.

A concept model that explains concept models (© Dan Brown, 2010)

Service designers Polaine, Løvlie, and Reason have arguably presented one of the best examples of an ecosystem map, however, without sufficient contextual knowledge it is difficult to understand the relationships their map presents between the “who,” “what,” “when,” “where,” “why,” and “how.”

That’s where digital cartography comes in.

Mapping an ecosystem

Digital cartography is an abductive, sensemaking process that, practically speaking, only requires time and permission to iterate. It boils down to five major activities:

  1. Understanding users and their goals;
  2. Mapping the activities (both known activities and “best guesses” as to the unknown activities) that users conduct in service of their goals;
  3. Mapping the information, services, devices and channels that users employ in service of their activities;
  4. Mapping the moments in which users perform their activities; and
  5. Narrowing down the discrete set of moments (or “experiences”) upon which the design team might focus.

The most useful outcome of digital cartography is not the map itself but the insights that the mapping process generates into the idiosyncrasies of users: their needs, their behaviours, and their perspectives. No map can really encompass the full complexity of an entire ecosystem; an illustration will always be a simplification of reality. However, the creation of simplified visual representations helps us to collaboratively forge paths in our digital world.

Creating a map

Like all user-centered design endeavors, digital cartography begins with research: interviews, observations, questionnaires, analyses of web site statistics, etc. This helps us to determine the goals towards which users are working as well as how users go about accomplishing their goals. Next we draw, or map, everything we know.

Don’t worry about getting everything right immediately. Ecosystem maps are useful both for structuring forthcoming research (finding out what needs to be examined) as well as for communicating the insights of the research that’s already been performed. Use a dry-erase board or a pencil and a piece of paper. It can also be useful to put the people and devices involved in a process, called actors, on individual post-it notes in order to move them around. This helps us to spatially reflect where actors fall in the process (left-to-right, top-to-bottom) as well as the relationships between them.

After spatially arranging the actors, have the team illustrate any/all of the activities undertaken by users as well as the information, services, devices, and channels they use for doing these activities. Next, cycle through the questions comprising ecosystem thinking: When do users perform activities? How do people send out invitations for, say, a birthday party? Who sends the invitations? How do they know who will come to the party?

It is easy to be overwhelmed with unknowns, especially in the beginning. Uncertainties (such as the order of certain events or the kind of channel that’s used for performing a specific activity), should be drawn as a “best guess” and marked with a questionmark for further investigation. Later, this information helps us to make a plan for how we can find out more about our ecosystem. For example, perhaps we could return to our research by conducting interviews with parents about how they usually invite children to their kid’s birthday party.

The final step is to determine the activities that our team will support through design. Not everything that is part of an ecosystem should be integrated into a digital product or service; it’s all about making strategic, informed choices. This helps us to distinguish “what is necessary” from what is “nice to have.” Moreover, it helps us determine which features might give our experience a competitive edge.

An example

Let’s continue using the example of an event-organizing application in order to illustrate how an actual act of digital cartography might unfold.

When organizing an event, people usually begin by discussing how, when, and where the event should take place. One person might take on the responsibility of securing the event space and sending out invites. Invitees might then contact the organizer to RSVP. Next, the organizer might wish to delegate tasks to the people who are attending (such as bringing stuff, preparing food and so on.) After the event, attendees might opt to send thank-you notes or share pictures from the event.

The ecosystem map, shown below, does not include all the activities that take place around an event, but it does include the more salient ones.

An ecosystem map for an event-planning application. I chose a circular presentation to indicate how the success of the app relied on repeated use.

The map also shows how activities are performed through the use of icons: invitations, questions and responses can be submitted through regular mail, e-mail, text message, in person, over the phone, or through Facebook. Timeframes for the various activities appear as green, dotted lines. In this case, I chose to use large timeframes as the timing varies a great deal across different types of events (planning a wedding might take six months, whereas planning a night out at the movies might take hours).

The inner circle of the map shows the activities that the app currently supports; the other circle shows what’s on our minds. Deciding what to do during an event and sharing photos are but two examples of countless activities that users might perform during the course of organizing an event. This division—what users do vs. what we support—is an excellent jumping off point as we formulate our digital strategy.

The map is not the territory

I have found the use of ecosystem maps to be very valuable when working with clients. I encourage readers to draw their own maps and share their experience of applying ecosystem thinking in their design projects.

Understanding ecosystems adds a whole new dimension to designing consistent user experiences across different types of media. So far I have explained what an ecosystem is and how we can draw ecosystem maps. Yet, it is not really about the map, but where it might take us. In the next (final) part of this series, we’ll see how to use ecosystem maps as tools, informing the creation of digital strategies.


The post Designing Digital Strategies, Part 1: Cartography appeared first on UX Booth.

December 03 2013

07:55

How to Breathe Life Into Personas

Personas are essential when you are working on a project and don’t know the target audience very well. For instance, not every designer has experience in fashion or banking. Creating a model of your target audience may help you and your stakeholders feel significantly more empathy for those people.

Personas can also help you get out of the mindset of thinking about users abstractly. “User” sounds like it does not refer to real people who have desires, concerns, past experiences. When real people use your app or website, they are there to reach their goals: to buy something, to research, to register for something they need, or to get information. How can we design something helpful for them without feeling empathy?

Thinking about users as “just users” is just plain harmful. Empathy for the real people who use the website or app, on the other hand, is essential. If we have empathy, we will not design something that would make these people feel trapped, cheated, or confused.

Humane personas

Using  personas enables us to feel more empathy by creating a life-like humans we want to make happy. The problem is, most personas are not designed to make the reader care about the person. Most of them look like dossiers: name, occupation, age, sex, some descriptive text, and a Google image search photo.  Why would anyone care about a persona that looks like a PowerPoint slide?

A usual, dossier-like persona.

A usual, dossier-like persona.

We should also always keep in mind that stakeholders are also “users.” We have to make our deliverables real easy for them to understand.

I wondered: What would make my personas more humane? The bullet-point personas really made me feel ashamed as a designer. I was sure that these deliverables would not reach their desired goal which is to put me and my stakeholders into the mind of the people who use their web site. So why do them that way?

Making life-like personas

The humane speech bubble persona

What would make my personas human? I made some concepts, researched, tested, and refined again.

I started to look for a solution. As a good UX designer should,  I did some Google searching, sketched, and then fleshed it out. I went through many versions until I found one I was happy with, and response from project teams seems to be positive. I think these deliverables can be developed further, though. I call the result the Humane Speech Bubble Persona.

Where a traditional persona would list attributes in bullet points, I had the persona tell his own story, in speech bubbles.

The key bubble is the worldview. It represents  the central attribute that tells us who our person is, summarizing the person in a single bubble.

Worldview speech bubble

Worldview speech bubble

Then I added bubbles with attributes like “motivation,” “looking for…,” and “desired experience,“ which help us focus on the goals of the person. Adding the opposite of these, such as “demotivation,” “not looking for,” and “last experience,” is also beneficial. Finally, I added the persona’s questions. This helps us focus on the needs and concerns of the user.

The unsolicited insight that comes from an overheard conversation means you get useful information that wasn’t meant for you. The bubbles recreate that experience for the users of the persona.

Presenting text attributes in speech bubbles make the persona humane as well. Speech bubbles show the person speaking, in easy-to-follow sound bites. This makes the persona scannable and adds some fun to the deliverable.

Finally, to make the persona more scannable and relatable, I added pictures from the persona’s imaginary life to help us visualize the persona as a human being. The pictures represent both current as well as desired objects that the persona cares about. As well, when personas are hanging on a far-off wall, they provide an easy way to remember who this persona is, and what he really cares about. No reading necessary!

Conclusion

Making personas humane not only benefits you, the UX designer, but your stakeholders as well. Adding flavor to deliverables does not take a lot of effort, so why not do it? A humane persona will help us feel empathy for the real people who will use our designs and will help stakeholders accept concepts readily.  Try out the Humane Speech Bubble Persona, and let me know what you think!

For some more insight how I made this persona template, read my article on my website.

October 03 2013

13:30

Digital Literacy, Part 1: Cadence

What does it mean to be literate in a digital age? While our conventional definition implies reading and writing, that definition also pays no mind to new media’s inherent malleability. It’s only by scrutinizing the ends to which our digital creations are used that we’ll come to better understand our ability to effect change via those creations.

It’s has been called a publishing platform and a conversation medium, but it’s also been used as a collaborative encyclopedia, a code playground and a canvas for art. Is there anything the web can’t do? (and should there be?)

After all, analog media was relatively simple by comparison. Everything we needed to know in order to think critically about the written word came down to reading and writing. But the web is different. Not only does it allow us to create new ideas along existing channels – we can post on Facebook and/or Twitter, for example – it also allows us to create new channels altogether, such as Tumblr and Medium. So what does this mean for our conventional definition of literacy?

Media theorist Clay Shirky offers a clue. In his foreword to the the book Mediactive, Shirky provides a media-agnostic definition, suggesting that “Literacy, in any medium, means not just knowing how to read that medium, but also how to create in it, and to understand the difference between good and bad uses.” And this definition, in particular, resonated with me (indeed, I might go so far as to say it should resonate with all user-centered designers who seek to understand what it means to create a “good,” useful web), inspiring an investigation to something I’ve currently termed digital- or “web design literacy.”

In the following three-part series I’d like to share digital litearcy as I’ve come to understand it. In the first part (the one you’re currently reading) I’ll recount a story highlighting some of the web’s more esoteric aspects, the elements that make it similar to – but altogether different from – print. In the second, I’ll briefly discuss the prominent double-diamond model of design thinking and explore how “design posture” might affect our ability to navigate that model. In the third, I’ll point to nascent trends in our profession, ways in which both investigative journalism and teaching might pertain to work that we do.

A design villain

In May of 2009, an interaction designer named Dustin Curtis published an open letter on his personal website entitled “Dear American Airlines” suggesting that the company take a look at his vision of what their future home page might look like:

The difference was profound. Instead of providing users with a cramped, uninspiring sea of text, Dustin placed the booking process – arguably the most important interaction on the page – front-and-center. He even included a photo of island getaway. Few people could argue that he isn’t onto something, so that’s precisely when Dustin decided to turn up the heat, asking American Airlines to “fire [their] entire design team,” who, he added, “is obviously incapable of building a good experience.” He concluded by suggesting that American Airlines “get outside help.”

As those watching the saga unfold later learned – in a response from a designer working at American Airlines named “Mr. X ” – what prohibited American from redesigning its website wasn’t a lack of desire or its in-house talent. No, it was their corporate culture. As Mr. X explained it, the public probably wouldn’t see the fruits of his group’s labor for at least another year simply due to the degree to which teams at American depended upon one another (i.e. bureaucracy). This meant that the company actually had two problems: not only did it have a poorly designed homepage, it also had a poorly designed organization that made it difficult to affect change.

In his most recent book, The Connected Company, management consultant Dave Gray tackles this
problem head on, suggesting that organizations of the future adopt a “podular” structure (not pictured above) to allow for more dynamic problem solving. Illustration copyright © Dave Gray. Used with permission.

In many ways the state of affairs at American Airlines probably came as no surprise to Dustin – or anyone else for that matter. Of course they had a poorly designed organizational structure; why else would their homepage have fallen into such disarray? That’s a fair question and, in fact, it’s probably what led Dustin to publish his open letter. A more prudent question, however (one that apparently nobody thought to ask), is: what should American Airlines have done? Clearly they couldn’t just fire their entire design team, as Dustin suggested. How should they have gone from where they were to where they need to be?

The answer is complex. Readers likely have an idea as to where we might start (stakeholder interviews, anyone?), but none of us could possibly devise “a set of steps to take the company from bad to good” without knowing the way in which American Airlines operates on a day-to-day basis. To begin, we’d ask a whole bunch of questions.

It’s the question that drives us

To better understand how a designer might begin to solve the organizational problems plaguing American Airlines, it’s worth taking a step back and more thoroughly considering the role that Dustin played with regards to American Airlines vis-à-vis the publication of his open letter. There are many ways in which Dustin could have expressed his opinion, after all: he could have called customer support; he could have sent an angry letter (you know, in the mail); he even could have written a Yelp review (customers occasionally comment on websites as part of their business reviews). But Dustin didn’t do any of these things. Instead, he published an open letter, subjecting his inquiry to the web’s seldom-discussed-but-nonetheless-profound political affordances.

A “political affordance” is simply an amalgamation of concepts originating from the fields of social science (politics) and psychology (affordances). Whereas a perceived affordance allows an actor – a person, say – to determine the potential utility of his/her implements by way of what he or she perceives (e.g. the shape of a hammer’s head affords hitting, its handle affords holding, etc.), a political affordance describes someone’s ability to assemble and direct a public – to “call an audience into being” – by way of his/her media.

Political affordances have a profound impact on the way in which we create and consume information. By contradistinction, consider a web designer who places a redesigned version of American Airlines in their online portfolio in hopes that the finesse it demonstrates will garner them future employment. This happens all the time. But while both our hypothetical designer and our actual designer, Dustin, have each presented “alternate realities,” the web’s political affordances greatly magnify the ramifications of the ways in which these designers have chosen to express their respective sentiments. Our hypothetical designer’s message is likely considered “friendly” regardless of its reach. Dustin’s open letter, on the other hand, is almost certainly seen as adversarial precisely because of its reach. Not only does Dustin’s letter call an organization into question, it does so in a way that incites others to feel the same.

Distinguishing between these two modes of presentation might seem superfluous – and, indeed, it would be of less consequence – if it weren’t for the sheer fact that questions lie at the heart of what we do: designers ask questions in order to better understand the boundary between form and function; designers ask questions in order to understand what users want; and designers ask (rhetorical) questions when they present wireframes, prototypes, etc. to their team. (None of these actions is explicitly “at odds” with a system, though. Quite the opposite, in fact; designers generally question things in order to attain a shared understanding.)

In his 2009 TED Talk – incidentally given the same year as Dustin published his
open letter – psychologist and author Barry Schwartz “makes a passionate call for “practical wisdom’ as an antidote to a society gone mad with bureaucracy.” This is a challenge that creative consultants frequently face.

The difference today is that the internet forces us to more thoroughly consider the timbre of conversations we facilitate. When criticism happens in private, organizations and individuals are more likely to be open-minded and develop a sense of wisdom. When criticism happens in public, however, organizations run the risk of appearing non-empathic. Many remain silent.

Ultimately, the preceding line of inquiry raises two, related lines questions pertaining to our design process:

  • What makes a question, itself, “appropriate” or “innocent?”
  • What makes a question, itself, “inappropriate” or “threatening?”

In the interest of expediency, the difference – as far as I can tell – is tact. Tact differentiates our ability to get what we want – be that potential work in the case of a student, or a redesigned organization in the case of Dustin Curtis – and our ability to squander an opportunity. Developing an intuition with regards to tact allows us to prudently plan for change over time. In this way, there’s a certain design to Design: Asking deliberate questions in a deliberate order yields a deliberate result.

Grammatically incorrect

Finally we come to the issue of cadence, or the ebb and flow of ideas.

As with political affordances, cadence behaves drastically different across the digital and analog worlds. Online, the web affords both linear and non-linear narratives. In other words, a designer can either architect a system such that a user sees a predetermined set, or “script,” of screens – a checkout path, for example – or she can make it such that a user can navigate those screens in any order that user chooses. The choice is up to the designer. Offline, things are different. Because “real life” requires that we experience events in a linear order – reading an article (as you’re doing right now) or pitching, selling, and actually producing a design project – Design requires a certain kind of sensitivity to the way in which information is paced.

And, as it turns out, this is precisely the function of grammar. What’s more interesting than the Design-grammar analogy, though, is observing the shift that grammar has made as it’s left the the world of traditional media and entered the realm of interactive media. Consider:

  • One of the most fundamental books in the history of grammar is William Strunk, Jr. and E. B. White’s pocket guide to writing called The Elements of Style. Named as one of the “100 most influential books written in English since 1923” by Time magazine, it condenses nearly everything an American-English author needs to know to pace their ideas (outside of words themselves) to a mere 100 pages.
  • Following suit, typographer and poet Robert Bringhurt’s “The Elements of Typographic Style” serves as kind of typographer’s book of grammar. It, too, provides everything a typographer needs to know in order to effectively use type, basic grids, etc. in service of an aesthetic.
  • Finally, comic-book theorist Scott McCloud’s comic book about comics – called “Understanding Comics” – discusses various methods of visual communication. It comprises a kind-of-sort-of “comic-book grammar.”

Star Wars director George Lucas suggests that all forms of art share the same goal: communication. He believes that contemporary educational system should reflect this notion.

By now the pattern is clear: grammar allows (graphic) designers to better determine the way information is paced in traditional media. Now for the shift. Digital grammars appear much less didactic and much more philosophical. Consider:

  • In 2007 computer scientist Bill Buxton authored “Sketching User Experiences,” in which he described the various ways in which designers might affect change over time. Buxton’s allusion to sketching suggests that the product design (UX design) process might more closely resemble a game of pictionary than a traditional publishing process.
  • In 2008, new-media theorist Clay Shirky released his book “Here Comes Everybody” explaining the potential ramifications of a post-Internet society. While extremely well received, the book also raised a number of important, difficult questions surrounding the internet and collective action (many of them dealing with political affordances).

Again I believe the pattern is clear: whereas the grammars defining traditional media (punctuation, typographic convention, grids, and visual language) helped creators better define the cadence of ideas, the grammar defining digital media is potentially much more complex. Designer Paul Boag’s recent post about the nature of the web sums this up well.

Increasingly you are not having to visit a website in order to find certain types of information. For example, if I want to know local cinema times I can simply ask Siri and she will return just the listings required without ever visiting a website. Equally, if I want to know who the CEO of Yahoo is, Google will tell me this in its search results without the need to visit a specific website.

What does a lack of digital grammar mean for designers, those of us who want to provide the best content for our end users?

The journey thus far

This article’s covered a lot of ground. We began with a question relating the analog concept of literacy to its digital equivalent, asking what does it mean to create and consume the web, to understand its good and bad uses? In search for an answer, we first heard the story of Dustin Curtis’s open letter to American Airlines. In light of that, we discussed the internet’s political affordances and the way those affordances galvanized Dustin’s role in relation to American Airlines. This led us to consider the design of the Design process itself. Finally, we discussed cadence, the way in which grammar affords our ability to control the flow of ideas.

In part two of this series we’ll take an even further step back, using the double-diamond model of design thinking to contextualize our work and the concept of design posture to explain how we navigate that model. Stay tuned!


The post Digital Literacy, Part 1: Cadence appeared first on UX Booth.

August 20 2013

13:30

Has the Recession Taken Your Experience to the Dark Side?

When a new milkshake bar opened in my local shopping mall, I was very excited; I went right over and ordered my favourite flavour (coconut, of course). The cashier responded “Would you like a regular size?” and I agreed. I paid what I considered a high price for a medium-sized milkshake and, as I left, I noticed the sizes available weren’t “Small, Regular, and Large” (as I might have expected), but rather “Tiny, Small and Regular.” Realizing I was duped, I lost my incentive to return.

Unsurprisingly, the milkshake bar isn’t there anymore.

It’s been a tough time for businesses lately. The global economic downturn has led many consumers to tighten their belts and part with their cash more selectively. This has naturally driven companies to focus on maximising profits wherever possible in order to provide a strong return on their investment. That’s all well and good, of course, but sometimes the hunger for short-term results can happen at the expense of other “non critical” factors – as was the case in the story of the milkshake bar, above.

This conundrum has led me, a self-described user experience geek (UXG), to more closely examine the relationship between user and business objectives. Specifically, I sought answers to the following questions:

Is poor customer experience a necessary evil in order to meet business objectives?
What is the optimal way to design products or experiences that deliver a return on investment in both the short term and the long-term?

If I could find them, the answers to these questions could help businesses better rationalize the difficult choices they’d make during the recession. What follows is my journey. We’ll begin by observing a positive version of the “milkshake bar” experience. Next, we’ll discover how deceptive approaches translate to on the web. We’ll finish with a review of the habits of highly effective user centered designers – habits which are always applicable, recession or otherwise.

A favorable interchange

On any given Thursday you’ll find me at my local McDonalds. There, you might observe the following exchange:

Me: Hi, I’d like a Big Mac please.
My buddy at McDonald’s: Would you like to make that a meal?
Me: Yeah, sure.
My buddy at McDonald’s: Would you like to make that a large meal?
Me: No, thanks.

In this scenario, the short-term business objective is to sell a meal and my interaction with the sales clerk meets that objective. The experience is also good for me as a customer, because I get exactly what I ask for. The McDonald’s salesman first understands my needs and then offers a relevant upsell. When I reject the large meal (a higher short-term objective for McDonald’s), the salesman moves on, ensuring that I meet their long-term objective by returning as a customer (side effects may include high cholesterol). This straightforward, contextual approach – a combination of easy-to-understand terminology and relevant propositions – is a sustainable way to attract returning customers and build a reputable brand.

And the same logic applies to our websites. Amazon.com does a great job, for example, of offering two, relevant upsell opportunities.

I might not take the bait, but the option is both relevant and easy-to-understand.

So, is a poor customer experience a necessary evil in order to meet business objectives? No. Companies such as McDonald’s and Amazon prove that by valuing customer service and user goals over sales, companies are actually able to more successfully achieve their own goals (assuming those goals include retaining customers).

Dark patterns

In extreme cases, some companies completely disregard the user experience in favour of meeting business objectives. UX designer Harry Brignull calls these interactions “dark patterns.” From his site: “A dark pattern is a type of user interface that has been carefully crafted to trick users into doing things, such as buying insurance with their purchase or signing up for recurring bills.” So why are dark patterns used? Simple: they get short-term results. Over the long-term, however, users feel deceived, cheated and tricked – and they’re not afraid to share these opinions online!

Celebrated author Tim Seidell suggests that “For every action, there’s an equal and opposite reaction. Plus a social media overreaction.” And Twifficiency is a great example of this. Launched in 2010, the app “went viral” in a matter of days due to its accidental use of a dark pattern in which users automatically shared the app to all of their Twitter followers. The early growth was short-lived, however, as it was soon overshadowed by the exponential amount of negative attention it received.

Prioritizing appropriately

Given the connection between positive user experiences and long-term business objectives, why doesn’t every designer put user goals ahead of business goals? Because, as management guru Peter Drucker explains, “what gets measured gets managed.” In other words, some companies believe it is easier to track short-term sales than long-term customer retention.

When companies focus on driving short-term revenue and increasing short-term profit, the emphasis is on improving conversion rates or profit per visitor rather than helping users achieve their goals. The happy medium falls into what author Stephen R. Covey calls “Quadrant 2.” In his legendary book 7 Habits of Highly Effective People, Covey explains that Quadrant 2 contains tasks that are important but not urgent, whereas tasks that are both important and urgent are considered “quadrant 1. ” These lead to a business that’s constantly “fire fighting.”

Four business postures

Adapting quadrant 2 from Covey’s model maps business goals and user goals across two axes.

In Quadrant 1 a company focuses only on the urgent, short-term business goals, but not the important, long-term user needs. They might see short-term success, at the expense of unhappy, deceived users (think the milkshake bar). In Quadrant 2 a company focuses on the important user-needs as well as how they impact the business goals. Here user needs are met and, in turn, business goals are also met (think Amazon). In Quadrant 3 both the user needs and business goals are ignored (and we all know what happens there). Finally, in Quadrant 4, user goals are met but business goals are ignored. This is nicknamed “daydreaming” because, really, there’s no business model here at all.

Habits of highly effective designers

Because quadrant 2 presents the optimal way to design experiences, the first step of any design process is to know what the business objectives are and how they connect to user needs.

However a company’s designers currently focus on things, here are seven ways to ensure they move towards “quadrant 2.”

  1. Make a decision not to employ dark patterns. If the client disagrees, remind him/her of the long-term goals and the value of repeat business compared to single-visit exploitation. If they can’t see the value, drop the client.
  2. Keep your eyes on the prize. Design decisions should be driven by business objectives. Always review the objectives before development or design meetings, and keep them posted somewhere obvious for the whole team to see.
  3. Make the link between the UX and profitability. Discuss the value of positive user experience with the client early on. Make sure both sides agree that resources spent on the user experience are resources well spent.
  4. Get to know the user. Find out what your users’ goals are and what motivates them. User interviews and focus groups can provide invaluable insights.
  5. Work with user goals, not against them. Instead of tricking users into following a predefined path, help them to see why that path is the most attractive option. Use contextually relevant content to align their goals with those of the business.
  6. Increase the type of measurements you do. Don’t just measure the obvious,such as whether a new development impacts the conversion rate. Measure the effects, too. Are users more likely to return if they have a favorable experience? Will users recommend your service to a friend?
  7. Finally, be data driven. Analyse objectively what is and isn’t working. Iterate when needed and move forward in the direction the data takes you, not the direction you were hoping it would take.

By practising the habits of highly effective UX designers, we move towards “Quadrant 2,” a place where happy clients and happy businesses can coexist. These habits set us up for recurring revenue from empowered users. There is no need to go over to the dark side and leave behind the principles of user experience – even in a recession.

Ok, I’m off to McDonalds. I think I’ll order a milkshake, but probably just a regular…


The post Has the Recession Taken Your Experience to the Dark Side? appeared first on UX Booth.

July 25 2013

15:15

Interviewing the Interviewer, Part 2: A Chat with Maish Nichani

Earlier this week we shared part one of Steve Portigal and Maish Nichani’s conversation concerning the practice of user research. In the final half of their conversation, Steve asks Maish how he and his firm structure their approach to design research as well as how Maish thinks research might be facilitated in the future.


Hey, Maish! What are some internal initiatives you’ve used to develop interviewing skills within your own organization?
PebbleRoad is a small team comprised of “t-shaped” researchers, so when it comes to collaborating on a project we work to ensure that the “horizontal part” of our T’s overlap. For example, everyone needs to know the process and methodology of research interviewing.
We used to think we could rely on our people to carry the knowledge of our research process, but we were wrong. We kept finding interesting stuff we did many years ago that nobody knew about! To establish common ground, we created processes and tools to guide our practice, including:
  • A toolkit, comprised of guides, templates and forms that frame the practice;
  • Artifacts, which are physical things that give quick access to our shared knowledge;
  • Resources, such as collections of books and articles for new knowledge; and
  • Rituals, which are regular activities to keep the ideas flowing such as sharing sessions called Jolt Fridays!
  • Interesting! What’s in the toolkit, then?
    The research toolkit consists of:

    The toolkit is kept in our Google Drive and can be updated by everyone on the team. It helps establish a common ground upon which further conversations can take place. For example, we can quickly start discussing the research need and plan activities to meet that need.

    I’m assuming the books and articles are physically present in your space?
    Yes, we have a nice collection of 300+ books in our library. We read a lot! Current favourites include Service Design – From Insight to Implementation by Andy Polaine, Lavrans Løvlie & Ben Reason, Thinking Fast and Slow by Daniel Kahneman and Designing the Search Experience by Tony-Russell Rose and Tyler Tate. Our entire catalog is on LibraryThing!
    Could you give me an example of an artifact? Where does something like that live?
    In one of your webinars, Steve, you outlined the different types of interview questions one could ask and what they are used for. We found that list to be very useful when writing the interview planning guide, so we created an interview-types keychain!

    This is an example of an artifact. When we want to use it, we open the ring and spread all the cards on the table. We then discuss which types of questions will be most useful for the interview. When we’re done, we put the cards back on the ring. In fact, for those who want to create their own version, download the PDF or Indesign file.

    Okay, so, I’ve got to know: what happens on Jolt Fridays? It sounds dramatic!
    Jolt sessions typically happen on a Friday morning and anyone on the team can volunteer to host one. The host arranges for breakfast, chooses a topic, and researches it beforehand. We’ve had Jolt sessions on topics like How to Listen, Digital Marketing, Gamification and, yes, Qualitative Data Analysis. We also have screenings such as the documentary Art & Copy: Inside Advertising’s Creative Revolution. The big idea is to widen the organization’s collective thinking – to give it a jolt!
    In the past you mentioned that you were developing an app to facilitate user research. What is the app? Who uses it and for what?
    A few years ago we spent almost half a year developing a research data management app called Insightico. Sadly, we “archived” the project late last year.

    The idea was to collect and store research data in chunks. Researchers could import audio and video recordings, pdf files, ppt templates and other types of files into the app. These files could then be “chunked” up; for example, a video file could be broken up into individual segments and tagged. The big idea was that if we had chunked and tagged data from all sources we’d be in a better position to find patterns. Also, since chunks exist independently we could mix and mash up chunks from different projects for a session on crazy connections!

    The app was hosted in the cloud and expensive to maintain. We did this without any external investment. It was our pet project.

    Very quickly we learned that ideation is an “all-at-once” activity. Researchers are more effective when we can “see” all findings at the same time, not linearly like a blog post, which is how we presented it in the application. We know of only two ways of doing it today: Post-It Notes on a wall and spreadsheets!

    The app design team moved on with their projects and the development team disbanded so we had no other option but to “archive it”. I say “archive,” not “kill,” because I still think the idea has merit. If we can get a good team in place we might just have a go at it again!

    But it sounds like the technology had a limitation in that it didn’t support the “all-at-once” way of engaging with the data? Is that something you would design around if came back to the project?
    Yes. Even the pro research apps, like MaxQDA, are trying to get more visualization capabilities, but they’re not there yet. I think the problem is screen size. Unless we get something larger where many people can simultaneously interact with (multi-touch, multi-user), the physical wall with yellow stickies is going to win. Collaborative ideation needs something like what Jeff Han demoed on TED a few years ago!
    You’ve explored creating very analog and very digital tools to support the research process. What do you think the tradeoffs are in the different approaches?
    Digital is fantastic for capturing data and analytics, but when it comes to inference we need to take it out of the computer, as Jon Kolko advises.

    My biggest peeve is that we should be able to reuse findings across projects. This is where digital can really help but only if we’re strict about collecting it the right way. Vijay Kumar’s recent book, 101 Design Methods, talks of a “User Observations Database” that students can refer to when doing background scans. This database contains results of observation studies across different projects. This is the kind of reuse I’m interested in and it seems to be something for which digital is extremely well suited.

    If you could wave a magic wand and create any kind of tool or artifact to support the research process, what would it be?
    Research is really all about creating new knowledge and the more people who have access to that knowledge, the better. Currently, our research findings and insights are all locked up in (what Karen McGrane calls) “blobs.” We need it, instead, to be “chunked” (as Sara Wachter-Boettcher says) so that it can travel more freely and be mixed and mashed up to create, again, new knowledge. I don’t know of any existing project or initiative but I was thinking about using a schema (like what is already available on schema.org) for research findings. That way anyone writing up research findings could use the same markup and then search engines and specialist apps could read and move those findings more efficiently.
    A while back, I asked my team to avoid actively discussing examples from a previous project while synthesizing a current one because it felt awkward. While our clients hire us because of the benefit of our expertise, is prior “data” off limits? Every time I hear about sharing across projects, I think about what might be legal or ethical issues. What do you think is our obligation to keep our data and our insights from a project to just that project?
    The main objective of research is to point to a design direction or decision. The multitude of these decisions leads to a design solution, in our case websites, intranets or apps. If we keep this frame, then the criss-crossing of findings across projects becomes a necessity. As an example, we recently did a project on the job market in Singapore. One of the core findings was a deep sense of “entitlement” of young Singaporean jobseekers. The reasons for this attitude are “macro” in nature—recent economic success, changing culture, political freedom, etc.

    Now, our latest project centers on workforce productivity. It would be a disservice to ignore a possible causality between the entitlement mindset and a productive workforce. This is the type of reuse I’m referring to; not about identifiable data, but broad strokes of understanding.


    And that’s a wrap! Thanks, again, Steve and Maish; we’re always delighted to listen in.

    Considering that the interview ended on such an ethical conundrum, I’m curious what readers think: is sharing research data a good thing or a bad thing? What about knowledge, the flashes of understanding we get as researchers? Finally, if anyone knows about a schema for structuring research findings, please share it with Maish in the comments, below.


    The post Interviewing the Interviewer, Part 2: A Chat with Maish Nichani appeared first on UX Booth.

    July 23 2013

    13:30

    Interviewing the Interviewer, Part 1: A Chat with Steve Portigal

    Whether you’re new to the practice or a user research veteran, there’s always something to learn. So when researchers Maish Nichani and Steve Portigal got together to talk, we were delighted to listen in. In the following two-part series, Maish and Steve take turns discussing some of the oft-overlooked aspects of the craft.

    Over the course of his career, Steve Portigal has interviewed hundreds of people – families eating breakfast, hotel maintenance staff, architects, radiologists, home-automation enthusiasts, credit-default swap traders, even rock musicians. He’s also the founder of Portigal Consulting, where his work has informed the development of dozens of products and services. In his new book “Interviewing Users: How to Uncover Compelling Insights” (recently published by our friends at Rosenfeld Media), Steve sheds light on his seemingly simple but rigorous practice.

    Maish Nichani is a UX practitioner and principal at Pebble Road, an enterprise UX consultancy. He and Steve are friends. Prompted by the release of Steve’s book, the two of them get together to really discuss aspects of their work. They had a whole book to go on, after all!

    Included in the first half of the transcript are the differences between interviewing and day-to-day conversation as well as what Steve describes as the “tipping point” that occurs during research. Later this week, we’ll present a the second half – a sort-of reverse interview – in which Steve asks Maish what he thinks about the current and future state of the profession. And if that wasn’t enough reason to check back in, we’re also running a contest, giving away three copies of Steve’s book. Details below!


    Thanks, Steve, for taking the time to chat! What is hardest part, you think, for newcomers to grasp when it comes to interviewing users?
    I don’t think people really grasp that there’s a big difference between talking to people – something we do every day – and leading an interview. Some people decide to treat interviews exactly like conversations, whereas others decide to act like what they think “real interviewers” do (e.g., a list of questions that are read from a sheet of paper and don’t ever turn into an interaction). Both groups are missing out. Developing an understanding of the ways that interviewing inherits some aspects of normal conversation and the ways in which it differs is what separates newbies from those with a bit of skill.
    What is an appropriate response to give clients who insist on specifying aspects of your research methodology?
    Whenever a client approaches me and has already specified the approach we should take with their study, that’s usually time for a conversation. Sometimes teams create a research plan as a stake in the ground when what they actually want is feedback and a recommended approach. Sometimes, though, their plan is a good one, and we might just suggest one or two changes to see if they are amenable. I can’t count the number of times I’ve received a detailed request, exclaimed “what?!” and then had a really excellent conversation to better understand the reasons behind it. Obviously, no one should take a project where they don’t believe the method is going to produce results. An examination of a prescribed approach is one of the first tests of (the potential for) good collaboration.
    A common stakeholder complaint regarding user interviews is that they take too much time. How do you respond to clients who insist on lean research?
    It’s a red flag when someone approaches me with schedule concerns. Whether it’s their version of a lean process or not, I want to be sure that it’s feasible to address their issues with the given resources. Otherwise, it’s a project that’s going to fail – and no one wants to take that on!
    I provide a “typical,” phased research schedule in the book:

    As well as a version with highly compressed phases:

    My job is to help clients be mindful of the tradeoffs they’re making as they build a project schedule. The more time we spend, the more complex issues we can explore and the more certainty we will have about our conclusions. It isn’t always necessary to reach “the ultimate depths of complexity” with “the ultimate heights of certitude,” though. Clients should adjust the schedule while being aware of the tradeoffs.
    In your book, you suggest interviewers use “transitional rituals.” What are these rituals and why are they important?
    In the same way that interviews are not the same as everyday conversations, the time we spend with research participants is separate from the time we spend doing our “regular jobby stuff.” Transition rituals help interviewers switch contexts, providing a more objective interview. For me, this sometimes means assembling the materials and equipment, checking that I have the documents, etc. That’s sufficient. For someone else, they might want to remind themselves that what they are about to do is focus on the participant. That also has the benefit of reminding them to let go of the stuff-at-the-office – the report they have to give, the meetings they missing, etc.
    You go on to mention a certain “tipping point” that happens during interviews where the interviewee shifts from giving short answers to telling stories. Can you shed more light on that?
    Almost all interviews (if done well) get to a point in which the interviewer receives a great deal of information without feeling as though they’re “pulling” it out. For some interviewees, this happens in 30 seconds; for others it might 30 minutes, 60 minutes, or more. Ultimately, it’s an unpredictable element. While it doesn’t always happen oftentimes, when running an interview, I have the realization “Oh, now we’re there!”
    Are transcripts of interviews necessary? Do memos or notes suffice in some situations?
    Notes taken during or before an interview are filled with inaccuracies. It’s just beyond human capacity to fully capture everything. You need an audio or video record. Whether you later transcribe those (my preference) or just watch them again is up to you, but notes are not the same as the definitive recording of the interview.
    How do you identify insights when going through interview data? In other words, what makes an insight an insight?
    Insights come from successive refinement. I like to have conversations with my team throughout the research process about what we’re hearing. That way, when we’re actually going through the data, it’s not the first time we’ve reflected on what is interesting. Later I go through data with two filters on: the first is looking for specific things that I’ve already identified as areas to understand; the second is looking for things that strike me as interesting. But going through data is just about gathering individual data points; it’s when you put them all together into something new (e.g., synthesis) that you start to be able to report an insight. As far as defining the term, ugh; I’ll let someone else worry about it!
    Last question! What are some tips for design teams to spread the use of research findings inside their organization?
    In short, it’s best to look for opportunities to share findings throughout the process [Ed: notice a pattern?], not just when you’ve got “findings.” I cover this in more detail in my presentation “Championing Contextual Research in your Organization.”


    That’s all, folks! Thanks again, Steve and Maish, for sharing your knowledge with us. Here’s a summary of Steve’s points:

    • Leading an interview is very different from everyday conversation. This subtle difference makes all the difference.
    • Methods-first briefs (in which a client prescribes a process) provide opportunities for researchers to meet clients and understand their approach.
    • Research can’t be rushed. Time is commensurate with outcome.
    • Transitional rituals provide time to remove our own hat and wear our participant’s.
    • Tipping points indicate states of flow during an interview, a natural outpouring of information.
    • Always record interviews when you can. Don’t depend on memory or scribbled notes.
    • Insights come from two points of view: what’s specified as part of research and what’s personally interesting!

    In Part 2, later this week, we’ll share the “reverse interview” in which Steve Portigal asks Maish how he and his team work to hone their skills over time and as well as how research might be stored in the future.

    As for the book giveaway, longtime readers know the drill. To enter, simply follow @uxbooth on twitter and leave a comment on this post answering the question: What’s the most surprising thing you’ve learned while conducting user research? Be sure to include your twitter handle in your comment and to leave it before this Thursday at midnight PST. We’ll contact winners over Twitter. Good luck!


    The post Interviewing the Interviewer, Part 1: A Chat with Steve Portigal appeared first on UX Booth.

    June 18 2013

    13:30

    A Confab Recap

    Kristina Halvorson issued a strong call-to-action during her opening keynote at this year’s Confab Minneapolis event, saying: “Part of my job as a content strategist is to get people on board with content strategy. You are a salesperson.” Through the next two days of Confab, speakers provided tools to make this challenging dream a reality.

    A few weeks ago, I had the great pleasure of interviewing two Confab speakers, Jonathon Khan and Melanie Moran, in preparation for my attendance of Confab Minneapolis. While writing the introduction for that interview, I spent some time reflecting on why Confab is such a meaningful conference to me:

    [Speakers at Confab] talk about writing from the perspective of thinkers – journalists, creatives, researchers, and readers – instead of merely dwelling on its marketing value. It’s a whole new world, connecting writing to design, turning copy into content.

    Kristina’s call-to-action during this year’s event – “You are a salesperson” – especially rang true. As an independent content strategist, I work with three types of clients:

    1. Clients who know what I do and value it
    2. Clients with a rough idea and interest in what I do, and
    3. Clients who simply don’t “get” content strategy.

    By far, the third category is the most difficult: in addition to doing my job as a strategist, I have to teach these clients about governance, content creation, content curation, and content modeling. I also have to continually prove my own value. It’s the single most frustrating aspect of my work.

    Communication techniques

    Fortunately, this year’s speakers also taught me how to value both my clients who understand my work, and the clients who need me to be their guide. It’s advice I’m excited to put into practice.

    Show them you care

    Some clients love content strategy, but that doesn’t mean everyone’s on board. The easiest way to get people invested in content strategy is to listen, not speak. Listening shows clients that we want to understand the problem at hand. Stakeholders may not care about content strategy, but they do care about finding a solution to their problem. Once they hear their solution lies in a content audit, authoring guidelines, a governance plan, etc, they’ll jump on board. We might call it content strategy; they just call it “what works.”

    Ask the right questions

    During her keynote, Kristina focused on the top 10 issues that content strategists face. Many clients want future-friendly, multi-channel, single-source, magical-unicorn-meat content. It’s depressing to be the bearer of bad news, telling clients they need to trudge through the boring world of organizing content before they get to the fun “future” stuff. The solution is to remind clients that we’ll get to the future-friendly, multi-channel, single-source, magical-unicorn-meat content by starting with simple questions, such as: why do we need it; what already exists; and where is it?

    Find your voice

    The first step in building a content strategy isn’t necessarily a big, expensive, full-site, multi-channel redesign. Tiffani Jones Brown explained the value of starting small in her talk, Voice Lessons: Finding Your Company’s Personality. Voice is a combination of personality, energy, and the experiences clients have with your company – all the words that represent a brand. Before touching a page on the website, it helps to reassure clients that we’re not starting from scratch; we’re making a record of, and using, their own, personalized language.

    Be Honest

    One of the most valuable talks I heard at Confab this year was Ahava Leibtag’s talk, Winning the Work: Making the Case for Content Strategy. Ahava drilled down to the heart of a common content strategy concern: what if I’m not right for the job? Her advice? Be honest. In a worst case scenario, you are freeing up your time for projects to which you’re better suited. And in a best case scenario, the client decides to work with you, and has reasonable expectations! In addition, every prospective client appreciates working with someone who recognizes their own strengths and weaknesses.

    Put the “Strategy” in content strategy

    Many clients fear the unknown of “content strategy,” and they want to see either a process, or a list of deliverables, neither of which come naturally to a flexible content strategy. In Responsive Web Projects: How to Plan a Successful Discovery Process Steve Fisher and Alaine Mackenzie offered some suggestions for helping to create a process that clients can understand… even if the process doesn’t exactly match the sample one that ships with Microsoft Project.

    Stay out of the silo

    Silos are for farming, not content strategy,” Steve Fisher told us. It’s easier said than done. Even as a proponent of knocking down silos between development, content strategy, and design, content strategists occasionally advocate for silos when working with management! A “heads down” approach and preference to work with clients who already “get” content strategy builds a wall between the strategist and the client; part of breaking silo walls down is teaching clients what they don’t understand.

    Get started

    Every conference leaves my head awhirl with new plans to change the way I work with my own clients. Starting now, I’m getting out of my private “content-knowledgeable” silo and advocating for content strategy. Feel free to follow my lead with these first steps:

    1. Provide some therapy for new clients. Ask them what keeps them awake at night, and how they feel about their content.
    2. Offer content strategy as the solution, not the issue. For clients who haven’t worked with a content strategist before, this will help frame the process.
    3. Talk about the process. The process is flexible and ever changing, but it does exist.
    4. Stay honest, stay optimistic. It’s easy to get jaded when “selling” your skills, particularly if you feel like you’re doing false advertising. Instead, engage in honest discussions with new clients; that’s enough to sell the value of content strategy!

    The post A Confab Recap appeared first on UX Booth.

    June 11 2013

    13:30

    A User Experience Business of One

    My initial foray into UX frustrated me. Although my job title suggested that I made products easier for end-users, I actually spent a lot of time selling user experience to clients, stakeholders, and colleagues. I knew I needed to broaden my focus, but I didn’t know where to start. And that’s when I discovered The Business Model Canvas.

    The story behind what we today know as the Business Model Canvas is an interesting one. Originally created as a conceptual framework for Alexander Osterwalder’s PhD project, it later became the subject of an entire book called Business Model Generation, co-authored with Yves Pigneur. Today, both the book and the canvas allow those of us without business training (including yours truly) to better understand sustainable business practices.

    My application of the Business Model Canvas is likely atypical, though. Instead of using the canvas to aid clients, I wondered: what if I looked at my role as a business itself? After all, I need resources to operate (a budget, my supervisors’ time, my colleagues’ expertise); I have customers (people to whom I provide value); I have costs (my time, materials, stress). Could understanding all these things help me design more efficiently?

    Introspection

    To follow my logic, it’s useful to first understand how the business model canvas is laid out.

    Personal Business Model Canvas Worksheet. Source: http://www.businessmodelyou.com

    Divided into nine parts, it includes:

    • Key partners – Who supports you?
    • Key activities – What do you do to create value?
    • Key resources – What do you require?
    • Customers – For whom do you create value?
    • Value – What problems do you solve? What needs do you address?
    • Channels – How do you communicate your value?
    • Customer relationships – How you interact with customers?
    • Revenue – What do you get?
    • Costs – What do you give?

    Using the original book’s sequel (Business Model You) as a guide, I thought critically about my role within my organization. Rather than rigorously weigh all nine considerations here, though – something for which the book is much better suited – let’s look at three in particular: customers, value provided, and key channels.

    Customers: not just the end-user

    While it’s relatively easy to assume that our customers are the same as the customers of the company for which we work, this isn’t strictly the case. As the book defines them, customers are anyone for whom we’re creating value, including:

    • Clients and stakeholders, who rely on us for our expertise;
    • End-users, who rely on us to represent their needs;
    • Software developers, who rely on us to clarify interactions and interfaces;
    • Other members of the design team, who rely on us for user research; and, finally,
    • Colleagues in quality assurance, who rely on us for specifications and clarifications.

    Notice that end-users are only one item on the list. Notice, also, that colleagues are customers too. Couple this with the fact that we practice user-centered design and it becomes increasingly obvious why it’s part of our job to consider our team and their benefit.

    User experience design isn’t limited to human-computer interaction; it includes human-human interaction as well. Before filling out the canvas, I instinctively knew this – that my responsibility did not end with “end users” – however, I didn’t know what I could do to serve them more effectively. That’s when I considered value propositions.

    Value: not just deliverables

    Just as clients tend to think of our work as deliverables, designers often think of our work as different activities: holding workshops, conducting interviews, writing scenarios, making wireframes. Yet one of the biggest mistakes we can make is to assume that the activities we conduct are the same thing as the value we provide.

    When I sat down to determine the value I provided, I was stumped. I could only think of – dare I say it – clichés. Yeesh. “Making things easy to use,” “generating empathy,” etc. I needed to break it down.

    My actual first draft of value provided – this describes what value my role provides, irrespective of activities.

    To determine the value I provided to others, I started with a list of what I was currently doing at work: conducting user interviews, diagramming mental models, building low-fidelity prototypes, tracing mind maps, putting together personas. Next, I considered my reasoning for each activity. Why did I interview project stakeholders?, for example. Then I asked myself: So what?

    Repeatedly. Until I hit something.

    This resulted in the following table:

    Activity I do this to… So that… User interviews Build empathy for customers We avoid building a product “for everyone” Mental Model Diagram Determine our feature fit Stakeholders can see gaps Low-fidelity prototype Share the vision Everyone can agree to the product direction, sooner

    Does interviewing customers before designing reduce the risk of product-market mismatch? Does one particular kind of prototype make it easier to adapt the design vision? You don’t know until you think it through.

    Next, I considered the value provided by each of these activities for my customers:

    Activity Value to client Value to developers Value to designers Mental Model Diagram Risk reduction. This helps clients see gaps in their offering (where they might lose competitive edge or profit) Convenience. This allows developers to more easily write user stories by providing user motivations. Cost reduction. This provides designers with context so they can more quickly make design decisions.

    Notice how the value differs depending upon the customer. Finding the right way to phrase the value we provide for a given audience is, simply put, a user-centered way of thinking. It requires asking the right questions and actually listening to the answers. In this case, we just have to add business constraints, and organizational fit to our list of topics to listen out for.

    Communicating this way signals that we have a wide skillset. When I sit down at a meeting, I sometimes sense that a new client considers the role of designer to be analogous to that of an aesthetician: the person responsible for adding “color” to an interface. Communicating my role in terms of value signals that I think broadly. It raises expectations.

    Key channels: stop waiting for recognition

    The third realization I had when filling out the canvas was that I was often waiting for people to become curious about what I did instead of communicating my own value. Channels are the methods we use to communicate to customers. They afford three things:

    • Awareness of the value we provide. They allow us to spread the word about what we can offer (and listen to others to see where its needed most).
    • The value itself. Channels allow us to deliver the value we promise.
    • Customer support after we’ve delivered our value.

    Most importantly, this exercise helped me realize that I needed to start doing things resonated most with each of my customers. To that end, I might:

    • Demo something I did in the company demo meeting and talk about the value to developers
    • Share a usability test recording
    • Make a cheat-sheet of my activities’ benefits for the sales team, or
    • Write articles about our process for the company website so clients could learn more about what UX means for business

    Making the sale

    To there you have it: the business model of a UX Team of One. Selling UX – especially within an organisation – is a complex topic. Whole books have been written on the subject. The three insights above resulted from reconsidering my value and what I could improve on.

    I eventually came to realize I needed a plan for communicating value to different groups of people I work with, and that I had to stop waiting and start doing. I also came to accept that there were areas in which I needed help – such as translating my reasoning for UX activities into business terms. I’m currently working on writing out all these benefits, with the help of an experienced consultant.

    The business model canvas hasn’t made my job any easier to do, but it has helped me prioritize. Communicating value is a journey. I recommend filling out the canvas for yourself and seeing which boxes are most difficult to fill (yours might differ from my 3 key learnings) or with which you could use some help. I have no doubt you’ll find the result rewarding.

    Related resources

    On UX within organizations
    On UX benefits
    On the Business Model Canvas

    The post A User Experience Business of One appeared first on UX Booth.

    January 08 2013

    05:07

    The General Stakeholder Interview

    This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

    Topics applicable to most stakeholders

    Try to keep the interview conversational rather than reading from a list of questions, but consider writing a list of topics on the inside cover of your notebook where you can glance at them when you get stuck. These are some questions applicable to most stakeholders; topics specific to particular stakeholder roles follow. Note that it’s as important for in-house teams to ask most of these questions as it is for consultants; you may know one answer, but do you know this particular stakeholder’s answer?

    What’s your role with respect to this product?

    If you’re a consultant, the reason for this question is obvious, but even if you’re an insider, you or one of your teammates may not understand someone’s role as well as you think you do. It’s also an easy, non-threatening way to get the conversation started.

    What did you do before this?

    Answers to this question will tell you whether this person has some unexpected expertise to share and will give you some clues about how this person might view the world; a product manager who has a background in the domain but not in product management won’t have the same concerns as an experienced product manager who doesn’t know the industry.

    What is this product or service supposed to be?

    It’s interesting to see what aspects of the product or service each person emphasizes. One of the key things to look for in the response is any hint of functionality no one has mentioned before, since this is important not only in helping the product team achieve consensus, but also in keeping the project timeline within bounds. Some stakeholders will answer you with an impenetrable wall of buzzwords: “It’s a distributed, service-model three-tier architecture that will leverage existing technology,” and so forth. In such cases, ask them to break down what that means by asking how they would explain what it does for the average user.

    You’ll also want to ask the reverse of this question: What is the product not meant to be? Some stakeholders have difficulty being realistic about what they can accomplish, so it’s important to build consensus about boundaries as well as goals.

    Expect a wide range of answers. With respect to software, this diversity is usually due to what people think will be in the first (or next) version versus what will be in later versions. You may be able to clear things up by asking each interviewee to compare the immediate release to what the product will eventually become.

    Who is this product for?

    Although the marketing or product management people have the most informative answers to this question, the range of answers from other stakeholders can highlight issues your research will need to address. It’s also important to know what assumptions there are about users so you can test them and see if they’re true.

    There may be variation due to a poor understanding of who the users are. On a recent project, for example, one stakeholder told us the product was going to be so indispensable that executive users would want to log in remotely from the airport, while another told us executives would only consume monthly reports generated by subordinates. Both agreed that executives were the targets for the information, but they had differing opinions about whether executives would see the information as so mission-critical that it had to be accessible at all times. This sort of variation doesn’t mean the organization is dysfunctional; it just means people need better user data to clarify things.

    When is the version we’re designing going to be released?

    It’s normal to hear optimism from the marketing and sales people and pessimism from the engineers, but if the answers to this question differ by more than a month or so, mention it to your project owner. Also, don’t forget to ask why the timeline is what it is. Sometimes there’s a serious mismatch between goals and timeline—stakeholders may say this project is going to be the basis for all of their products in the next ten years, but they want to launch it in just a couple of months. Don’t just let this slide; it will bite you later. Instead, point out the apparent contradiction and ask about it. “You’ve said the product has to be all things to all people. You’ve also said it has to ship by the end of this year. Those two things are potentially conflicting. Which is more important and why?” A reasonable executive stakeholder will clarify what the priorities are.

    What worries you about this project? What’s the worst thing that could happen?

    This is a good topic for the later part of the interview, after the stakeholder has relaxed a bit. Sometimes the anxieties will be things you can help with, such as worries that the product won’t have the right functionality. In other cases, the worries may point out organizational weaknesses you need to be aware of. While engineers always worry that there won’t be enough time to build the product the way they’d like to (and they’re always right), listen for truly unrealistic expectations. You may hear concerns beyond the usual level of grumbling that one part of the company is not up to doing what it needs to. If you hear that the marketing team is largely inexperienced in the product development world, you may be able to help by educating as you go. If it appears the engineering team is less capable than most, you’ll either need to suggest some additional engineering resources if you’re in a position to do so, or you’ll need to be fairly conservative in your design.

    What should this project accomplish for the business?

    In a highly functional company, most stakeholders can answer this question to some extent, but it’s amazing how often a senior executive is the only one who can do so. When this happens, you can help the organization by disseminating the business goals during the design process.

    If stakeholders struggle with articulating this, try asking more specific questions: How will this product generate revenue? How will this product save money? How should this product affect the company’s brand and position in the marketplace? What should the company be able to accomplish with the product that it hasn’t before?

    How will you, personally, define success for this project?

    Many stakeholders will simply reiterate the business goal, or they’ll say the thing they’re most worried about won’t happen. Some will give you insight into other things that worry them or what will get them excited about the design. You might hear things like, “If we just avoid this problem we’ve had before, I’ll be happy,” or “Other people in the company will finally see the value my team can offer.” Understanding these issues is essential in building support for the design.

    Is there anyone you think we need to speak with who isn’t on our list? Who are those people?

    Ask this one toward the end of the interview. Check in with the project owner later to see if discussion with any of the people mentioned is really a good idea.

    How would you like to be involved in the rest of the project, and what’s the best way to reach you?

    This is a good one to save for last. It’s an especially good opportunity to make sure the senior people stay involved at key decision points. If you have a middle manager who’s reluctant to involve senior management, this gives you room to say “The CEO specifically said she wanted to be involved in that meeting.”

    See also

    Excerpted with permission from the publisher, Wiley, from Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin. Copyright (c) 2009.

    05:06

    The Marketing Stakeholder Interview

    This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

    Marketing stakeholders

    Marketing stakeholders (such as marketing executives and most product managers) are usually responsible for promoting the company’s brand, identifying new market opportunities and products that could address them, or both. Most marketing people will immediately view designers as allies who will promote a customer-centric point of view. Some view designers as threatening rather than helpful, though; when you talk about doing research and driving some of the requirements, you may be treading on territory they view as theirs. If they’ve just spent hundreds of thousands of dollars on market research that doesn’t provide the answers you need, you also have the potential to make them look bad. Talk about how the design team’s work is in addition to theirs, not instead of it, and describe how you can help communicate their vision to the engineering team (which is often a point of frustration).

    There are a number of questions the marketing people are best equipped to answer; some examples follow. The more brand-focused questions are things a visual or industrial designer will particularly want to know, though the answers can prove useful to the whole team. These questions are in no particular order; they generally fall somewhere in the middle of the questions for all stakeholders listed above.

    Who are your customers and users today, and how do you want that to be different in five years?

    It’s essential to see where the marketing team wants to take the product or the brand, especially if it involves a change in direction. This will affect how you plan your user and customer interviews, since you won’t want to limit your research to existing customers if the idea is to break into a new industry vertical. (Note that if you’re a consultant planning the research before the project kickoff, the project lead should have asked this question at that time.)

    Sometimes the vision is so ambitious that it sounds impossible. For example, the interviewee might paint a very broad picture about handling all types of business communication. This could turn into a monstrous product that attempts to replace phones, email, instant messaging, online conferencing, and more. Try asking what business they definitely don’t want to be in.

    Ask for clear timelines. Sometimes, the engineers think the marketers are unrealistic because they talk in very grandiose terms, but don’t always clarify when they want the vision to be fully realized. Often, the marketing folks are talking about a five-year vision and don’t expect the whole thing to be accomplished in the first release a year from now. This is one of many opportunities to help improve communication between groups.

    How does this product fit into the overall product strategy?

    If the product is part of a bigger suite of related offerings, you need to know what role it plays in that greater plan. For example, if you’re designing the entry-level product in a set and the marketing team envisions getting people to upgrade as their needs change, you know you’ll need to focus on giving that product limited but excellent capabilities and a design that can scale up. If they’re envisioning the product as some sort of platform for future growth, you’ll need some idea what those possible directions are if you’re going to have any chance of anticipating them in the design.

    Who are the biggest competitors and what worries you about them? How do you expect to differentiate this product?

    While it’s seldom helpful to spend a lot of time on competitive research unless you want to build a “me too” product, you at least need to know what else is out there. Ideally, you will get to interview and observe people using these competitive systems, too. Some people see the competition as the other companies trying to sell similar products, but be sure to discuss the hidden competition, which might even be some combination of paper, telephones, and face-to-face communication.

    What three or four qualities do you want people to attribute to your company and your product?

    In an established company, good marketing people have a clear answer to this sort of question, and that answer guides everything they do. This answer is essential when your mandate includes developing a unique design language for hardware or software. It can be useful for interaction design, as well; when you are presenting a particular bit of functionality or behavior, describing how it supports the brand values can be a powerful argument. Mind you, this argument works best with very brand-driven organizations, such as consumer product and service companies—in a company that thinks the brand is just the logo, you won’t have much luck with this approach.

    In organizations that are less sophisticated about brand, people may struggle with this question. This is where analogies can come in handy. Some people try to get at this information by asking “If your company were a car, what kind of car would it be?” It can sound less silly and be more productive to frame the question in human terms, such as “If your product were a person, how would you describe its qualities?” You might also ask for examples of other brands or products they think embody each attribute, and why.

    Note that most larger companies separate product marketing and corporate marketing; the product marketing people may be focused more on understanding their particular segments, leaving the brand issues to the corporate people. If that’s the case, ask this question of the corporate team.

    What is the current state of the identity, and could we have a copy of the style guide (if there is one) and examples of it applied to materials?

    This question is essential for consultants, but in-house teams probably have this information already. Like the previous question, this is more geared toward corporate marketing than product marketing. In a company that’s sophisticated about marketing, you’ll see consistent visual themes across print and online collateral as well as the visual and industrial design of products; you can look at any Apple product or marketing piece from ten feet away and immediately see that it’s from Apple, for example.

    In less sophisticated companies, you may see one style applied to print, another to the Web site, and still another applied to the products (or even worse, no consistent style across any of them). You might also find that the company has a style guide geared almost entirely toward print rather than pixels or hardware. If you’re lucky, the style guide will at least take into account the visual design differences between print and Web design. It’s a rare company, though, that has much of a style guide suited to digital product design, so visual and industrial designers must often interpret the spirit of those guidelines across platforms.

    When the style guide doesn’t seem appropriate to what you’re designing, it’s critical to get access to a senior brand stakeholder; a less-senior marketing person dedicated to a product or group often enforces the guidelines without seeing where they should be bent. For example, when my team was designing a phone for one company, the relatively junior marketing person assigned to the product told us it absolutely had to be a certain color and had to contain certain style elements common to the company’s other phones, even though our mandate was total reinvention of the product family. When we were eventually able to get a senior marketing executive involved, he immediately understood why the parameters needed to be varied, so long as the design still conveyed the brand attributes in other ways. This is certainly a tricky situation when you’re an in-house designer; your best option might be to let it go for now, but later try a style treatment that follows the guidelines and one that captures the spirit of the brand even if it breaks the guidelines.

     

    See also

    Excerpted with permission from the publisher, Wiley, from Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin. Copyright (c) 2009.

    05:05

    The Engineering Stakeholder Interview

    This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

    Engineering stakeholders

    Try to speak with engineering management as well as the design engineer(s), if such a role exists; it’s seldom a good idea to involve the entire engineering team at this point. If there are no design engineers, a system architect and GUI lead may be the best option for software expertise. When hardware is required, be sure to involve the electrical and mechanical engineering leads, as well as anyone responsible for manufacturing.

    Programmers and engineers may initially be wary of designers. They may have worked with people who called themselves designers, but who proposed horrendously difficult solutions that seemed “cool.” Programmers may feel that designers are stepping on their toes, since some currently design screens themselves. You might also encounter mechanical engineers who view industrial designers as stylists rather than problem-solvers. However, any technical group’s reluctance to give up control over design is usually due to the fact that so far, they’ve been the most competent to do it. It sometimes takes a while, but once they see that good designers can actually do a better job than they can, most engineers are delighted to let go of the design.

    The focus and length of engineering interviews differs quite a bit between a new product and a revision of an existing one; in the first case, there is more room for the design to drive the technology, while in the second, the capabilities of the existing technology, when combined with the project budget and timeline, may introduce significant design limitations.

    However, don’t ask what you “can” and “can’t” do because in a healthy organization, that will be a business decision and not a technical one—although physics really does limit what you can do with hardware, there’s very little you can’t do with software given sufficient time and budget. Instead, ask what kinds of things would be hard to do and why.

    Engineers also tend to relax more when you say you’re not trying to get them to commit to anything at this point, but simply to get a sense of what they already expect may be challenging. The following questions are helpful on most projects, though most projects call for additional, unique questions, too:

    What technology decisions have already been made, and what’s driving them?

    In the case of a new product, the technology decisions would ideally happen once the design started to take shape, but this is not always the case. When an existing product is being reworked, the technology train may have left the station a long time ago; the software development platform or perhaps several of the electrical components have already been identified. Even decisions that have already been made are sometimes unmade later, though, if the reasons are compelling enough.

    For example, one client told us they had already sunk millions of dollars into a particular system as the basis of their development. However, our later research showed that users had needs this system simply couldn’t address. The company’s executives weren’t excited to see those millions go down the drain, but they were glad they’d learned about the issues before throwing away the additional millions they’d planned to spend.

    How large is the engineering team assigned to the project, and what are their skills?

    This is ideally determined by what the design requires, but in practice there may be a fixed number of people and days allotted to the work. As with technology decisions, though, designers often better serve the business by questioning such parameters than by accepting them. The most important thing to look for is a mismatch between the expectations for the product and the number and skills of the engineers. If you’re designing a big enterprise product and there are only two developers assigned, you’re going to run into trouble.

    Likewise, if the software or hardware team has very limited skills, you may need to scale back your design ambitions, though it’s better to find a tactful way to encourage stakeholders to bring in the appropriate expertise if you can. Lack of skilled programmers was an enormous problem at the height of the dot-com boom, when companies hired anyone who’d taken an HTML class and called them software developers; this seems to be less of a problem during “bust” cycles but is likely to crop up any time there is a shortage of talent. I’ve seen similar issues in organizations where mechanical engineers are only accustomed to doing plastic casings and not designing moving parts.

    You may wonder how a designer can assess the skills of an engineer. In truth, most designers can’t. However, if you have enough experience working with skilled people and less-skilled people, you’ll learn that certain attitudes and behaviors tend to indicate skill level. If you hear engineers saying that something is impossibly hard when half of your last ten project teams were able to build it, you might start to wonder.

    It’s also a bad sign when programmers are anxious about designs they can’t assemble from off-the-shelf libraries; it could mean the timelines are ridiculously short or they’ve seen truly absurd solutions proposed, but sometimes it means they simply don’t know how to build it. The most skilled programmers and engineers get excited about technical challenges, as long as the challenge is there for a good reason and the timeline is reasonably sane.

    Could you draw a diagram and tell me in lay terms how the existing system works?

    Sometimes this is important information; sometimes it isn’t. You probably won’t know until later whether you need it. Certain system limitations, such as client-side data that’s not always synchronized or response times that are very slow, can make interaction design more challenging. The same is true of hardware systems; if it won’t be possible to change certain kinds of boards or other components, you may not have much room to change the form factor. Just be sure to take this information as food for thought, rather than as something carved in stone.

    Note that there’s a reason to ask for an explanation in both visual and lay terms, as shown in Figure 5.2, even if you think you’re well versed in techno-speak—it encourages clarity, and can be another indication of an engineer’s skill level.

    Figure 5.2 Example of an engineer’s system diagram.

    Figure 5.2 Example of an engineer’s system diagram.

    See also:

    Excerpted with permission from the publisher, Wiley, from Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin. Copyright (c) 2009.

    05:04

    The Sales Stakeholder Interview

    This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

    Sales stakeholders

    Sometimes sales and marketing are lumped together in an organization, but most large companies split the two functions. In either case, sales and marketing people tend to have different concerns, so it’s important to include one or more senior members of the sales group as part of the product team. This is true even in companies that ship consumer products, since the distributors or stores to which they sell have their own concerns about things like shelf space.

    An enterprise system sales team is often closer to the customers than the marketing team is. In most cases, though, that doesn’t mean they’re closer to end users—IT tools and systems used by small groups of experts are the likeliest exceptions. They may also be more focused on the here and now, since they’re getting evaluated and compensated based on today’s sales, while the marketing group is more focused on the future. Sales people may be among the voices pushing to ship the product right away. However, this is tempered by the fact that sales people get an earful when the customers are unhappy, so it’s not in their best interests to push for shipment of a product that isn’t ready.

    A sales person’s biggest worry during design research is that there will be other people spending time with his customers, possibly making a bad impression, promising things he can’t deliver, or saying something that will cause the customer to wait and buy next year’s version instead of next month’s incremental upgrade. It’s important to acknowledge these concerns and to promise that you won’t do any of these things.

    Good questions for sales people often focus on what they hear from customers or see at customer sites:

    Who is typically involved in the purchase decision?

    This question will help you identify all of the right people for design research. For example, a hospital IT department may be the apparent customer for an information system, but you may not realize that the heads of medicine, nursing, the lab, and other departments are very influential.

    Why do customers buy a product like this one, and why this one over a competitor’s?

    This is good preparation for later interviews with customers. A related but sometimes useful question is, “What one thing could we do to this product that would make sales easier?”

    When you lose sales, what are the most common reasons?

    People are sometimes puzzled at having a designer ask this kind of question, but it’s helpful in identifying potential product weaknesses. In some cases, though, what customers say is not really what they mean. For example, when people cite a competitor’s user interface as better, sometimes it’s not that the behavior is better, but that the visual design is more attractive. In other cases, the deal is lost because the product lacks important functionality or the workflow is inferior. Naturally, there are also reasons that designers are less able to address, such as poor customer service or shoddy manufacturing, though these are worth pointing out to stakeholders.

    What things do customers complain about or ask for most often, and why?

    Customers, like stakeholders, may ask for certain solutions without identifying the problem they hope to solve; be sure to ask the sales person why customers are asking for particular things. Sales people often don’t take the time to probe and learn the need behind the feature request, but the answer to this question may hint at some things to look for in customer and user interviews.

    See also

    Excerpted with permission from the publisher, Wiley, from Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin. Copyright (c) 2009.

    05:03

    Interviewing Executives and SME Stakeholders

    This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

    Senior executives

    Ideally, there is at least one executive involved who has cross-functional authority and can balance the perspectives of both marketing and engineering; you need this person to make critical decisions, such as what’s worth waiting a little longer for. These are usually the most critical stakeholder interviews, because the way other team members approach product development depends on the views of the people at the top.

    It can be difficult to get on a senior executive’s schedule, particularly if the executives regard the product’s design as a secondary concern. If they seem reluctant to spend the time, point out the kinds of strategic decisions that will be made in the course of the design work. However, most executives are more willing to spend this kind of time than people expect.

    The concerns of senior executives may include any of the concerns mentioned above for marketing, sales, or engineering, as well as a common concern that they can’t get their subordinates to “see the big picture.”

    What do we need to know that you don’t think other members of your team have said?

    Senior executives often have a vision or perspective that others in the organization don’t. If they’ve shared that vision much at all, you will have heard it already from multiple people, but some executives communicate about their vision less than they think they do.

    We know that both timeline and functionality are important, but if you had to choose one, what would it be?

    When there seems to be some controversy about schedule, it’s usually because senior executives are asking to their teams to make omelettes without breaking any eggs. Mention the controversy, then ask what timeline they want you to design for and whether they would rather go to market with an incomplete product or delay shipment to get a product that meets more user needs. (Some designers frame this as “do it fast or do it right,” but it’s best to suspend this kind of judgment; sometimes, doing it “right” means shipping at a certain time to get critical revenue in the door, so tradeoffs have to be made.)

    Subject matter experts

    If you are working on a consumer product or a business product that involves common work or life activities, you probably won’t need domain experts to help you understand what you see in your research. For products in complex industries, though, subject matter experts (SMEs) are incredibly helpful to have around—so helpful that you might want to hire a consultant to spend a few hours here and there, if there is no expert already on the product team. Even in-house designers with a lot of experience working on certain products can benefit from the perspective of people with deep industry expertise, though they may be able to skip some of the following questions. In-house SMEs are usually part of a product management or professional services group.

    A subject matter expert isn’t just someone who was a user (or did a similar job) once upon a time—it’s someone who has broad and deep industry experience and who understands industry best (and worst) practices. If your product overlaps a couple of disciplines, it’s best to have an SME in each; for example, when designing a device that delivers intravenous medication to patients in a hospital, we found it helpful to have the perspectives of both a pharmacy expert, who had a thorough understanding of the drugs, and a nursing expert, who had a thorough understanding of clinical practice.

    Beware of getting presumed SMEs who are a little outside their expertise, though—for example, a surgeon who spends his time in the operating room is not an expert in how nurses do their jobs on the hospital ward.

    Unless they’ve worked with you before, SMEs will be more concerned than anyone else that you won’t be able to understand their incredibly complex world, since it took them many years to get where they are. They usually wind up surprised at how quickly immersion in the usage environment can educate the design team. However, it’s important to be clear that good research techniques will let you develop a working vocabulary and high-level understanding very quickly, but you will be absolutely reliant on the SMEs for their detailed knowledge.

    Spend a couple of hours with SMEs before the user interviews to get some background. Get definitions of terms, ask about best and worst practices, common processes, and regulations. If you’re talking about processes, ask the SME to diagram them on the whiteboard or do this yourself, using your sketches as a discussion tool.

    Specific topics will vary by domain, but here are some typical topics to cover with SMEs:

    What are the typical demographics and skills of potential users, and how much do these vary?

    This information is handy for planning your interview sample, as well as for assessing how typical your actual interviewees seem to be in these respects.

    What distinctions in user roles and tasks would you expect us to see?

    A SME may be able to tell you about likely differences, such as tasks that vary based on seniority or skill levels that differ with geography. They probably won’t be able to point out all of those factors that make people behave differently, but they should at least be able to give you enough background to help determine how large an interview sample you need.

    What sorts of workflows or practices do you think we’ll be seeing in the field?

    Some SMEs will describe only the best practices in their industry, while others are very good at pointing out where reality tends to deviate from what people are supposed to do. This kind of discussion is a great way to think about topics you’ll want to explore in user interviews. However, avoid getting into tremendous detail or spending more than an hour or so on this, because you will still want to look at user behavior from a fresh point of view. A certain amount of ignorance helps you ask the naïve questions that can lead to important insights.

    Other product team members

    In theory, some organizations place QA and support on a par with marketing, sales, and development, but in practice, these organizations seldom have much influence over product direction. However, they may have a variety of useful insights, and at a minimum, they will be able to answer two important questions.

    An experienced QA manager can often tell you how solid the engineering team is and can point out process holes that are currently leading to problems. The support or customer service team can tell you where users are most often encountering problems today, whether this is based on tech support calls for software or common failures for hardware—either could mean a flaw in the current design. In some companies, there are other groups that can provide useful information, as well, such as the training staff or technical writers, who may be able to identify where users most often get confused with the current products. Regulatory experts are also indispensable for medical products.

    See also

    Excerpted with permission from the publisher, Wiley, from Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin. Copyright (c) 2009.

    05:02

    A Stakeholder Interview Checklist

    This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

    A Cheat Sheet For Interviewing Stakeholders

    If you need a little help in your stakeholder interviews, tape a copy of this summary inside the front cover of your notebook.

    Things to watch out for

    • Presumed constraints—ask why they are constraints
    • Jumping to solutions—ask what problem the solution would solve

    All stakeholders

    • What is your role in this project?
    • What did you do before this?
    • What is this product going to be?
    • Who is this product for?
    • When is the version we’re designing going to be released?
    • What worries you about this project? What’s the worst thing that could happen?
    • What should this project accomplish for the business?
    • How will you, personally, define success for this project?
    • Is there anyone you think we need to speak with who isn’t on our list? Who?
    • How would you like to be involved in the rest of the project, and what’s the best way to reach you?

    Marketing stakeholders

    • Who are your customers and users today, and how do you want that to be different in five years?
    • How does this product fit into the overall product strategy?
    • Who are the biggest competitors and what worries you about them?
    • How do you expect to differentiate this product?
    • Using a few key words, how do you want people to see your brand (both the company brand and the product brand)?
    • What is the current state of the identity, and can we see a style guide (if there is one) and examples of it applied to materials?

    Engineering stakeholders

    • What technology decisions have already been made, and how firm are they?
    • How large is the development team assigned to the project, and what are their skills?
    • Would you draw a diagram and tell me in lay terms how the system works? (existing products only)

    Sales stakeholders

    • Who is typically involved in the purchase decision?
    • Why do customers buy a product like this one, and why this one over competitor’s?
    • When you lose sales, what are the most common reasons?
    • What things do customers complain about or ask for most often, and why?

    Senior executives

    • Questions similar to those for marketing stake-holders, plus:
    • What do I need to know that you don’t think other members of your team have said?
    • If you had to choose between going to market on schedule with a flawed product, or going to market late with a solid product, which would you choose? (If there seems to be some conflict on this point)

    Subject matter experts

    • What are the typical demographics and skills of potential users, and how much variation in these is typical?
    • What distinctions in user roles and tasks would you expect us to see?
    • What sorts of workflows or practices do you think we’ll be seeing in the field?

    Other product team members

    • QA: What problems do you currently see in development?
    • Support or customer service: What problems do you see most often?
    • Training or technical documentation: Where do users most often get confused today?

    All parts of the chapter

    Excerpted with permission from the publisher, Wiley, from Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin. Copyright (c) 2009.

    05:01

    Project Management for Stakeholder Interviews

    This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

    With good planning, most of your stakeholder interviews should fit within three or four days. Don’t plan on more than six interviews in a day, since they require a lot more energy than most people expect—you have to absorb what people are saying, figure out what the implications are, lead an effective interview, and take thorough notes all at the same time. A quick lunch and the occasional restroom break are essential. Plan on a short break after every couple of interviews to chat with your teammates, if possible. This table shows an example schedule.

    Monday Tuesday Wednesday 8:00 Kickoff meeting Simon Parker (European sales) 8:30 9:00 Cristina Walker (clinical SME) Nothing scheduled—debrief, review materials 9:30 10:00 10:30 Ellen Kent and Ed Lieberman (product managers), walk through existing system Maria Torres (QA manager) Marty Long (mechanical engineer) and Jay Adachi (electrical engineer) 11:00 11:30 Lunch and debrief Noon Lunch and debrief Lunch and debrief 12:30 Vijay Gupta (GUI lead) and Adam Matievich (lead architect) 1:00 Anders Haglund (sales VP) Collin Smith (CEO) 1:30 2:00 Ron LaFleur (products VP) Cynthia Woo (corporate marketing) Debrief, review schedule with Kate Riley (project owner) 2:30 3:00 Debrief Debrief Gunter Vering (professional services) 3:30 Tim Walsh (director of product management) John McIntyre (support manager) 4:00 Robin Sachs (regulatory issues) 4:30 Debrief, review schedule Debrief, review schedule

    Try for at least a couple of the most critical stakeholders near the beginning of your schedule. If a few of the others need to be worked in between user interviews, that may not be a problem, but it’s preferable to finish stakeholder discussions first. That way, you’ll be aware of all the assumptions, opinions, and open issues you need to address in the user research.

    When You Can’t Interview Stakeholders

    The approach outlined above works well when you have an officially sanctioned project with support from the management team. If you don’t, how can you get some of this information? First, consider trying to get some of these meetings anyway; you may be surprised at how willing some executives are to spend time with you if you ask for help. Send them a persuasive, thoughtful email about how what they know could influence the design and how design decisions can affect business issues. Consider giving them a compelling article or short, interesting book on the subject. Seriously, try anything that won’t get you fired, because their involvement is ultimately necessary for the project to succeed. The one thing that won’t work is whining that you’re being excluded—instead, show them something so impressive they’ll see the value of including you for themselves.

    If you simply cannot get access to the right people, see if you can get access to relevant documents they’ve created—white papers, memos, presentations, or whatever you can find. Build relationships with people in their departments so you can at least get indirect information. Above all, don’t give up—keep looking for opportunities to get them involved. Otherwise, they may very well involve themselves later, often with unfortunate results.

    Summary

    Goal-Directed design isn’t just about accomplishing user goals; a product or service that doesn’t also accomplish a business goal is a failure. Never shortchange your stakeholder research, even if it means compressing your time with potential users. Always:

    • Identify the full range of stakeholders and meet with each
    • Take advantage of the expertise that’s available
    • Learn about hopes, fears, beliefs, and goals
    • Avoid taking assumptions at face value
    • Remember that you’re not just asking questions—you’re also building essential relationships

    Once you have a solid understanding of the business, you’re ready to move on to research with potential customers and users.

    Excerpted with permission from the publisher, Wiley, from Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin. Copyright (c) 2009.

    April 24 2012

    13:30

    Breaking Out of the UX Status Quo

    As a UX Designer you’ve committed your career to helping people. You challenge the status quo everyday…but are you challenging it enough? How about with your deliverables? Your customers are people, too! Are your common deliverables – personas, sitemaps, user-flows and wireframes – really usable or are they just getting in the way?

    It’s no secret to us: user experience designers speak their own language. From personas to user journeys, card sorts to wireframes, there’s a certain vernacular to our profession. It’s something that we learn over the years but that our clientele must overcome immediately.

    Frustrated with the conventional deliverables used to communicate our work, I began to reconsider their presentation. What resulted is certainly not “conventional,” but – taken together – they are arguably more usable.

    Personas are like resumés

    Personas come in all shapes and sizes. Contrary to what they’re designed to do, however, rarely do they convey a good sense of the user. Most look like resumés: sterile and lacking in personality.

    When was the last time you hired someone based on their resumé alone? Even with a resumé you still need to conduct an interview in order effectively gauge a prospect. Seeing someone and listening to their words reveals their personality – the key element missing from most personas.

    So I started a searching for a better way. The first thing I did was move my deliverables online. This allowed me to link them together so that clients could click between them. For desktop projects I use Axure and for mobile and tablet I use Proto.io. Both of them are great tools as they create clickable, HTML-based output.

    Next, I searched high and low for inspiration. This persona, created by User Insight, is definitely different. Therein, the user (Tina) does not consist of mere bullet points; she comes off as a real person. Jason Travis’s personas are infinitely more visual. Being picture-based, though, they lack any descriptive text whatsoever.

    Inspired by these (plus adding my ideas and style) I tried to put together a new version of the traditional persona.

    Barnabas's persona

    You can view a demo here.

    This approach paints a much more holistic picture of a person. Not only does it include their goals, it includes important, ancillary information such as their worldview, what they are looking for and their motivation. Further, the overheard conversation adds just the right amount of insight into his/her life. The “questions” section helps identify the areas the target user is unsure of and the “life pieces” section makes the persona human-like with feelings and desires.

    Sitemaps are like spiderwebs

    Sitemaps are (as most of you know) used to “map” the major components of a website to a rather sparse-looking diagram. Because they’re so sparse, they also tend leave a lot to the imagination. This gives rise to common retort: “What’s this page do, again?” “Can you change this page to that?” “How about we scrap that page”

    You know the routine. Because clients come to us for the visual thinking they often can’t turn these sparse diagrams into anything “useful” on their own.

    This got me thinking: why not just put the thinking alongside the map?

    Barnabas's persona

    You can view a demo here.

    Even though it’s just a small difference, this approach pays off. It helps our clients understand the internal monologue that drives the narrative. Knowing the reasoning behind your decisions helps others understand (and agree) with your perspective.

    User journeys are like electric panel diagrams

    User journeys map the steps of a user, correlating goals (explained in Personas) with a site map to better illustrate how users will get things done. As a result, designers can make informed suggestions to the site’s information architecture.

    The problem is that most user-flows are very dry. It is difficult to feel empathy with a user and their journey if all you see are boxes and arrows (similar to electric panel diagrams).

    After scouring the internet looking for something better I found a couple of good approaches.

    Jakub Linowski's user flow

    Jakub Linowski’s Grand Narratives & Play Points diagram offers a compelling yet easy-to–understand presentation based on wireframes.

    A user journey from the Bluepoint+ deliverable framework

    Blueprint+ (Service Design Visual) is great because it includes the persona and a timeline.

    Carlos Abler's user journey

    Carlos Abler’s Multiuser WireFlows combines the two former ideas.

    All of these are good but they all seemed to be missing something.

    I’ve been always fan of recycling, so I thought there has to be a way to re-use the sitemap and display the user-flow on it. I also wanted to re-use my personas in order to create empathy for the user’s journey. This led me to the following presentation:

    Barnabas Nagy's user flow

    You can also view a demo here.

    As you can see, I simply re-used my sitemap and added one of my persona with speech bubbles. In the speech bubbles I added the thoughts of the persona at every stage of their journey. This adds a human touch. The thoughts of the persona can explain to clients the reasons for the journey taken and the scenario puts these thoughts into context. It is simple but visually understandable way to show your user-flow.

    Clients that already understand your sitemaps and personas will have no trouble seeing the two work together.

    Prototypes/wireframes are like abandoned houses

    Wireframes created in the absence of personas are broken. Yet we do this all the time. Why do we create personas if we don’t use them?

    Looking for a better way, I saw a picture in the essay of Rósa Gudjónsdóttir:

    A man working next to two cardboard cutouts of personas.

    I was fascinated by the idea of having my personas around me. I started to print my personas and stick them to the wall in front of me. It helped, however, the screen and the wall are two different worlds, analog and digital. No good.

    I eventually placed my personas in the margin of my prototype to serve as a constant reminder of who my users are:

    A wireframe juxtaposed with persona avatars.

    You can also view a demo here.

    Not only does this help us to not design for ourselves, our clients and stakeholders are now constantly reminded who will use our design. The time and effort we put into establishing our personas is never lost.

    Never stop learning

    As I mentioned earlier, these ideas have helped me better convey my work to my clientele. They are not perfect, of course, nor were they intended to be. I am certain that it is possible to tweak them or in fact come up with even better presentations that work for you.

    Are you also frustrated with common UX processes or deliverables? Don’t let the status quo get you. Always try to make things better, iterate and optimize. Surprise your users – err, clients – with something new and innovative as this is the way forward. If you’ve tried your hand at something different, be sure to share your result in the comments below!


    September 07 2011

    18:40

    Alignment Diagrams

    Alignment diagramsDid you ever get bounced around between departments when interacting with a company or service? This happened to me recently with my credit card: the card issuer and the bank backing it seemed to disagree who was responsible for my problem. Each blamed the other. I got caught in the middle.

    My communication with them also crossed multiple channels. For some things I used their website, for others I had to call. There were emails, regular mail and even a fax involved as well. None of it seemed coordinated. Apparently it was my job to piece it together. Bad experience.

    Why does this happen? All too often companies are focused on their own processes, wrapped up in a type of organizational navel gazing. They simply don’t know what customers actually go through.

    What’s more, logical solutions can cross departmental lines. Ideal solutions may require crossing those boundaries. An organization’s rigid decision making makes that difficult.

    Here’s where I believe IAs and UX designers can use our skills to make a difference. We have the ability to understand and to map out both business processes and the user experience. Visual representations can provide new insight into solutions that appeal to a range of stakeholders. Alignment diagrams are a key tool to do this.

    Mapping The Experience

    Alignment diagrams reveal the touchpoints between a customer and a business. Illustrating these helps a company shift its inward-focusing perspectives outward. Alignment diagrams make the value creation chain visible.

    The phrase “alignment diagrams” describes a class of documents that reveal the touchpoints between a customer and a business. These touchpoints are organized and visually aligned in a single graphical overview. Illustrating these touchpoints helps a company shift its inherently inward-focusing perspectives outward. Alignment diagrams make the value creation chain visible from both sides of the fence.

    Alignment diagrams are not new. In fact, you’ve already used them. Thus my definition of alignment diagrams does not introduce a new technique but rather recognizes how existing techniques can be seen in a new, constructive way. 

    Alignment diagrams have two major parts. On the one side, they illustrate various aspects of user behavior—actions, thoughts, and feelings, among other aspects of their experience. On the other side, alignment diagrams reflect a company’s offerings and business process in some way. The areas where the two halves meet gives rise to touchpoints, or the interactions between customers and an organization.

    Below are examples of two diagrams that illustrate the alignment principle.

    Example 1: Service Blueprint

    The first example is a service blueprint created by Brandon Schauer of Adaptive Path (Figure 1.). This shows the chronological flow of steps for attending a live event, in this case a panel on service design. (See the original details of the event from 2009 [1]).

    The top two rows show the phases and physical devices a participant might use. We can call this the “front stage.” The bottom three rows show the activities of the organizer. These are “backstage” activities. These two parts are separated by the “line of interaction,” or touchpoints between participants and organizer of the event.


    Service map

    Figure 1: An example of a simple service blueprint by Brand Schauer, Adaptive Path


    Example 2: Mental Model Diagram

    The next example of an alignment diagram is a mental model. Indi Young developed this technique and detailed it in her book Mental Models (Rosenfeld Media, 2008) [2].

    Figure 2 is a slightly simplified version of a mental model diagram, but it shows the alignment principle well. This example shows a mental model for activities related to “getting up in the morning.” The top half hierarchically arranges user actions, thoughts and feelings gleaned from primary research. These are clustered together into broader “goal spaces” (e.g., “Get Dressed”).


    Below the center horizontal line are products and services that support people in these activities. With this alignment, providers of goods and services can see where they address user needs and where there are gaps.


    Mental model

    Figure 2: An example of a mental model diagram by Indi Young, reflecting the alignment principle.


    There are other visual styles and approaches to alignment diagrams beyond the above figures. (See the list of Alignment Diagram resources at the end of this article.) Customer journey maps and workflow diagrams are also examples. So there is no single approach to the alignment technique. Instead, you choose the form, the information included, and the way you present them to shape your overall message. It depends on your situation. The important thing to remember is that an alignment diagram shows user behavior aligned to business activity to reveal touchpoints.

    Locating Value

    An analysis of the touchpoints between users and the business lets us see value creation from both sides of the equation at the same time. This is at the core of the alignment technique.

    Businesses ultimately need to earn money. But to do so they also have to provide some value to customers. An analysis of the touchpoints between users and the business lets us see value creation from both sides of the equation at the same time. This is at the core of the alignment technique.

    In a previous Boxes and Arrows article entitled “Searching for the Center of Design,” Jess McMullin proposes what he calls “value-centered design.” [3] Instead of focusing solely on the business or solely on users, Jess advocates focusing on how value is created for both. “Value-centered design” is the approach he prefers. He writes:

    The basic premise of value-centered design is that shared value is the center of design. This value comes from the intersection of: business goals and context, individual goals and context, and the offering…and delivery.

    Value-centered design starts a story about an ideal interaction between an individual and an organization and the benefits each realizes from that interaction.

    Jess McMullin, “Searching for the center of design”, Boxes and Arrows, 2003.

    Alignment diagrams let us tell the story of value creation.

    Once completed, alignment diagrams serve as diagnostic tools. With them we can spot and prioritize areas for improvement. They also point to opportunities for innovation and growth. Ultimately, alignment diagrams let designers capture and reflect how value is created in a holistic way. When communicated to decision makers, this can have real business impact by changing the focus from how products are made to the experience customers have.

    Who Creates Alignment Diagrams?

    Modern business challenges are wicked problems. Organizations unknowingly pass this complexity on to customers, resulting in negative user experiences. Alignment diagrams can reduce complexity for both customers and for organizations. They are an antidote to the challenges our business partners face.

    The good news is you probably already have the skills needed to create alignment diagrams. These include:

    1. Conducting Research

    Alignment diagrams are not made up. They are based on real data. Face-to-face interviews and observation work best. This includes contacting people on the business side: stakeholder research is part of the alignment technique.

    2. Synthesizing Findings

    Designers are good at describing abstract concepts, such as an intended experience. We’re able to empathize with users and summarize their perspective well. And we can communicate this back to our business partners in a way they can understand.

    3. Visualizing Information

    Alignment diagrams are visual stories. Designers are good at representing ideas in graphic form. The visual nature of alignment diagrams makes them compact and immediately understandable.

    4. Brainstorming

    Alignment diagrams serve as an excellent stimulus for a workshop or brainstorming session. Designers have the skills to creatively brainstorm and lead such sessions.

    5. Prototyping Solutions

    Exploring different directions is a key aspect of “design thinking.” Designers are well-versed in trying out different options—from sketching to wireframing to prototyping.

    Keep in mind that the lines between design-related disciplines are blurring. Service designers increasingly use online services and digital kiosks in their concepts. UX designers must be able to integrate offline support and services into their solutions. IAs need to be able to structure information across channels, including physical spaces. Interaction designers must conceive of workflows and actions across media types and devices.

    In the end, alignment diagrams aren’t the domain of one field or the other: they can inform any field. The skills needed to create them, listed above, cross these lines as well.

    Getting Started

    Alignment diagrams start a conversation towards coherence, bringing actions, thoughts, and people together to foster consensus. More importantly, they focus on creating value—for both the customer and the business.

    Understanding the mechanics of alignment diagrams is fairly straight forward. The hard part is getting your foot in the door. Often designers aren’t called in until after a project is already set up. Alignment diagrams, however, really need to impact decisions much earlier in the process—before a project even starts. This means you need to “swim upstream” and reach out to a potentially new set of stakeholders.

    For designers in internal teams, you may have access to managers, product owners and other executives who could benefit from alignment diagrams at a strategic level. For external consultants, pitching a case for an alignment diagram effort may be harder: reaching high-level decision makers is difficult. Either way, you’ll need to effectively evangelize alignment diagrams in order to get the time and money to complete one.

    Here are some things you can do to get started:

    1. Learn about alignment diagrams.

    Start by reading books like Indi Young’s Mental Models. Or, check out things like my resources on customer journey mapping on the web [4]. I also have a presentation [5] and an article [6] coauthored with Paul Kahn specifically on alignment diagrams.

    2. Sketch draft diagrams for your current project.

    What story could you tell on your current project to show where customer value and business value is located? How would best visualize that story in a diagram? Even without any official project scope or user research, you can sketch out a rough map showing the facets of information you’d include, where alignment occurs, and how you would visually convey your message. This is practice in understanding the alignment technique.

    3. Complete an alignment diagram “under the wire.”

    A formal alignment diagram must be based on real evidence. But this evidence could come from a variety of sources. A high-level customer journey map, for instance, could be created with data from existing research. Or, try adding a few simple questions your next usability test to understand users’ interaction with a service. Create a draft diagram from this data as you do other types of analysis. Present this to stakeholders. It’s likely they’ll find it interesting and ask for more.

    4. Find a champion in management.

    Seek out business partners who might “get” alignment diagrams. Discuss the possibility of a pilot project with them. For the cost of a normal usability test, for instance, you could create a simple alignment diagram. Unlike outcomes from other types of research, such as marketing studies or usability tests, alignment diagrams do not change very quickly. Be sure to highlight the longevity of an alignment diagram effort to sponsors, and remind them they’ll be able to refer to the information years later.

    Conclusion

    Truth is, the business world is becoming increasingly complex. Studies in business complexity show that leaders are unable to cope: they are pulled in different directions and unable to focus [7, 8]. Modern business challenges are wicked problems. All too often, organizations unknowingly pass this complexity on to customers, resulting in negative user experiences.

    While they do not guarantee success, alignment diagrams can reduce complexity for both customers and for organizations. They are an antidote to the challenges our business partners face. At a minimum, alignment diagrams start a conversation towards coherence, bringing actions, thoughts, and people together to foster consensus. More importantly, they focus on creating value—for both the customer and the business.

    Designers can use their skills to map out value creation and help solve business problems. Empathizing with users and illustrating out their experiences plays a big role. Visualizing touchpoints provides an immediate “big picture” often lacking in many organizations. This can provide a much-needed shift of attention from inside-out to outside-in. Alignment diagrams are a class of documents that seek to address the causes of poor experiences at their roots and ultimately help designers have a real business impact.

    Footnotes


    [1] Brandon Schauer, Service Blueprint, http://adaptivepath.com/ideas/this-thursday-in-sf-service-design-panel-kicker-kickoff

    [2] Indi Young, Mental Models (Rosenfeld Media, 2008). http://rosenfeldmedia.com/books/mental-models/

    [3] Jess McMullin, “Searching for the Center of Design,” Boxes and Arrows (Sept 2003). http://www.boxesandarrows.com/view/searching_for_the_center_of_design

    [4] James Kalbach, “Customer Journey Mapping Resources on the Web.” http://experiencinginformation.wordpress.com/2010/05/10/customer-journey-mapping-resources-on-the-web/

    [5] James Kalbach, “Alignment Diagrams: Strategic UX Deliverables,” Euro IA Conference (Paris, 2010). http://www.slideshare.net/Kalbach/james-kalbach-alignment-diagrams-euro-ia-2010

    [6] James Kalbach and Paul Kahn, “Locating Value with Alignment Diagrams,” Parsons Journal of Information Mapping (April 2010). http://piim.newschool.edu/journal/issues/2011/02/pdfs/ParsonsJournalForInformationMapping_Kalbach-James+Kahn-Paul.pdf

    [7] IBM, “Capitalizing on Complexity,” (2010). http://www-935.ibm.com/services/us/ceo/ceostudy2010/

    [8] Booz & Co, “Executives Say They’re Pulled in Too Many Directions and That Their Company’s Capabilities Don’t Support Their Strategy,” (Feb 2011). http://www.booz.com/global/home/press/article/49007867

    January 05 2011

    09:05

    Storyboarding iPad Transitions



    If your clients are not yet asking you to design transitions, they will likely do that on your next project. Transitions are hot, and not just because they entertain the eye. In confined mobile computing interfaces, on tablet devices or in complex virtual environments, transitions are an authentic, minimalist way of enabling way-finding, displaying system state and exposing crucial functionality – in short, they are key in creating a superior user experience.


    Transitions as design elements


    Since the 1980s, designers have been drawing wireframes to represent web pages and device interfaces.1 In the beginning, wireframes were static schematics that showed a single state of the page. With the emergence of dHTML in the 1990s, it became necessary to draw different states of specific dynamic page elements, so the designers adapted the wireframe methodology to document the beginning and end states of the dynamic elements. Still, designers and engineers had little or no control over what happened in between the beginning and end states—the browser or the operating system handled all transitions.

    More recently, sophisticated mobile touch frameworks like iPhone, Android, Palm and Windows Mobile allowed unprecedented control over the speed and structure of the transitions, giving designers more tools with which to create a better experience in a confined mobile space.2 Simultaneously, on the web, dynamic platforms like Flash and Flex gained tremendous ground, making it possible for designers to think about and document transitions because those were now part of the customer experience.

    With the release of the Apple iPad, the Age of Transition has come to its full potential. On the iPad, Apple takes full advantage of some of the principles and ideas the company previously explored and perfected using the iPhone. On the bigger iPad screen, transitions achieve a new level of detail and sophistication, making the device come alive, and become a powerful, integral part of the experience.


    Transitions Require Thinking Differently


    As Jonathan Follett writes in his article “Interfaces That Flow: Transitions as Design Elements”:http://www.uxmatters.com/mt/archives/2007/04/interfaces-that-flow-transitions-as-design-elements.php, 3 many UX designers approach projects from a combination of information architecture and interaction design. These disciplines involve thinking that is quite different from constructing the continuous linear narratives required to design and document transitions. Nevertheless, by borrowing freely from the lessons of early animators, it is quite possible to adopt the existing wireframes methodology to convey the structure and rhythm of a user interface transition.

    The task consists of wireframing each of the important changes (or “key frames”) that occur during the transition and stringing a bunch of wireframes together in a storyboard. By documenting the key aspects of the transition, it is possible to share them with the larger team and try out different transitions designs. Documenting the transitions also allows us to step back and consider them in a larger context of a specific use case or overall goal of progressive engagement and immersion.


    Understanding iPad Transitions


    In order to be able to design and document transitions using storyboards, we have to first understand design principles that designers of transitions use to convey the desired meaning. Let’s take a look at the Apple, Inc. video in Figure 1 showing selected transitions from what is arguably the most popular iPad application today: iTunes. Although many different transitions are shown in the video, we will be specifically looking at the two of them: “opening the iTunes application” (0:17-0:20 min) and “opening album details” (0:30 -0:36 min).




    Figure 1: Video of iTunes transitions on the iPad [“View larger version on YouTube”:http://www.youtube.com/watch?v=Z03PR_4Ln90]


    Borrowing from Chet and Guy’s excellent Devoxx presentation “Animation Rules!”:http://www.parleys.com/#st=5&sl=1&id=1578,4 we can identify seven key principles that specifically apply to the animated transitions on the iPad: # Component Relationship (background-foreground) # Illusion (motion perception and perceptual constancy) # Exaggeration (highlighting states, actions, and changes in state) # Staging (camera view, lighting, focus) # Acceleration and Deceleration (slow in and out) # Metaphors (using real-world analogies to convey complex digital events) # Simplicity (avoiding noise)

    To understand how the seven principles above apply combine to make the transition work its magic, let’s do a step-by-step breakdown of the “opening the iTunes application” transition, shown in Figure 2.


    Figure 2: Step-by-step breakdown of the

    Figure 2: Opening iTunes Application Step-by-Step


    Using our seven key principles:

    Component Relationship (background-foreground)
    
This transition is essentially the process by which the iTunes application comes into the foreground, while the rest of the apps recede into the background. In the first row, the transition starts out with the home screen and apps icons firmly in the foreground. By the end of the row, we can see that the home screen recedes and darkens, while the iTunes app (represented by a white square) slowly comes into the foreground. By the second row, the background-foreground transition is essentially complete – we can see only the loading iTunes app against the black background.

    Illusion (motion perception and perceptual constancy)

    This transition creates its magic via an illusion of “flying into” the device, and eventually meeting the white square that represents the iTunes app. To accomplish this, the animation shows us “flying” through the layer of the apps icons on the home screen. The other app icons begin to “fly” to the sides of the screen in a circular pattern, as shown in row 1. The most interesting part of the illusion is the kind of “bait-and-switch”. If you look carefully, you’ll see that the app icons never make it off screen. Just before we “pass through the icons layer” and “witness” the icons “flying off screen”, the background goes completely black, and our attention is focused on the white rectangle. The illusion is complete.

    Exaggeration (highlighting states, actions, and changes in state)
    In this transition, the lighting effects are used to exaggerate the switch between the background and foreground. In the second row, the background goes completely black, to highlight the change in state. Exaggeration can also be used to warp the shape of an object to emphasize movement, as in is used more in the “genie” effects and transitions.

    Staging (camera view, lighting, focus)

    Subtle but powerful lighting is used throughout the transition as the primary means for focusing our attention on the foreground of the opening window of the iTunes app through subtle darkening of the background (principle 1). Lighting is also used to accomplish the bait-and-switch in the Illusion principle.

    Acceleration and Deceleration (slow in and out)
    
Our brains know from experience that objects do not start running at top speed or “stop on the dime”. To make the movement more life-like, the animation accelerates into the movement very slowly, picking up pace in later screenshots, as evidenced by the increasing “smudginess” of the icons in the first row. Not surprisingly, the bait-and-switch happens in the fastest moment of the transition to pull of the illusion that the homepage icons actually “fly off screen”. The transition then slows down again in the last row to smoothly fade in the iTunes content elements, deliberately giving the auxiliary page elements and pictures time to “catch up” and making the page load appear smoother.

    Metaphors (using real-world analogies to convey complex digital events)
    
The most effective transitions use real-life elements to provide a frame of reference which makes the animation more realistic. In this case, the icons on the home screen are moving to the sides, creating an overall illusion of moving through space, or deeper “into” the device itself to convey a digital event of opening an application inside the device.

    Simplicity (avoiding noise)
    The overriding theme of this transition is its apparent simplicity. During the transition, iTunes is not doing anything particularly complicated or earth-shattering. The magic comes not from one particular element, but through carefully blending and combining the lighting and movement to create a smooth cohesive digital dance, perfectly orchestrated from beginning to the end.


    Storyboarding iPad Transitions


    The key to successfully designing and storyboarding the transitions is understanding and applying the seven animation principles we discussed above. To demonstrate how this can be done, let’s use a slightly more complex transition: the iTunes “opening album details”, shown in Figure 3.


    Figure 3: Opening iTunes Album Details Step-by-Step

    Figure 3: Opening iTunes Album Details Step-by-Step


    Here again, we see the seven principles at work:

    Component Relationship (background-foreground)
    
This entire transition can be viewed as bringing the selected album cover into the foreground, while the rest of the iTunes application recedes slightly into the background.

    Illusion (motion perception and perceptual constancy)

    The animation shows us the illusion of the album flying forward on the screen while flipping 180 degrees. The most interesting part of the illusion is the switch from darker gray “back” of the album to a while loading screen (midway through the second row). This sleigh of hand changes the focus to the white cover to make the transition believable.

    Exaggeration (highlighting states, actions, and changes in state)
    
In this transition again, the lighting effects are used to exaggerate the switch between the background and foreground. Midway through the second row the album turns completely white against the slightly darker background.

    Staging (camera view, lighting, focus)

    In the beginning the iTunes application darkens gradually, and reaches its full saturation about half-way through the second row to create the background against which the album will be staged. The album, on the other hand, switches first from color to darker gray, then to solid white to jump to the foreground.

    Acceleration and Deceleration (slow in and out)
    
The animation starts slowly, and achieves top speed half-way through the second row to quickly switch from the dark gray flipping rectangle to a solid white loading page. Just as in the previously discussed “opening iTunes” transition, this transition also slows down in the last row to smoothly fade in the iTunes album cover content elements.

    Metaphors (using real-world analogies to convey complex digital events)

    This transition invokes the magical feeling of opening picking the old LP album off the shelf and flipping it over to see the back cover by creating the illusion of the album jumping off the page and flipping 180 degrees horizontally around the middle.

    Simplicity (avoiding noise)

    While a bit more complex than the “opening iTunes application”, this transition can nevertheless be adequately described by looking at only 12 screenshots.


    Once the transition design principles are understood, the process of drawing the storyboard becomes fairly straightforward. I use the same method that Galileo Galilei used four centuries ago when he first diagrammed the step-by-step movement of the sun spots in 1613.5 The basic transition storyboard for the “Opening iTunes Details” transition is shown in Figure 4.


    Figure 4: Storyboarding iPad Transitions Using Post-it Notes

    Figure 4: Storyboarding iPad Transitions Using Post-it Notes [“See larger version”:/files/banda/storyboarding-ipad/figure4_ipadtransitions_postitnotes_large.png]



    Now Start Making Your Own Transitions


    As you try your own hand in transition storyboarding, here are a few points to keep in mind:


    Use appropriate materials



    To diagram transitions, I prefer to use medium-size post-it notes that measure 3-inch square. I draw each of the steps in the transition using a soft retractable pencil with a good eraser. This allows me to quickly diagram portrait and landscape transitions, and everything in between. Because the iPad is a rectangle, not a square, I leave the extra space left on the right of the post-it note (on the bottom for landscape) to write the additional explanation for each step or simply leave it blank.


    Simplify shading



    As I said above, on the iPad the lighting is foundation to expressing Component Relationship, Exaggeration, and Staging principles, so it makes sense to take a disciplined approach to drawing various shades of light and dark in your storyboard. I find that the easiest approach is to draw shading on top of the picture as light lines at a 45 degree angle. As you can see in the last three post-its, I use tighter line spacing to indicate progressively darker shading.


    Get the basics down first



    When I first approach the transition design, I make only the post-its necessary to convey the overall movement of the various elements and basic component relationship. I sketch quickly using very rough strokes, and use a ruler and templates whenever possible to make my job easier.


    Stick to 6-8 post-its


    
As you can see in Figure 4, it is not necessary to draw all 12 original key frames we saw in figure 3. To convey the basic structure of a transition, I typically try to use only 6-8 post-it notes. Using fewer steps keeps me focused on the principle of simplicity: if it takes me more than 8 post-it notes to describe the transition, it is probably too complex and I immediately look for unnecessary elements or animation that needs to be eliminated or scaled back.


    Ignore Acceleration and Deceleration



    Above we spoke at length about the Acceleration and Deceleration principle. This idea is essential to creating effective, believable transitions. However, when drawing a rough storyboard of 6-8 post-its, this is the one principle that I found can be safely ignored. Once people understand this principle, most folks can extrapolate from your rough drawings to imagine the complete smooth transition “in their mind’s eye”. As long as you make it clear to your team that this is only a rough storyboard that the end result will in fact follow the principle, you can safely ignore the subject and concentrate on the relationship, movement and shading of screen elements.


    Draw the complete story


    
Transitions do not happen in isolation – they are an integral part of the overall customer experience. Thus, when I storyboard transitions, I typically do it in the context of the entire use case. This helps me make sure that the particular transition makes sense in the complete context and in combination with other transitions. For example, when I use the “flip” transition to show the search results on the map, and then use the “slide back” transition to go back to the list of search results, the storyboard will quickly reveal the inconsistency in the mental model of the interface I am trying to create and the problem transition will feel awkward when walking through the use entire storyboard.


    Sketch a few different transition designs



    When I approach a given transition, I usually try out 3-4 different design approaches to see which transition creates the effect I am seeking. Sometimes I find that I need to create 10 or more sets of ideas for more complex and critical interactions. The point of this initial sketching is not to create the complete and final blueprint, but to help you visualize how a given transition design option would feel with the rest of the app interactions. Doing the transition with post-it notes allows me to quickly add a new transition or re-position the existing post-its to create and try out several different scenarios, often while engaging in the active team discussion. I recommend you make copies or take photos of your boards periodically to preserve promising design directions before repositioning the post-it notes and changing the transition layout again.


    Obtain Initial Stakeholder Approval


    
In addition to helping you find the best design approach, a rough storyboard is also a fantastic tool for conveying various design options to your team for joint discussion and brainstorming as well as for obtaining initial stakeholder buy-in. It’s a lot easier to discuss the merits of a particular transition movement and information architecture when everyone is quite literally on the same page looking at your complete use case storyboard.


    Creating the Final Transition Blueprint


    When you obtain the initial stakeholder approval using your rough storyboard drawing, you will need to document the final storyboard design that the engineers to actually create. Here you have a couple of options.

    One approach is to use Flash to create the transition with the final high-fidelity look and feel. This is certainly a valid option. However, I found Flash to be more useful for higher-fidelity usability testing and final stakeholder approval than for describing transitions to engineers. Here is why: most developers do not read Flash code and most transitions are simply too fast for the eye to understand in detail the subtleties of acceleration and shading simply by looking at a running a Flash file. I have had several instances of getting not exactly what I specified or else getting something completely different, only to have the engineers claim that “this is exactly what the Flash looked like”. This is especially a big problem with distributed multi-lingual teams where communication is an issue.

    The method that I found to work well is to specify (e.g. create a wireframe for) each of the frames at regular intervals of every 50-100 milliseconds for the entire duration of the transition. Most transitions are between 0.5 – 1.2 seconds, so you will need to create anywhere between 5-24 wireframes in your favorite wireframing tool such as Fireworks, OmniGraffle or Visio. Stringing these frames together in document pages will create a short movie that will comprise the complete blueprint that will describe the position, shading, and movement of each element that will communicate clearly and exactly so the engineers can create the exact transition you envisioned.

    While this seems at first like a lot of work, after a bit of practice the wireframing goes fairly quickly, as the difference between the each new page and the one before it is only a slight change in position and shading. As long as we firmly keep in mind the principles by which iPad transitions work, we can easily diagram relevant steps for rich, expressive transitions.

    To continue this conversation, add a comment below or reach out to Greg at ”@designcaffeine”:http://twitter.com/designcaffeine or through his website, “DesignCaffeine.com”:http://www.DesignCaffeine.com.

    Interested in more UX sketching techniques? Join us Saturday, May 28th, 2011 at UX SketchCamp [“SketchCamp.com”:http://www.sketchcamp.com or ”@sketchcamp”:http://twitter.com/sketchcamp on Twitter] in San Francisco for a chance to learn from the experts, practice UX sketching and share what you know with others.




    References


    1. “Wireframing Marathon Starts”:http://ciohappyhour.com/wireframing-marathon-starts/; CIO Happy Hour, September 2010

    2. See my article “Designing Mobile Search: Turning Limitations into Opportunities”:http://www.uxmatters.com/mt/archives/2010/03/designing-mobile-search-turning-limitations-into-opportunities.php; UX Matters, March 2010.

    3. Jonathan Follett; “Interfaces That Flow: Transitions as Design Elements”:http://www.uxmatters.com/mt/archives/2007/04/interfaces-that-flow-transitions-as-design-elements.php; UX Matters, July 2007

    4. Chet Haase and Romain Guy; “Animation Rules!”:http://www.parleys.com/#st=5&sl=1&id=1578; Devoxx ‘09

    5. Galileo documented the movement of the sun spots in his triumphant “Istoria e Dimostrazioni Intorno Alle Macchie Solari e Loro Accidenti Rome”:http://physics.ship.edu/~mrc/pfs/110/inside_out/vu1/Galileo/Things/g_sunspots.html (History and Demonstrations Concerning Sunspots and their Properties); 1613.

    September 13 2010

    22:19

    So You Wanna Build a Library, Eh?

    Modular Web Design book coverThe following article is an abridged version of Chapter 7 of Nathan Curtis’s 2009 book, Modular Web Design published by New Riders. The book’s first half addresses how to modularly break down your design, build it back up, and communicate in new and interesting ways. With those design techniques in hand, the book then drills into how to organize and build a library, teach it to others, and establish a process for maintaining it for an organization.


    Legos are so freakin' awesome!!! Design patterns and modular components are effective techniques for designing and building long-lasting, consistent experiences. You may reach the point where you ask yourself “Is it time to build a library for our team?”

    Many teams have realized incredible efficiencies, savings, and better design through design libraries and related standards. However, building a library isn’t trivial. It takes time and effort to get off the ground, can trigger significant and uncomfortable organizational change, and comes with an ongoing maintenance cost. In some cases, libraries are not the answer and yes, sometimes libraries fail. Nobody wants to invest the time, effort, and personal capital only to have nothing to show for it.

    Therefore, precede any kind of library build out with a period of discernment. Before you dive, ask yourself and your teammates the following eight questions to gauge whether a library is right for you.


    1. Why Do You Want Create a Library?

    What is your primary rationale for building a library? What motivates you?
    At the top of nearly everyone’s list is usually one of two benefits: efficiency or consistency. Some value speed through reuse: get design done faster, be more productive, save time, save money! Others see opportunities for governance and consistency, using the library as a baseline to sustain a design system over time.

    Many teams have realized incredible efficiencies, savings, and better design through design libraries and related standards. However, building a library isn’t trivial.

    Beyond efficiency and consistency, other benefits that drive teams include:

    Memory: A destination to record and refer to all the design decisions made in creating a large-scale experience.

    Portability: Designers come and go. Project priorities change. A library should make you more nimble in shifting resourcing and focus.

    Vocabulary: Establish and promote common understanding that includes terms you use for items, page types, and even deliverables.

    Authority: Provide a more credible resource on which to make design decisions, prioritize efforts, and easily refer to conventions.

    Predictability: Have a foundation to discuss and more closely approximate the impact of a design decision.

    Collaboration: Amp up collaboration in your organization to trigger conversations, share knowledge, and learn together.



    2. Are You Building the Right Kind of Library?

    When it comes to libraries, teams usually find themselves choosing between a library of patterns or components.

    A design pattern is a solution to a recurring problem. Patterns offer principles to follow and avoid specifics like style, editorial guidelines, page location, and finalized code. Libraries of design patterns are ideal for teams that design many experiences, such as Yahoo’s team that designs products with unique visual systems that adhere to a larger, common brand.

    A component is a chunk of a page design. Experiences can reuse components for navigation (such as header, footer, and local nav), content (such as video players and page titles), and more. A component library is ideal for organizations that have built a system of modular HTML and CSS, and these teams can complement the code library with a collection of reusable design assets for wireframes or comps.

    Choosing between patterns and components may not be an either / or question. In fact, one team built libraries for both patterns (for example, Tabs) as well as components (for example, tabbed product details, tabbed content module, tabbed search results, and so on). Other teams have hedged their bets by embedding aspects of one approach into the guidelines and spirit of the other, most commonly via pattern-like guidelines incorporated into the more specific component definitions.

    Consider a pattern library if your team has:

    • Many design systems that are intentionally different or will not be reconciled into a single component library.
    • Capability to document patterns more specific than public libraries like Yahoo Design Patterns, welie.com, and ui-patterns.com.
    • Known opposition to prescriptive approaches, but a willingness to use common guidelines.

    Consider a component library if your team has:

    • A specific visual design system, including grid(s), layout, color palettes and typography.
    • Many reusable components (page “chunks”) within that system.
    • Diverse groups across an organization that must work together using that system.
    • Interest in and capability of sustaining that design and code system across groups, projects and time.
    • Strong, centralized influence to create, deploy, and maintain a library (or plans to centralize influence via a library).
    A comprehensive library of design standards doesn’t end with design patterns and modular components. A team could consider … include the design frameworks espoused by Robert Hoekman as well as common standards like page types/templates, editorial standards, a style guide, and more.

    Finally, a comprehensive library of design standards doesn’t end with design patterns and modular components. Instead, a team could consider expanding their repertoire to include the design frameworks espoused by Robert Hoekman as well as common standards like page types/templates, editorial standards, a style guide, and more.


    3. Is Your Experience Ready for a Library?

    Ok, so you’ve got dreams of efficiencies, consistency, standards, and more. However, just because you’ve built a website, that doesn’t automatically imply that you should build a library. In fact, there are plenty of websites for which a library won’t net any benefit. You should take a long, hard look at your design system to ensure it warrants a library.

    Scale: Libraries can be invaluable to large, distributed teams supporting many products or a site with thousands – or millions – of pages. On the other hand, if you are a small and tight-knit team constantly communicating across cube walls, then there’s no need to codify standards. Heck, there’s no need to document anything at all – just get real and build stuff.

    Relevance: Rarely do experiences of any scale contain no reusable elements. However, some site areas – like an e-commerce checkout or an account management portal – may be unique, built once, and not duplicated again short of a redesign. Why standardize something that’s never reused?

    Stability: Be careful not to standardize an experience too soon. A design system should stabilize before you invest in codifying layouts, grids, typography, patterns, and components.

    Disparity: Instead of one simple set of grids, styles, and reusable chunks, you may have multiple, distinct design systems. Do you merge them into one library? If now, is it worth it to create distinct and potentially overlapping libraries?



    4. Is Someone Ready to be a Librarian?

    Just because you’ve built a website, that doesn’t automatically imply that you should build a library.

    Building and sustaining a component library takes an evangelizing advocate. That person may be you, or someone you manage or work with. Almost always, the librarian wears many hats:

    Leader: You’ll promote a new way of thinking, shepherding participants into common practice and evangelizing the techniques, benefits, and spirit of the library.

    Target: You’ll be a lightning rod for the library, and even the cause of controversy in a design organization. Others may point to you as the standards police that constrains them from being creative.

    Writer: You’ll be an author, or at least a contributor and reviewer of other’s contributions, for items like guidelines, library cheat sheets, and blog posts.

    Teacher: You’ll teach principles and basic fundamentals about what’s where and how to use it. Help requests can be disruptive, and you’ll have to be patient, determined, and flexible.



    5. Is Your Design Team Ready for a Library?

    A library can transform how a team operates. Gone are the days where every project is a blank canvas where a designer creates a creative and original work of art. Instead, designers are equipped with helpful starting points as a framework in which to operate. Those constraints can be simultaneously welcome and controversial.

    Above all, your team will have to overcome the misconception that a library is about constraining innovation. You want to – you need to – stop reinventing the wheel. Templates with grids, libraries, styles, and pre-made page chunks don’t turn designers into robotic automatons. But designers often react that way. You’ll have to convince designers that library starting points can focus creativity.

    Other team attributes that influence library readiness include:

    Size: How big is your design team? The larger the team, the more likely techniques, styles and deliverables vary. Libraries and templates can get your team synched up and communicating more consistently.

    Overlap: How much do designs contain overlapping patterns and components? If your team is designing towards a common experience, a library can be a key part of a holistic strategy.

    Distribution: Is your team spread out geographically? Standard design assets can mitigate impacts of reduced face-to-face collaboration.

    Adaptability: Will your team be able to adapt to design practices that involve a library?

    Stability: How stable is your team? Do designers come and go often? Learning library details is an investment with a return that increases the longer each designer uses it.

    Advocacy: Do you have team members that are jazzed about or knowledgeable of reuse? Are they willing to be partners or champions?



    6. Is Your Organization Ready for a Library?

    Your team will have to overcome the misconception that a library is about constraining innovation. You want to – you need to – stop reinventing the wheel.

    You’ll need to have a pitch that explains the library in simple and concrete terms. What is it? How does it work? What does it mean to me? These questions hint at the profound impacts a library can have:

    Workflow: Design libraries impact at least two critical workflows: how you produce a solution for each project and how you maintain assets, guidelines, and documentation across projects.

    Collaboration: Do key team members – such as engineers and designers – have a common foundation to communicate on?

    Documentation: You got to make it easy for people to refer to, find, learn, and integrate reusable assets into their own practices, whether via a component ID annotation on a wireframe, a PDF’s link to online documentation, or consistent HTML comments in your code.

    Timing: When change is in the air, there may be opportunity to insert a library into the discussion and approach. Can you time the expansion of your library to dovetail with when your experience are already undergoing significant change?



    7. Is Management Ready to Support a Library?

    None of your planning and efforts will matter if you lack management support. They must vocalize a public belief in your effort as well as pony up time, money, and resources. It’s your duty to communicate a plan – and the return on that investment – to sell your management on why a library matters.

    Unfortunately, even when the library is otherwise a good idea, management support sometimes wavers in instances like:

    Lack of Priority: It can happen to the best of teams. You get your top talent together, you start roughing out a framework, and then projects hit. You get distracted. It’s up to management to carve out sufficient time for you, or else the library becomes stale and ineffective.

    Insufficient Hardware and Software: It’s up to managers to ensure that designers have the right hardware and software installed so they can use the design assets. My confusion turned into empathy when I sat at a designer’s desk and watched for TEN MINUTES as the software tool launched on his out-of-date laptop. My query of “This is unacceptable. Haven’t you asked for an update?” was met with “You can only ask so many times” and a shrug.

    Leadership and Evangelism: Ensure management is on message. Prep them with simple ways to communicate library value and help them avoid undermining you with explanations like “the library is another good idea, but if it doesn’t work for you, shouldn’t disrupt your own personal approach if you feel your way is more effective.”

    Background Support: Public declarations are important, but so are the back-channel efforts. Your managers need to open doors to connect you with key players and partners. Knowing what doors to open is a two-way street, so help your managers understand the obstacles and why you need help.



    8. So, Are You Really Ready to Build a Library?

    Take a deep breath, because you’ve got a fun ride ahead.

    So, your design system is stable, you’ve got some champions backing you up, and you know just what your organization needs. You are ready to put yourself on the line. You believe.

    Then take a deep breath, because you’ve got a fun ride ahead.

    Creating a UX library diagram
    Diagram of How to Create a UX Design Library (PDF)

    Up next, you’ll want craft a plan and read all you can from all the best authors and online resources. You then discover, organize, and prioritize what goes in your library. You’ll setup a platform for managing your catalog and publishing your standards. You may even equip one or more software tools with a library of reusable assets so that your team can create better design and deliverables, faster.

    It’s time to build a library.

    Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
    Could not load more posts
    Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
    Just a second, loading more posts...
    You've reached the end.
    Get rid of the ads (sfw)

    Don't be the product, buy the product!

    Schweinderl