The Why and The How of Organizations that Deliver Great Experiences

As companies embrace the need to take user experience seriously, often their first step is to build out a “UX department.” However, the reality is that user experience is a phenomenon that emerges from an entire organization’s activities, not just the efforts of one team. There are (at least) six components that need to be aligned throughout the organization, which I’ve grouped into “The Why” and “The How”.

The Why

Values

What do you stand for?

An organization must have a clearly articulated set of values, and if you want to deliver great experiences, those values most include humanistic qualities of customer-centeredness and empathy.

Values statements from Apple, Southwest Airlines, Target.

Vision

Where are you headed? 

Everyone must have a shared sense of where the organization is going. This vision must be concrete and inspiring. Bulleted lists do not comprise a vision, because it allows team members to have very different interpretations, which will undermine their efforts to deliver a great experience. At Groupon, before we launched our redesigned website, we created an internal-only “north star” that illustrated what our experience could be in 2 years time. It helped orient everyone in the same direction. Deborah Adler’s “SafeRX” prototype embodied a vision for a new pill delivery system better than any list of requirements could.

Jared Spool has written good stuff about vision: The 3 Qs for Great Experience Design, The 3 Steps For Creating An Experience Vision.

Goals

How do we know when we’re successful?

At Adaptive Path, my favorite question to ask client stakeholders during the initial discovery phase was, “How do we know when we’re successful?” It seems so obvious and innocent, but as I worked with more companies, I grew to realize just how few organizations had a clear sense of what success meant to them. However, if you’re not clear about goals and success metrics, it’s much harder to make decisions throughout your process, and your efforts lose focus.

Christina Wodtke’s discussion of OKRs is a good place to go deeper.

How

Incentives

How do we encourage desired behavior within the team?

Incentives might seem a highly specific tactical matter compared to the others. Thing is, it warrants being called out as it’s where the best laid plans of delivering great experience get bound up in the legacy behaviors of an organization.

How is performance assessed? What criteria drive rewards (raises, bonuses, promotions)? What behaviors get lauded and evangelized? 

I’ve worked with numerous financial services organizations, where people were rewarded based on the performance within their business unit (banking, brokerage, insurance, loans) or their channel (in store, by phone, online). Such incentives are anathema to great experiences, as it discourages internal cooperation, even though customers are engaging across businesses and channels. 

I recently spoke with Irene Au about her career leading UX teams, and a challenge she had at Google is that individuals were promoted based on how much stuff they shipped, and not about the quality of what was shipped. Optimization and refinement was thus discouraged, even though such iteration is necessary for great experiences.

Processes

How do we operate?

The first thing to understand — there is no One True Way. No grand process to rule them all. Delivering great experiences requires discarding rigidly defined processes, instead embracing a toolkit, a set of techniques that can be used as needed to solve specific problems. 

However, there are characteristics of organizational operation that typically lead to the delivery of better experiences.

Work as a cross-functional team as early as possible. Waterfall approaches, where one functional group hands off to the next functional group, deliver poorer experiences. The complexity of the problems you’re trying to solve, the components that need to be marshaled and coordinated in order to succeed, requires input from the entire team from the outset. And not just at a kickoff meeting, but throughout throughout definition, design, and development.

Upfront, qualitative field research reveals opportunities, leads to insights, and sparks creativity. Engaging prospective and active users at the start of a project, understanding their current behaviors, and revealing the motivations and emotions that drive their actions, will lead to insights that in turn identify new opportunities for delivering customer value. 

Design and prototyping are activities that support the entire process, not discrete steps in the process. You can use design and prototyping techniques from the beginning of the process. (For more on this, read about The Double Diamond Model)

Bias towards building and making, not thinking and documenting (though some thinking and documentation can be quite helpful). Companies that deliver great experiences are constantly crafting those experiences, refining and refining them.

Capabilities

What skills are necessary?

This question is the hardest to answer generically, because it’s so dependent on the specifics of experience delivery. That said, there are a couple of newish roles that organizations serious about great user experiences must consider.

Strategic designer. As design gets brought into earlier parts of the process, it’s important that designers are comfortable with strategy and planning. Not all designers excel at these discussions, so it is important to have designers who can engage with and are excited by strategic concerns, and who can hold their own with business analysts,  product managers, and engineers.

Prototype engineering. Engineering is typically seen as a production exercise — creating code that is ready to be deployed. In this new era of iterative design and prototyping, a role has emerged for those who can quickly cobble together interactive prototypes with no concern as to whether the code created is reusable. 

This capability comes from one of two places — technologists who are comfortable being nimble, or designers who are comfortable prototyping their designs. Either way, it’s important that your team can quickly prototype new solutions in such a way that users can experience them and provide meaningful feedback, which will then inform subsequent iterations of the solution. 

I’m Sure There’s More

While I think this is pretty complete, it’s doubtless not exhaustive. I’d love feedback on improvements, be they amendments, refinements, or removals.

 

A key challenge in delivering great user experiences

In my last post, I suggested that ,ost of us work in markets where products and services have matured out of “technology” and “features” and into “experience”, and so design should be driving the conversation, because delivering on experience is what design does best. Instead, we find design hamstrung into organization models that are still “features”-driven.

The more I’ve thought about it, the more I’ve realized that there is a potentially intractable issue “experience design” faces. When you study how people behave, and propose design interventions to support better experiences, you’re engaging in a holistic and continuous activity. Human experience is continuous. It flows seamlessly.

However, in order to deliver products and services to people, we must break up this continuous experience into discrete pieces that are achievable by teams. So, to use the example from the last post, the Shopping Experience becomes a series of features (Search, Browse, Product Page, Checkout, Gifting, etc.) Working in producible chunks inevitably means losing the holism that defines human experience, and the thing I struggle with is figuring out how to manage this liminal shift so that what we deliver doesn’t become defined by the features (and the teams dedicated to the features), and it maintains its more subtle, nuanced, integrated qualities.

How could we/should we reorganize development teams and processes to achieve this experiential holism?

Design should drive product and engineering, not vice versa

[Note: I’m actually wary of “should”s, and what follows is more of a provocation than a call to arms. But I think it needs to be seriously considered.]

In 2007, Jared Spool wrote about the market maturity framework, and how technical product categories evolve from “technology” (where it’s compelling that a product simply does a thing at all) to “features” (where there’s competition that stakes claims based on the number of capabilities) to “experience” (which delivers a gestalt greater than the sum of the parts, and often involves removing features).

Most technical product organizations are still driven by engineering (“technology”) or product management (“features”). “Experience” is where design comes to the fore, but because of its nascency, design is typically subsumed into an existing engineering- or PM-driven org.

This means that many organizations place design within existing product/feature teams, looking something like this (for an imagined e-commerce service):

typicalprod

The vertical orientation is primary. On the left, there’s a leadership team with a Director of Design, Director of Product, and Director of Engineering who coordinate and plan across the teams. Then you have distinct “feature” teams that own different parts of the product, comprised of a product manager, a designer, and 4 (or so) engineers.

At Groupon, and in some other orgs I know, you see an organization more like this:
centralizedpartnership

The design team is distinct and works together. The Director of Design still coordinates with Director of Product and Director of Engineering, and now also with a Product Manager on a key feature team. We’ve introduced Senior Designers who own relationships with two Product Managers each. When a PM needs to know what’s going on with design, the PM talks to that senior designer. And then we have 2-3 additional designers who collaborate with the Senior Designers or Director of Design as needed.

I call this a “Centralized Partnership” model, where design is centralized, but, through the senior designers, there is a real commitment and partnership with product areas. The benefit of this model is that designers can work across multiple features, ensuring coherence of the experience.

However, this is still ruled by “features”. So, maybe we need to fundamentally rethink it?

If companies are serious about focusing on experience, than design teams should be free to work on that holistic experience, which means that they can actually address a whole lot more. At Adaptive Path, I lead a project team on an e-commerce site. We were able to deliver across many more features, because we weren’t constrained by product teams.

designteam_experience

The open question is to figure out how product management and engineering should be structured to support this crafting of experience. But it doesn’t make sense to let legacy organization structures constrict our ability to deliver the greatest possible experience for our users.

Teams are the key to ongoing design success

When presenting my philosophy of design organizations, I show this slide: voltron_teams.051   On the left, comprised of 5 robot lions (stay with me…), you have super robot Voltron, Defender of the Universe.  On the right, 5 unicorns. The unicorns refer to the “design unicorn” a designer skilled at interaction design, visual design, and front-end development. They’re “unicorns” because some believe they don’t exist, though others are betting that they are very much real. For the sake of argument, let’s say that design unicorns are real.

My concern is that all this talk about unicorns, on thus on design at the level of the individual, is misguided, and potentially even harmful to design as a field.

Companies want a unicorn because she can be the lone designer on a product team, working with product managers and engineers to deliver features. On the face of it, this seems great – you get a lot of bang for your buck.

However, in my experience, design is best considered at the level of a design team, and the point of the slide above is that a coordinated team of 5 designers (of varying skill sets) can out perform 5 identically-skilled unicorns working in isolation.

When I joined Groupon, product designers primarily acted on their own in product teams. And what I saw is that the scope of their efforts was quite constricted. When you’re asking one person to deliver interaction design, visual design, and front-end code (or at least something prototyped), it leads to designers focusing on narrowly defined features — a single web page, or augmenting an existing flow.

Among the first things I did as VP of Design was relax our requirements for product designers. They no longer needed to be technically savvy, and, they could have an emphasis in interaction design and IA or in visual design.

And much of my own initial effort was on hiring strong design leads — directors and senior managers. This turned out to be key. About 9 months into my tenure, I organized the 40-plus person Design Union (what we called the whole design team) into a series of teams, each with a lead. This proved transformative not just for design, but the for the company. With these teams in place we could deliver on larger scale efforts like Groupon’s first-ever website redesign (a prior effort, before I had joined, had failed), or DealBuilder, a self-service tool for merchants to launch a deal.

Another short-coming of focusing on design unicorns is that it reduces design to an execution function (I’ve written about definition and execution in my post and presentation on The Double Diamond.) Approaching design from the orientation of teams, with strong team leadership, not only allows designers to tackle broader problems, it also enables them to move “upstream” into the decision-making behind product definition.

Team Structure

Through experience, I’ve arrived at a sense of what seems to work for the structure of design teams (again, these are teams within a larger design organization, not the whole organization itself!).

Teams should have 4-7 members. Any larger than that, and team coordination gets unwieldy.

Teams require strong singular leadership. This Team Lead role is perhaps the most challenging in the whole design organization (even moreso than a VP of Design). The Lead must:

  • Manage down – getting the most and best out of their team
  • Manage across – collaborate with cross-functional partners
  • Manage up – presents to executives and other stakeholders

Pivoting between detailed delivery within your team, coordination with peers in product, engineering, and marketing, and communication to executives can induce a kind of whiplash that not everyone can handle (in fact, I would say it’s rarer than the ‘design unicorn’). But if you find folks who can handle this successfully, your design organization can be surprisingly effective.

These teams should be organized around business problems (supporting a line of business) or aspects of the customer experience, not by function (interaction design team, visual design team, etc.)

And within these teams should be located a spread of skills — user research, strategy, planning, interaction design, information architecture, visual design, and prototyping. And this suggests another reason to Think Beyond Unicorns, as no one could be expected to excel in all of these areas. Instead, hire folks who excel at a couple of these but can productively collaborate across all of them. (I’m not in anyway advocating the hiring of single-minded specialists.)

There’s an alchemy that happens with great design teams, where the whole is greater than the sum of the parts. My understaffed teams were able to deliver far more than could have been reasonably expected because they could leverage their team-ness for greater effectiveness.

When I next write about teams…

Something that I’ve realized is that the ideal level of scope for a design team is different than that of a product and engineering team, and designers are currently constrained by working within an organization optimized for the latter. When I have time (and after I do some doodling), I want to talk about bridging that gap.

STEM into STEAM into STREAM

STEM is the acronym for Science, Technology, Engineering, and Mathematics, and is used when talking about what we need Our Young People to study in order for the United States to Stay Competitive in the world.

John Maeda, formerly president of RISD and now a design partner at KPCB, popularized the idea of turning STEM into STEAM — adding Arts (and design), because it’s clear that inventions that turn into innovations are often not just driven by the hard sciences.

However, this strikes me as insufficient. Because in my experience, the greatest source of insights for inspiring meaningful product and service creation comes not from the hard sciences, but from the social sciences. To turn STEM into STEAM into STREAM, where R stands for Research on people, their behaviors and contexts.

Software, hardware, purpose, and agency–first thoughts from Solid

Rodney Brooks gave the first presentation at Solid Conference, talking about the integration of software and hardware in robotics. For decades, industrial robots were programmatically simple, performing the same action over and over again–not all that distinct from the machines that preceded them.

Brooks, though, is interested in how software allows hardware to change it’s behavior, to become more effective, and, in a way, smarter. He showed the robot Baxter, demonstrating how it picks up items to pack them. On Baxter’s second pass, Brooks takes the object from Baxter midway in his movement. An older robot would continue to go through the packing motion. Baxter, however, realizes that the object is missing, and halts it’s motion to instead go get the next object.

Brooks commented how many of his customers find this disturbing–they expect the machine to behave like a machine. However, Baxter is now exerting something like agency.

This is challenging for people because we assume that anything reacting with agency is alive. Machines are things we use for a purpose, typically a singular purpose. However, if software allows that machine to appear smart, to behave in unpredictable but savvy ways, people no longer perceive it as just a machine. Even if it doesn’t look like a person or animal, we still treat them as alive (think about how people typically name their Roombas.)

The challenge for design is to appropriately set expectations. I wrote an earlier post about the role of purpose in product design–people use an app to fulfill a purpose, and if that app changes (usually to add purposes) people often reject that change. As we start designing for wearables (smart watches, glasses, clothes, etc) and robots, we have to recognize that people bring a preconception of purpose stability–I use a watch to track time; I wear glasses to improve eyesight. Making these things smart crosses a cognitive chasm, where the person no longer perceives it as an object, but now a living thing.

The key, overarching insight from CREATIVITY, INC.

Creativity, Inc

Creativity, Inc., by Ed Catmull and Amy Wallace, is an important work, not just as a business book, but as a piece of non-fiction. In it, Catmull shares his hard-won lessons on management from 40 years of work, the last 30 as President at Pixar.

Just given Pixar’s unparalleled success, Catmull would be worth listening to. However, he goes beyond expectations and shares his story with remarkable candor, humanity, wisdom, and humility.

In a book riddled with insights, the single most important is the overarching realization that any creative organization is a constantly evolving complex dynamic system. The book’s subtitle could have been Corralling Dynamism To Deliver Greatness.

This insight has a number of implications:

  • practices that aim for certainty will curb creativity, and are fruitless anyway, because dynamism
  • instead, embrace that dynamism, as it leads to unexpected awesomeness that couldn’t be predicted
  • as dynamism is messy, develop practices that encourage discovery and recovery
  • create feedback loops throughout the organization, so that this dynamism is continually tacking towards positive outcomes
  • these feedback loops require candid communication throughout the entire organization, which means everyone needs to be comfortable sharing their thoughts and concerns, without fear of retribution
  • like tending a productive garden, management and leadership’s work is never done, and just because something worked in the past doesn’t mean it will continue to do so

These implications scare the crap out of most senior leadership, who are under the notion of “you can’t manage what you can’t measure,” and who require certainty in the desire to be predictable. Catmull addresses this in one of my favorite passages:

“You can’t manage what you can’t measure” is a maxim that is taught and believed by many in both the business and education sectors. But in fact, the phrase is ridiculous—something said by people who are unaware of how much is hidden.

This is but a sliver of what the book offers. To do it justice, I’d pretty much have to rewrite the whole damn thing, so just go read it already.

There is one thing that the book punts on that I find crucial in any creative enterprise, and I’d love to ask Catmull why he didn’t address it directly. And that’s the matter of taste, of judgment, of knowing when something is great. Catmull takes it as a given that all ideas start crappy, but through iteration, interrogation, research, and refinement, they become great. But he doesn’t share when his team (particularly the Braintrust) knows when to be satisfied that something is great enough and requires no further improvement.

Why I’m Grateful to Massimo Vignelli

News spread over the past day that legendary graphic designer Massimo Vignelli is terminally ill at his home in New York City. There will be a lot said about his contributions to design, notably the New York City Subway Graphic Language, American Airlines’ long standing logo, even stackable dinnerware.

I first came to appreciate Vignelli through my own little discovery. Roadtripping with my wife (then girlfriend) across the American Southwest, we visited many National Parks. And for every park, we got a beautiful brochure. And I was struck these thoughtfully designed objects, as we don’t tend to think of the Feds and good design. So much so that I blogged about it and through my research found out that Vignelli developed the “Unigrid” system that kept all these different brochures feeling like they’re part of the same family, though with enough flexibility so that each was quite distinct.

We should cherish good design when we find it, and laud those who help bring it into being. So, thank you, Signor Vignelli.

 

The Seduction of the Superficial in Digital Product Design

Digital product design discourse over the last few years has become literally superficial. Much (most?) of the attention has been on issues like ‘flat’ vs ‘skeuomorphic,’ the color scheme of iOS7, parallax scrolling, or underlining links. And not that these things aren’t important or worth discussing, but as someone who came up in design by way of usability and information architecture, I’ve been disappointed how the community has willfully neglected the deeper concerns of systems and structure in favor of the surface. I mean, how many pixels need to be spilled on iOS 7.1’s redesigned shift key?

I was talking with Jesse about this over lunch a bit back, specifically how his 5 planes are more important now than ever.

simpleplanes

 

There was a golden moment, in late 90s and early 2000s, where the deeper matters of strategy, scope, and structure seemed to get more play, with multiple books on information architecture, and online journals like Boxes and Arrows leading the design discussion.

Jesse, ever the wiser one, coached me to watch for my “Get off my lawn!” mindset, and through our discussion I realized something.

When digital design discourse emerged in the late 90s, our ability to interestingly design for “surface” was heavily compromised. We designed for 640 x 480 displays. Maybe 800 x 600. We worried about the Netscape Color Cube. We had laughable control over typography and layout.

Graphic designers often got frustrated with the Web, and did what they could to control the presentation, overly relying on images, and exploiting hacks with tables and invisible .GIFs. And schmucks like me, who had no real graphic design skill, would smugly tell them to “embrace the medium” and focus on the interesting hard problems of information architecture and interaction design.

We now live in a world where I have an 1136×640 display with 16 million colors in my pocket. And processor speeds that allow for startlingly smooth animations. The Surface now warrants critical examination and exploration. But the Surface isn’t merely superficial. The decades of insightful dialogue on matters of graphic and motion design can now be applied to digital products. The increased sophistication of the digital canvas has lead to limitless possibilities on the Surface, and a capable digital interface designer must understand not only color, composition, typography, and layout, but now must also be facile with motion and animation. That’s enough to keep anyone busy for their career.

It’s understandable that non-designers talking about design (as increasingly happens) focus on the superficial–it’s the easiest to discuss. However, we in the digital design community must not get so caught up in the seductive Surface that we neglect those lower layers. There are a number of reasons:

  • It is a disservice to younger designers, particularly the self-taught, as it encourages emphasis on style over substance
  • It plays into the still-prevailing attitude among business and technical types that designers don’t grok the deeper concerns in these complicated systems, and are best to bring in when it’s time to make something look good
  • As the services we design cross more devices and have more online and offline touch points, managing those deeper layers is increasingly important for success

I’ve realized I’m grateful for the passionate conversation around Surface–it means that people care and are engaged. Still, we must be vigilant in maintaining similar attention to those deeper layers, precisely because their abstraction makes them more challenging to discuss.

On the shortcomings of “Minimum Viable Product”

Christina Wodtke recently wrote “Getting the V Right”, addressing a common failing of Lean Startup practice — successfully establishing viability in your Minimum Viable Product (MVP). I commented there, but felt it worth expanding here.

The MVP Incantation

My frustration with MVP comes from its reckless use in product management. When launching a feature, I’d hear about “We just need to get our MVP out.” But never was there any attempt at determining viability. What product managers actually meant was, “next release,” but used “MVP” to suggest savvy and greater likelhood to succeed. Christina attempts to address this by coaching people on how to appropriately articulate viability, even resorting to the grade-school-essay canard of the dictionary definition. The problem is, most folks who are misusing MVP are already a lost cause – they’re cargo cultists hoping an incantation gets results, and no amount of guidance will change that core behavior.

Viability is unpredictable

MVP rests on an assumption that you can pre-assess something’s viability with reasonable confidence. However, viability can only be understood in retrospect — you can try to predict it, but really you won’t know until it’s out there. I suspect this is why so many people punt on defining it, in favor of “just get something out and see how people react.” But then this just turns into a resource-wasting exercise in throwing spaghetti, hoping that something sticks.

“MVP” doesn’t galvanize and inspire

However, even if we believe that MVP is an appropriate tool, the confusion in its use suggests a different issue — that while it’s proven catchy enough to spread, it’s nebulousness and abstractness limit its utility. Nebulousness leads to too much variance in how it can be interpreted, and abstractness means it doesn’t galvanize a product team. No one gets excited about launching an MVP. It lacks punch. I much prefer models such as Brandon Schauer’s Cake Model of Product Strategy or Spotify’s vehicular one:

These models communicate what’s most important — that at every stage, even the very first, you must deliver something that feels complete, and delivers useful functionality and/or delight. I’ve personally seen teams shift from MVP to “cupcake,” and, in doing so, shift focus on delivering some bare minimum to something that they can get enthused about.

Maybe we’ve been using the wrong kind of viable?

I teased about the dictionary definition, but there’s actually something in there that’s valuable that I’ve never heard discussed in the context of MVP:

(of a seed or spore) Able to germinate.

We’ve been so focused on economic viability, that we overlooked the origin of the word “viable”, rooted in the word “life.” The common thinking for MVP is “what is the least I can do to deliver a product that doesn’t fail”, but wouldn’t it be more interesting, and inspirational, if we thought, “what can I deliver that could take on a life of its own?”