For example, if you wake a lead designer up before 8am for a Design Review, our expectation is that we’ll be leading a call where the work to date is packaged up and presented to directors, VPs, or even a sponsoring executive. We’re probably up and caffeinating 90min beforehand. It isn’t a phrase that you should use lightly when summoning a creative.

But what should you call a meeting about the design if it isn’t a design review?

Product Owners, Product Managers, Scrum Masters, and others of the ilk: this handy list should help you decide what type of meeting you need to request in order to get the best communication out of a creative team.

Intake
Introduce the new project, requirements, and expected delivery window to team leads.

Unpack
After the design lead(s) process the intake it is unpacked to the creative team in an actionable way, typically using a creative brief. This will include a summary of the intake alongside research findings and a design challenge articulation.

Alignment
An expanded version of the processed intake will be placed into a project brief. The goal is for the lead designer to restate and reframe the intake in an actionable way that everyone can agree on while setting expectations for what will be delivered. Once the agreement is made any shifts in the strategy will affect the delivery timeline.

Ideation
This is a creative call where we brainstorm potential solutions to a design challenge.

Checkpoint
A meeting to inform team members and stakeholders regarding the status of the design project.

Review
This word triggers alarm bells for any designer. It is a critically important meeting where we present our work, defend our decisions, then agree to additional research spikes or change orders. A review call can include core stakeholders, or a full stakeholder review. This is a sign-off meeting if no changes are requested. Changes beyond this point may have a significant impact on the delivery timeline.

Developer Checkpoint
A specific version of the regular checkpoint where we meet with the lead developer(s) to ensure the solutions we are pursuing are feasible under our current technology stack and timeline.

Developer Handoff
We hand the design off to the dev team for production. After this point any changes unrelated to content or graphical assets may impact the delivery timeline.

Fidelity Checkpoint
A follow-up version of the developer checkpoint meetings where the lead designer(s) and developer(s) ensure the product being delivered matches the one that was designed. Gaps are addressed. Compromise is a common outcome.

Stakeholder Presentation
The completed work is formally presented to the entire stakeholder group.

Pre-Flight Check
A final look at the complete product ahead of launch.

Retrospective
An internal meeting to review the design process and establish next steps, if they exist.

Congratulations! You’ve been empowered with a knowledge of what certain words and phrases mean to designers. Use that power well and stop calling 7am “design review” meetings when Asia Pacific isn’t on the line and you actually meant “pre-flight check.”

We still love you, ops team!

—

At the time of this publication, I am the Lead Designer for Dell Technologies Digital Events team. I learned HTML in 1997 and built my first commercial web experience in 1999. Professional designers and entrepreneurs can connect with me on LinkedIn or Twitter.

Unless you are a designer, executive, writer, or founder; please leave a note when connecting on LinkedIn or I may not add you.

The Types of Design Meetings was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

I do a lot of thinking and writing on the field of user experience design and, for some reason, a bunch of you have decided you like to spend your precious spare minutes reading it. That discovery has been one of the most gratifying and humbling experiences of my career.

Most of what I write down never leaves my drafts folder. As it turns out, some of you have noticed this in the year since my last article.

Right, my bad. Sorry about that.

Can you keep a secret? Logging into over 1000 notifications every time I opened Medium was pretty intimidating. I had to go through my own Campbellian Hero’s Journey of refusing the call before deciding to accept that such an overwhelming number of people care what I have to say on the subject. 3000 reads is an ego boost. 100,000 reads is an awakening.

As I dust off my drafts and optimize a few of them for publication, I’m also thinking a lot about how I present myself as a designer. Various incarnations of my website have been woefully at odds with my writing. If I’m going to have the temerity to write a 100,000+ view article (this is still a trip) on the evolution of UX process I should aim to at least be consistent in my professional and thought leadership presentation.

Also, I should probably share my thoughts since y’all are crazy enough to want to hear them. So here it goes:

As we progress in our careers, we all develop a creative philosophy. Some of us are better at articulating it than others, though all of us should strive for clarity. We talk about our creative philosophy when we evangelize UX to stakeholders, when we interview for jobs, when mentor less advanced designers, and when we present or defend our work. We revel in it when things go well and we agonize over it when they don’t. As we mature, so does our position on what makes design meaningful, and why we should be well paid for it.

What follows is a bit of recent work I’ve done on crafting my own UX philosophy, and it echoes a lot of what my readers have become familiar with in a concise format.

May it help speed you on your own path to greater eloquence.

—

“UX is Process” — Ian Armstrong

“Learn the rules like a pro, so you can break them like an artist.” — Pablo Picasso (attribution)

“Everyone is kind of an idiot.” — Adam J. Kurtz

With that in mind, let’s talk about my UX process.

I am Agile

That’s inherently tricky because the entire field of UX relies on a deeply waterfall premise: learn everything you can possibly know about the user before executing a design because you only get one chance at a first impression. The whole idea of Lean UX, at first blush, is a masterclass in cognitive dissonance.

An agile process relies on two important things: a sense of direction and a compelling hypothesis. Without either one, it flounders. The goal of research is to improve the quality of the average hypothesis but all the research under the stars can’t tell a team what they’re supposed to build. That’s the creative leap that makes design work, which leads me to the next thing…

I Practice Dual-Track Design

Dual track design is a phrase that I coined to represent the heartbeat of a design sprint (ideative) and Lean UX (iterative). Through the design sprint, we align on an opportunity, reframe it as a challenge, then draft a blue sky target. Once the target has been validated, Lean UX fleshes out the details over time. The idea behind this concept is something I go into during the back half of my article on The Evolution of UX Process. If you’ve ever heard a designer say to their product owner “if I could write that story I would already have done the design” then you’ve seen the moment when I like to switch tracks.

I Am a Proponent of Pair Design

A traditional UX designer’s job is to tirelessly challenge and reframe assumptions, lending perspective to a team of detail-oriented doers. A classic visual designer’s job is to achieve what managers often call “pixel perfection”. It is all but impossible to hold perspective and perfection in the same mind; the dominant aspiration will always assimilate its reflection. For this reason, I prefer to pair a researcher/wireframer (IxD) with a digital artist (VizD). Fresh creative takes fewer cycles to reach peak effectiveness, negating any perceived loss of efficiency when the two designers are no longer working on two mission critical tasks in their own swim lanes. A/B test this for six months before you argue with me.

I Believe in a Ruthless Pursuit of Value

There are five things I need to know in order to start a design project: the market opportunity, the business goals that work in pursuit of that opportunity, the user behaviors that will quantify our success, the nature of that user, and the value they seek. Value is what connects the user to the opportunity in the form of a choice. “This is a solution, there are many like it but this one is mine.” The pursuit and delivery of value is at the core of what drives a successful business outcome.

Alignment is Our Launchpad

Without alignment, critique and optimization are impossible. In order to drive the creation of breakthrough products we need to be aligned on the five core ideas in the previous section: opportunity, goals, behaviors, personas, and desired value. Without that alignment, every single product decision will devolve into conflict and ineffective compromise.

Process is the Vehicle

A consistent process allows us to understand what has been accomplished, what our next steps are, where we expect to be in the future, and how our work will be measured. Creativity is inherently chaotic and artists are prone to crippling self doubt in a negative workspace. A team’s creative process should be flexible enough to allow for chaos but also firm enough to prevent a team from getting stuck in a rut or lost in the woods.

Insight is the Fuel

Creativity abhors a vacuum. While it is true that design is often a benevolent dictatorship (and not a democracy), every single person from the product owner to the engineers should feel welcome to present design hypotheses. There are no wrong ideas, just differently informed points of view. A designer needs to be emotionally bulletproof when a team member’s ideas contradict their own because a design-lead organization needs to foster a culture of creativity. In that culture the best feedback is often inquisitive, not prescriptive: as in “yes, and how about this?” Anxiety, fear, and self-consciousness are the enemies of insight. Surprise is the engine of innovation. As a consequence, I aim to find something surprising in every day.

—

At the time of this publication, I am a Principal UX Designer at Dell Technologies Digital Marketing Studio in San Francisco. I learned HTML in 1997 and built my first commercial web experience in 1999. Professional designers and entrepreneurs can connect with me on LinkedIn or Twitter.

Leave a note when connecting on LinkedIn, especially if you have a weird title.

Crafting a UX Philosophy was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

Version 2.1 re-publication: October 8, 2020

In the beginning there was Donald A. Norman, and he created the idea of user experience design.

I invented the term because I thought human interface and usability were too narrow. I wanted to cover all aspects of the person’s experience with the system including industrial design graphics, the interface, the physical interaction and the manual. Since then the term has spread widely, so much so that it is starting to lose its meaning.

— Donald Norman

By 2016, Don Norman was pretty vocal about how badly misunderstood the term had become. He talks about it in this short YouTube video. These days he says he’s a people designer (apologies, I’ve misplaced the interview link), sort of, but he’s non-committal about the title.

I can’t think of a better place to start unraveling the weird and confusing world of modern UX Design than this: Not even the originator of our field knows what to call himself anymore.

De-obfuscating modern UX requires understanding the history of both design and development since the 1990s. They’re intrinsically linked, so it helps to start just a few years after it all began.

Classic User Experience Design

In its purest form, UX Design is waterfall based.

A product team working through the waterfall methodology sets out to learn everything they possibly can before building even the simplest prototype. Research can take months, or even years to complete; and the results dictate a design team’s execution. The requirements lock before design kicks off, and design locks before development kicks off. There’s no going back, not until version 2.0. That’s just how waterfall operates.

A classic UX process is usually taught to college students. It goes like this:

1. Do research to discover what the problem is
2. Categorize the problems you uncover
3. Create personas and journey maps
4. Run ideation exercises to generate ideas
5. Build and test a prototype
6. Send the final prototype out the door to development
7. Launch the product
8. Return to step 1 based on user feedback

That’s basically a waterfall. The classic elements of UX (Jesse James Garrett) also follow a waterfall schema, building an execution from the bottom up based on well articulated requirements.

The problem is that classic UX is fundamentally incompatible with agile.

Along Came Agile

For a long time innovation in the Silicon Valley was driven by Moore’s Law, which states that the number of transistors in a dense integrated circuit doubles approximately every two years. Superimpose a waterfall process and you’ll notice that it fits nicely into a 24 month cadence. Business, design, and development cycles worked like a Swiss timepiece; perfectly attuned to the release of a new Intel chipset.

Then one day Sony, Toshiba, and IBM (The STI Alliance) decided that Moore’s Law was too slow.

STI created the first cell chip, which stacked 8 microprocessor cores on a single wafer, and the damn thing actually worked (it powered the Playstation 2). Multi-core architecture changed everything.

Moore’s law didn’t break, it got life-hacked. What did break was waterfall.

Almost overnight speed and flexibility replaced precision and predictability as competitive advantages. Companies turned en masse to another well established but underutilized development methodology: Agile.

Agile focuses on rapid iteration. It releases a new set of shippable increments (features) every 2-4 weeks, evolving a product over time instead of all at once. It’s based on hypothesis, experimentation, rapid release, and real-time measurement. In Agile there is no editing stage, there is no perfection. As Bre Pettis put it in 2009… done is the engine of more.

Waterfall’s painstaking “measure twice, cut once” approach went out of style faster than a StarTAC in a room full of iPhones.

There Was Just This One Small Problem Though

Classic UX operated on a waterfall cadence.

With feature releases happening once or twice a month there wasn’t time to wait for UX Designers to execute their process. In Agile nomenclature UX became a blocker and it was a bad one.

Faced with an immovable block most teams simply abandoned UX. In its place they hired young graphic designers who were capable of turning out assets on a two-week cadence. Those designers weren’t real UXers, not in the classic sense, but they knew just enough about user centered design to avoid making the worst types of mistakes.

That was okay with product development teams. The details, they figured, would work themselves out through iteration.

Care to take a guess at what the Agile title for that type of designer was?

If you answered “UI/UX Designer” give yourself a cookie.

UI/UX Designers were at the heart of the storm when Apple proved that a design-led business could become the most valuable brand in the world. They carried the torch of UX when UX itself couldn’t sharpen a pencil inside of a two-week sprint, let alone design a feature. They made UX a household name.

It came at a cost though.

The UI/UX bias towards digital and graphic design badly skewed the business world’s perception what an experience designer does. To this day far too many businesses still think of UX as a visual discipline. As Don Norman has been trying to explain, that’s incorrect.

Things didn’t start to get better until 2013.

Lean UX

Lean UX was Jeff Gothelf’s game changing answer to the problem of practicing UX in an agile environment. In his seminal masterwork, Jeff turned the entire field of UX on its head. The book introduces a series of strategy and alignment activities, which allow UX to operate inside of agile’s cone of uncertainty and rapidly update designs based on user feedback.

Whereas classic UX is requirements based, Lean UX is outcome based. If you need a quick primer on how that works, O’Reilly has a free chapter available online that breaks things down in no-nonsense terms.

Lean UX wasn’t perfect though. While UX was now able to harmonize with an agile cadence, the lean model broke down if a product was vaguely defined –basically anything un-launched – and quickly devolved back into engineers doing design and designers fixing it.

Under agile designers also found themselves under immense pressure to fill a sprint backlog before they really understood what they were building. As a result a lot of development cycles got burned on features that never made it into the final product. In project management circles, the Lean UX / Agile pairing was known for a high volume of waste and rework when attempted under less than ideal conditions.

In a mature product there is lots of user feedback coming in, which does wonderful job of driving the iterative cycle that powers Lean UX. That’s why Lean UX is the industry standard on almost any established product team. Nobody in their right mind would change a thing.

On establishing teams, however, the user feedback cycle has yet to ignite itself. The waste and rework problem in those circumstances was serious enough that it often crippled the adoption of Lean UX. This presented a real conundrum for startups and skunkworks units that wanted to ensure a strong UX component without reverting back to a waterfall cadence.

And then it happened. The thing that would make UX work for the fast generation came out of the sky like a bolt of lightning and solved the agile process problem with the design sprint. Despite having roots in the work of Stanford, the d.school, and McKinsey nobody saw it coming until Jake Knapp and Google Ventures named it and put it to work at scale.

Just like that the long dark night of UX was finally over.

The Google Ventures Design Sprint

If you were to look at a design sprint and say “wait, that’s just really fast classic UX” you wouldn’t be far off the mark. The difference (and genius) is that it’s classic UX at an incredibly low fidelity. It’s the difference between an artistic masterpiece and a napkin sketch — but it works.

The goal of a design sprint is to take all of the existing research about a problem, unpack its essence to a diverse group, then ideate like crazy. The ideations are then funneled through the lenses of human centered design and those that survive are voted on by the team. Designers then build a low-fidelity prototype (often in just one day) that is just barely good enough to test on potential users. The results of the test, if positive, create a target for designers to hit in high-fidelity; thus fueling the Lean UX/Agile cycle.

Magic.

Dual Track Design

So now we come to the point of modern day UX methodology.

As you might expect, dual track design has two tracks (a Sherlock Holmes level deduction, I know, don’t everybody gasp at once):

1. The design thinking/research track powers a design sprint
2. The Lean UX/Agile track powers iterative experimentation

A product team is typically running on track two unless the backlog becomes poorly defined. If that happens, the problem is assessed and the team runs a design sprint. Problem solved.

But where does that assessment come from if the production team is busy practicing Lean UX?

The most obvious answer is that a proper iterative feedback cycle, which includes strong analytics, tells a team what to tune. That works well for sprint-to-sprint planning but it doesn’t always see the big picture of what could be. It doesn’t power what was popularly called disruption for the better part of a generation.

Where does the breakthrough thinking come from?

The most effective answer is to put a dedicated team on it. While design & development pumps out iterations, a research team investigates the results much more comprehensively in the background. Because that research team isn’t bound to an Agile sprint cadence they still have the luxury of taking 3 months to reach a conclusion.

Every few months a fresh infusion of new insight will hit the production teams, filling their backlog with new ideas for experimentation. Most enterprises now have a data science team and a qualitative research team (affectionately known as test & learn) feeding knowledge to multiple creative units. The insight is infrequent, as researchers have much longer delivery cycles, but when it comes down the line it’s eye opening.

Sometimes the insight is big enough to be evolutionary, at which point it triggers a major design sprint. Most of the time, however, it just adds additional kindling to the fire of Lean UX experimentation.

So yes, dual track works best when a dedicated research team is working outside the scope of the active product group. You’ve probably surmised that it’s an expensive undertaking. You’re not wrong.

What I can tell you is that it’s less expensive than the alternatives: operating without UX or dealing with the waste and rework problem of pure lean.

Fund it out of your savings.

Wrapping Up

1. In the beginning there was Don Norman, and Don invented UX.
2. Other innovators like Jesse James Garrett fleshed out Don Norman’s ideas and the classic UX process was born.
3. Classic UX worked well with the standard waterfall development cadence and everybody was happy. UX was still a niche practice though.
4. Moore’s Law was bypassed by innovation and Waterfall no longer worked.
5. Classic UX was therefore incompatible with modern (Agile) development.
6. UI/UX Designers took up the mantle of user-centered design. They were crucial to the growth of UX in the design field but limited in scope. Their bias towards digital and graphic design badly skewed the business world’s perception as to the role of UX. That remains a problem today.
7. Lean UX was conceived by Jeff Gothelf in 2013 and brought true user experience design back into harmony with product development. Suddenly researchers, interaction designers, information designers, and all manner of specialized UX professionals were in demand.
8. Unfortunately Lean UX was inefficient when a product plan wasn’t well defined, resulting in significant waste and rework.
9. Google Ventures conceived the design sprint, which allowed teams to rapidly define and test a low-fidelity prototypes. This jump-started the Lean UX cycle on emerging product teams and effectively eliminated the waste and rework problem.
10. Dual Track Design fused the Google Ventures design sprint model with Jeff Gothelf’s Lean UX methodology.

So what is a UX Designer in a dual-track world?

A UX Designer is a leader, a process evangelist, a generator of insight, a purveyor of context, and a creative ideation machine. UX Design, as I’ve said elsewhere, doesn’t really have any deliverables other than value. It has come to encompass dozens of job titles that have hundreds of their own deliverables though.

Most of us aren’t actually UX Designers unless we lead a team, rather, we work in the field of UX Design.

It’s enough to confuse anyone.

It’s enough to exasperate even Donald A. Norman.

2020 Addendum

Since 2018 the design sprint model has matured to a point where they’re ubiquitous with UX Design. There are models that pack everything into a single day, though the three day model is most common. I’ve seen them used to refine features and I’ve seen them used to restructure marketing departments. They’re a remarkable tool and every one of you reading this article knows that now. This is no longer news.

But there has been another innovation, which existed at the time of writing but hadn’t yet had its full impact. Designers, educators, marketers; all of you reading this article–The Design System changed everything.

Again.

Design systems like Material Design (and its web equivalent), Apple’s Human Interface Guidelines, Salesforce Lightning, and VMWare Clarity have been adopted by nearly every company in the world. Most major companies roll their own system, and most of those companies are basing their work on Material Design then using Zurb Foundation or Bootstrap as a starting point.

This means the design generalist, like the UI/UX designer before them, has risen to prominence.

The latest evolution of UX process hasn’t destroyed dual track design but it has made relationship the purview of senior/lead level roles in a design group. Everyone else needs to have a foundation in UX theory, training in visuals and layout, and the ability to follow a design system / styleguide with a high degree of fidelity. You’re not exactly a unicorn because the design system carries you. You are, however, sort of a jack-of-all-trades.

Rule of thumb: For every dual track design pair (Lead UX +Principal Graphic Design) at a large company there will be five generalists and maybe a single dedicated researcher. If you have less than 5–7 years of experience, you’re going to be one of the generalists.

The UI/UX designer is dead, long live the UI/UX designer

My advice under this system is exactly what it was when the UI/UX Designer ruled the craft, because the generalist is just a more UX-oriented version.

Know your neighbors. The circle of work is as follows:

(loop) ← Research ↔ Ideation & Wireframing ↔ Visual Design ↔ Interaction Design ↔ Prototype Coding ↔ Analytics → (loop)

Are you a UX Designer who has a love of classic UX? Look at your neighbors. You should be professionally competent in both research and visual design.

Are you a UX Designer who has specialized in interaction design? That’s really closely related to the actual code, so you should study it even if you aren’t the UX Engineer. It’s also going to require a lot of tweaks to finished visual designs so even if it’s not your favorite part of UX, you should be trained in graphic design.

These are the rules in 2020. I’ll update them again when things change.

Because they always do.

—

At the time of this (re)publication, I am the Lead Designer for Dell Technologies Digital Events team. I learned HTML in 1997 and built my first commercial web experience in 1999. Professional designers and entrepreneurs can connect with me on LinkedIn or Twitter.

Unless you are a designer, executive, writer, or founder; please leave a note when connecting on LinkedIn or I may not add you.

The Evolution of UX Process Methodology was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

There’s an idea that floats incessantly around the Internet, which is best summed up as “design doesn’t scale”, and it’s been mostly debunked over the last few years. I say mostly because no system is perfect and some yahoo will always use that to devalue design. It’s our cross to bear.

When it comes to scaling design though, the process of alignment can be dauntingly complex for someone who isn’t a veteran of the game. What follows is a quick non-exhaustive reference to the moving parts of that challenge.

There are 9 areas of focus to account for when scaling design to multiple teams, or enterprises.

Core Principles
Ethical Touchstones
Team Structure
Design System
Process & Methodology
Generative Research
Behavioral Analytics
Measurable ROI
Evangelism & Outreach

Core Principles

By articulating our core principles, we ensure that everyone who practices design, or design thinking, is grounded in a common set of agreements. It’s easiest to think of this as a creative mission statement. Core principles aren’t about tactics or execution, they’re about a team’s dominant aspiration.

Considering a diverse set of examples can be elucidating, so here’s a quick list:

Salesforce: Lightning Design System principles

• Clarity
• Efficiency
• Consistency
• Beauty

Google: Material Design principles

• Material is the metaphor
• Bold, graphic, intentional
• Motion provides meaning

IBM Design principles

• A focus on user outcomes
• Restless Innovation­
• Diverse empowered teams

Airbnb Design principles

• Unified
• Universal
• Iconic
• Conversational

VMware Clarity principles

• Product-based
• Rapid development
• Evolving
• Reliable

Intuit: Harmony Design principles

• Drive cohesive customer experiences across devices and product ecosystem.
• Steward design innovation and excellence throughout the Intuit organization and beyond
• Support internal and external Intuit teams through a centralized design system and re-usable components

Ethical Touchstones

Without a code of ethics, creative and UX design quickly devolve into a seedy underworld of psychological hacks and dark patterns. Dark patterns are interactive techniques designed to trick or deceive a user into taking action. Because usability testing puts such a ruthless focus on action, a/b testing will often conclude that these patterns are a holy grail of effectiveness. As a result, almost every company has a few dark patterns in place. Developing our ethical principles is just as important as sustaining our core principles in a field where we try to view design as a force for good in the world.

Team Structure

Nathan Curtis (founder, eightshapes) provided an excellent overview of team models for scaling design systems in 2015. His conclusions are broadly applicable to design culture in general. Curtis identified three primary design team models:

The solitary model

This model is common to startups who have one primary designer and perhaps a handful of contractors. All design decisions route through a single unicorn-like subject matter expert. The solitary model is cost-effective up front but it doesn’t scale well. Solitary experts frequently suffer from tunnel vision or myopia in the absence of a diverse and well-rounded team. As in all things scalable, delegation is a necessary side-effect of growth.

The Centralized Model

This is probably the most common design team setup. A centralized team makes design decisions, which are then applied across the entire company. It works very well for agency teams and medium to large businesses. At the enterprise level, however, the scale of operations becomes problematic without a cult-like personality leading the charge.

Most centralized design teams eventually find themselves unable to maintain effective control over a sprawling brand. Friction increases between the design team and other powerful stakeholders, who may begin to exhibit a disdain for the out of touch authority. This often results in both strategic and executional inconsistency, expressed as fragmented design decisions and quality control issues between sub-brands.

The Federated Model

This model de-centralizes the practice of design while consolidating its direction by way of a style guide or design system. Federated design teams are collaborative by nature and constantly evolving based on the needs of a project or challenge. The core design group maintains a design system while individual teams are free to interpret, extend, and contribute back to it. Google’s “committee by design” is the federated system with the most visibility in the design world, thanks to Material Design. It differs substantially from Apple’s HIG model, which is based on a centralized system run by Johnny Ive.

Design System

When scaling design, diverse creative interpretations can very quickly move from being an asset to a liability. Stakeholders need to know that when they work with a creative studio the assigned team will use a consistent and repeatable process that results in a predictable quality of work. Teams also need to minimize their time-to market as a matter of competitive advantage, which is an area that has often bottlenecked with creative and UX . Design systems are a continuously evolving answer to both areas of concern.

A design system is a set of reusable modular components bound together by a style guide and comprehensive documentation. A good design system is restrictive by nature but flexible in application. Teams that use design systems have more time to focus on content architecture and the efficacy of the user journey because they aren’t continuously designing interactions and visual approaches from scratch. Design systems also contain pre-coded objects, so layouts can be generated much more quickly by developers.

Here’s a short list of some famous design systems:

• Google Material Design
• GE Predix
• Salesforce Lightning
• VMWare Clarity
• Apple Human Interface Guidelines (HIG)

Developing a design system is a specialized undertaking. Simply looking at Material Design and saying “we want one” is too big a challenge out of the gate. A design system is realized in stages, over time. Hiring a designer with prior experience building one is a good first step.

Process & Methodology

Adopting an effective process & methodology can take years, even for an experienced leadership team. The larger the company, the more difficult the task becomes; which is why growing companies are well advised to begin early and revise often. Creative and strategic process are as much about negotiation with other business units as internal dynamics. Identifying a working model means balancing the requirements of a company’s development methodology with the reality of a team’s creative process.

One of the best examples of this can be understood through the history of Lean UX (Jeff Gothelf, 2013). User experience design is, by nature, a very waterfall practice. Its practitioners are most comfortable when a nearly omniscient level of user research has been distilled into a concise strategy before a creative execution is attempted. Agile, on the other hand, thrives within the cone of uncertainty and executes small, rapid changes to an existing product. The two approaches were fundamentally incompatible and after years of friction, Lean UX was the game-changing result. To a classic UX Designer, however, Lean is still a very uncomfortable process to learn.

As a company develops its own methodology, discomfort is an expected side-effect. Learning to manage that discomfort among designers, developers, and stakeholders without causing a corporate civil war is nearly as critical as articulating the process itself.

Generative Research

In design, exploratory research teaches us about our potential audience and evaluative research tells us how they feel about existing solutions. Generative research, on the other hand, tells us what might be possible. It’s the formal study of nearly-impossible things; the Mad Hatter would have loved it. A healthy design culture spends a lot of time in the yellow circle (below).

This form of research is all about discovering the right questions to ask and gaining unexpected perspectives as a result. By involving our users directly in the human-centered design process we remove many of our preconceived biases from the result. That’s a good thing.

The work focuses on problem discovery and participatory design. The Google Ventures design sprint is a direct descendent of this practice (it requires good generative research and is a participatory ideation — though it’s not technically a generative activity). Generative research techniques enable teams to short-circuit the trap of rigid institutionalized assumptions that plagues most companies at scale.

Many familiar types of research fall under the generative umbrella:

Generative Research Methods - Usability Testing Experts

Behavioral Analytics

The fundamental difference between fine art and design is intent. Design conveys a specific message and requires a consistent interpretation if it is to be considered successful. Intent is measured through the observation of behavioral change when comparing two or more versions of a creative execution. It follows that analytics to measure behavioral change within a system are a critical component of any scalable design system. We are unable to optimize what we cannot see, and without behavioral analytics we are blind.

Unless you have an in-house data science team, measuring advanced behavioral analytics requires a suite like MixPanel or Amplitude. Less specialized suites like Google Analytics will get a team only part of the way there.

Measurable ROI

At a certain point, a company will need a way to quantify investment levels among one of more design teams based on the actual business value they provide.

A lazy set of metrics might take a ruthless approach to conversion (did the design sell more product?), which leads to the use of unethical dark patterns as a matter of survival.

Well considered metrics will account for things like speed of iteration, responsiveness to change, user satisfaction, stakeholder satisfaction, positive buzz, and adherence to the core principles and ethical touchstones established in harmony with the larger brand.

Evangelism & Outreach

No matter how well a company’s design culture has been articulated, communicating it to a diverse set of teams will make or break the effort. Every division of an enterprise has its own goals to achieve and if they don’t understand how good design is helping them, it’ll feel like extra work that doesn’t have a relevant outcome.

As design scales, so must the education and outreach program. The board of directors isn’t the only team that needs to understand the ROI of good design. Communicating our value to a every corner of the company is the life blood of a healthy and innovative culture.

—

At the time of this publication, I am a Principal UX Designer at Dell EMC’s Digital Marketing Studio in San Francisco. I learned HTML in 1997 and built my first commercial web experience in 1999. Professional designers and entrepreneurs can connect with me on LinkedIn or Twitter.

Leave a note when connecting on LinkedIn, especially if you have a weird title.

Scaling Design as the Company Grows was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

In This Series:

1. How to Intake a New Project
2. Actionable User Insight
3. Design from a Creative Brief (you are here)
4. The Design Sprint that works for you (forthcoming)

Introduction

The first article of this series looked at how a consistent and repeatable intake process can be used to improve team alignment and reduce friction. The second article explored how persona models are used to help designers feel connected to the user research. In this article, I’ll explain how a creative brief pulls all of your research together and sets the stage for a team to design for maximum impact.

A brief is the fulcrum point of your creative strategy. It tells the story of group of people who are suffering to some degree. Oppressed by bad design, legacy process, and unmet needs they toil to extract minimum value in return for their efforts. The brief describes what a design hero could do make a difference, and if saving those poor folk from misery makes us a bit of money? Well, there’s noting wrong with a little reward for our heroism.

Technically speaking, a creative brief connects the user journey to the brand’s value proposition; thereby laying the groundwork for inspired product design.

Who invented this brief and why haven’t I heard of it?

A creative brief is a short document (duh, brief) that distills the complex findings of user research into a well articulated strategy. The first creative brief was introduced by Stanley Pollitt, father of account planning (a precursor of user experience design), in the 1960s. During that era the British made some wonderful ads but the practice remained obscure outside of the United Kingdom.

It took a while, but in the 1990s account planning finally made it to the United States, and few imported it with as much success as John Steele (author, Truth, Lies, and Advertising). By combining American inventiveness with Pollit’s strategic clarity, he catapulted Goodby, Silverstein, and Partners into stardom almost overnight.

Ever heard of got milk?

Of course you have, everyone has. It’s probably the most famous deprivation strategy ever executed. It’s also a vintage Steele-era campaign. Due to the agency’s success their creative brief format was used to train a horde of eager college students in the art of account planning.

I was one of those students.

Many of us never got back into advertising after the 2008 recession. The crashing economy, along with a digital media transformation that agencies weren’t prepared for, created a perfect storm of unemployment. A decade later you can still see the echoes of traditional/digital consolidation in agency names like SapientRazorfish. The mergers continue even now.

Not content to wait out the industry’s realignment, a lot of us were forced to evolve. We used our combined technological fluency and user-centered design training to become a highly influential cohort within the first generation of professional UX Designers.

We still have a deep respect for a well written creative brief.

What Drives a User Experience Design Strategy?

Modern UX and advertising both follow a user-centered design philosophy. That’s why we are able to apply a creative brief within the scope of our own work. The two formats don’t actually diverge until we consider their intended outcomes.

Advertising expresses a “big idea” in a compelling way, which alters the recipient’s perception of a brand, leading to trial or consumption. An advertising creative brief distills the big idea from user research and pitches it to a creative team as strategy. It is a contextual bridge between insight and execution. The campaigns we see all around us are really just clever expressions of that big idea.

Experience designers don’t yet have the big idea. In fact, our stated mission is to design experiences that become the big ideas. Where an advertising strategy derives its power from an emotional selling point, we derive ours from emotional pain points. Emotional pain points drive the creation of an opportunity statement, which anchors a creative strategy. As a designer, you should have crafted one during intake (the first article of this series).

We investigated a whole bunch of questions during the assumptions worksheet activity, then validated the results into an aligned statement of beliefs. At this point we’re going to elevate three of those beliefs royalty. Together they’ll form the backbone of the creative brief:

What opportunity are we going to target?

What user behaviors will define our success?

What primary value do they (the users) seek?

The first question defined our opportunity statement, which stakeholders have already approved so we get to copy and paste it. The opportunity statement expresses both a gap in the market and a place where we can create value for our intended user. It’s our North Star.

The second question defines the actions users will need to take in order to fulfill the opportunity statement. When HD flatscreen TVs successfully penetrated broadband-equipped homes, Netflix saw an opportunity to provide theater-quality experiences to users in the comfort of their living rooms. Taking advantage of that opportunity required users to behave a certain way in their consumption of streaming media. If those behaviors failed to appear then the money invested in Stranger Things would never have been spent. Also, this would have made me sad. I like Stranger Things.

The third question defines the value that users need to perceive when the opportunity is presented to them. The perception of value motivates users to perform behaviors associated with success, and that success is why we’re paid to do this for a living.

A UX Creative Brief takes those core elements, combines them with a bunch of business and technical requirements, then expresses them as a creative strategy. The strategy has a pot of gold at the end. Happy hunting.

The Elements of a UX Creative Brief

The Opportunity Statement
Expresses both a gap in the market and a space where we can create value for the user. This doesn’t suggest what we should design, just why.

Behavioral Goals
What user-behaviors will define our success? List the actions a user will need to take in order to fulfill the opportunity statement.

Who Are We Talking To?
In simple terms, who are the people we are designing for?

How Are People Doing This Now?
Most people are looking for a better, simpler way to get value and that’s our opportunity. How are they getting that value now?

What Are Their Pain Points?
What frustrates people about the way they are doing things today? These are the problems that we need to solve if we want to be perceived as valuable.

What Would Make Them Happy?
What have people told us they want? This is a wish list of things that our potential users would like us to promise them. Dear Santa…

Technical, Branding, Budget, and Regulatory Requirements
Okay this part of the story is pretty dry. It’s necessary though.

When Is The Work Due?
List the expected completion date and any critical milestones

Supporting Documents

In an academic environment the brief is good enough to work from. Out in the business world, however, it can be useful to include some supporting documents. They aren’t super useful to creatives, but their addition prevents mission-critical details from getting lost along the way.

A list of stakeholders

This may seem like a small thing, but I define a stakeholder as anyone who can derail the train. Few things are more frustrating than someone you haven’t heard from in 3 months declaring an emergency stop because a business requirement wasn’t met and you didn’t keep them in the loop.

Personas

As described in the brief, the user is a napkin sketch. Attach all personas and any notes about how they interact with one other. You should also attach a user matrix for each one, since it’s a useful design review tool.

KPI Measurements

By the time your brief is approved, the stakeholders will probably have key performance indicators (KPIs) ready to go. KPIs are a much more technical version of the expected behaviors list. They quantify behaviors as statistical data then correlate p-values with actual revenue. KPIs are downright scary if you let them sneak up on you.

What’s Next?

I don’t know, take a weekend off? This has been a lot of work.

When you get back, we’ll talk about how to launch a design sprint in an environment… somewhat less perfect than Google Ventures would have you facilitate. Put another way, I’d like to talk about running design sprints in real life where not everyone is on board with the idea.

The sprint will take your best research and unpack it for a team of designers. Because you’ve written a creative brief, it’ll be much more straightforward to run. By the end of the sprint, you’ll have a prototype ready for usability testing and a unified group of stakeholders supporting it. Usually.

Be sure to follow me on Medium and we’ll all meet back here in a few weeks for part 4 of this series on UX Process.

—

At the time of this publication, I am a Principal UX Designer at Dell EMC’s Digital Marketing Studio in San Francisco. I learned HTML in 1997 and built my first commercial web experience in 1999. Professional designers and entrepreneurs can connect with me on LinkedIn or Twitter.

Leave a note when connecting on LinkedIn, especially if you have a weird title.

UX is Process: Designing From a Creative Brief was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

Article updated on January 14, 2018. Edits for clarity and brevity, along with the addition of new image resources. Persona examples updated January 21, 2018.

In This Series:

1. How to Intake a New Project
2. Actionable User Insight (you are here)
3. Design from a Creative Brief
4. The Design Sprint that works for you (forthcoming)

Introduction

The first article of this series looked at how a consistent and repeatable intake process can be used to improve team alignment and reduce friction when launching a design or redesign project. In this installment, we’ll move from a a validated assumptions worksheet to the creation of actionable user personas, while introducing the user matrix model I developed at Dell EMC. Before we get down into the weeds though, we’ll pause to talk about the acquisition and requisition of UX research.

Prerequisites

1. You’ve articulated an opportunity statement
2. You’ve merged and validated your assumption worksheets

Now… please pull out all of your validated user assumptions.

Short list? Probably. I’m guessing that the stakeholders have been able to provide you with plenty of information on the value proposition, previous executions, competing products, and their vision for the design; but very little in the way of who is supposed to use it. That’s kind of normal and if it’s inaccurate you are a very fortunate individual.

As tempting as it is to jump straight into persona development and the user matrix, I think it’s important that we first talk about how on earth you’re going to get enough user data to build them with. That means a very quick 101 review of UX Research.

A Brief Overview of UX Research Techniques

If you didn’t study user research as a marketing, advertising, psychology, or design student then you might not be familiar with a few key concepts.

You can skip this whole segment if you’re already in the know.

Primary vs Secondary Research

Primary research is the type you do yourself. It’s like baking a cake from scratch. When you want specific information with a high degree of certainty that your conclusions are the right ones, primary research is the way to go.

Susan Farrell published a solid UX Research cheat sheet for the Nielsen Norman Group in 2017. If you are trying to wrap your head around UX research techniques, it’s a good place to kick off a Google binge.

UX Research Cheat Sheet

Secondary research is pre-existing research on a topic or user group. Some of it is free, and some of it isn’t. When you aren’t yet sure what questions to ask and need to get a broad context for what people care about, secondary research will be your go-to. It’s a great place to start the process of discovery that leads to questions requiring primary research.

If you don’t have any budget for primary research then poll your coworkers and friends. The subject pool isn’t ideal but it’s better than flying blind.

User Testing vs Usability Testing

• User testing seeks insight about who will be using a product or service. It includes a range of techniques from ethnography to choice-based analysis to standard surveys or interviews.
• Usability testing seeks insight about how people are using a product or service. It includes things like analytics, contextual interviewing, prototype and preference testing.

Qualitative vs Quantitative Testing

There is a lot written on this. I’m going to borrow the top-line definitions from another article and link you there for more information. For now, all you need to know is the basic definition of each and that they work hand-in-hand.

Qualitative Research is primarily exploratory research. It is used to gain an understanding of underlying reasons, opinions, and motivations. It provides insights into the problem or helps to develop ideas or hypotheses for potential quantitative research.

Quantitative Research is used to quantify the problem by way of generating numerical data or data that can be transformed into usable statistics. It is used to quantify attitudes, opinions, behaviors, and other defined variables — and generalize results [to a larger population].

Difference between qualitative and quantitative research.

Qualitative research tells you what might be possible, whereas quantitative research tells you what is actually happening. Quantitative research can also tell you and whether or not your hypothesis from qualitative testing is actually valid before you go out and design a solution to a problem that nobody actually had.

Welcome back! You should stop skipping the basics now

Getting From a Data to Insight

Between primary and secondary research utilizing both qualitative discovery and quantitative validation, you’re going to have a mountain of information on hand. That’s good! A mountain is the opposite of that little stack of notes you had earlier. That information needs to be distilled into something more allegorical before we can use it though.

Definition of ALLEGORY

As human-centered designers, few constructs more poignantly illustrate our quest for the holy grail of user insight than the history of the persona.

Before the Internet became a thing, research cost a whole lot of money to commission and — true story — they faxed it to you. I know, right? What? Yes I was alive then. Stop laughing.

Way back in the 1990s most businesses couldn’t afford the time and expense of developing the validated user models required by user-centered design, so personas were the response. They were cardboard cutouts meant to stand in for a well researched target.

Personas of that era were not expected to be accurate representations of the latest demographic and psychographic data. Their primary function was to provide teams with a basic understanding the people they were supposed to interact with. The details weren’t all that important. Teams had the “what” from the stakeholder, and a cardboard version of “who” was enough to start generating ideas.

In summary, the original persona was a life hack.

Over time the persona has evolved into something much more vital. It has been grounded in behavioral psychology, steeped in online secondary research, quantified through analytics, and optimized with data science.

The Cooper Persona

On his website Alan Cooper writes “The Inmates Are Running the Asylum, published in 1998, introduced the use of personas as a practical interaction design tool” before going into a long explanation of how it evolved over time.

A Cooper persona is a snapshot of a person that any of us might meet in the lunch line. Their profile is typically named, given an age, a lifestyle, habits, quirks, and enough color that you could comfortably write them into a screenplay as an extra. The Cooper persona is less concerned with behavioral psychology and more concerned with humanizing. That is because creatives design things for actual people, not statistical models. In this context, they work really well.

The Nielsen Norman Persona

In 2015, Aurora Haley wrote “A persona is a fictional, yet realistic, description of a typical or target user of the product. A persona is an archetype instead of an actual living human, but personas should be described as if they were real people.”

In 2017, Page Haubheimer goes on to say: “Definition: Jobs-to-be-done (JTBD) is a framework based on the idea that whenever users “hire” (i.e., use) a product, they do it for a specific “job” (i.e., to achieve a particular outcome). The set of “jobs” for the product amounts to a comprehensive list of user needs.”

The key difference between a Cooper persona and the Neilsen Norman persona is that NNG’s version is realish instead of realistic. NNG personas dispense with frivolous details about the character’s personal life and stick to a description that affects how people are likely to interact with a product or service.

For example, if I’m selling a $65,000 Dell EMC storage array to a business, I probably don’t need to know that the IT Decision maker likes to bake cupcakes on the weekend with her 2.5 children.

The NNG persona is typical of what most UX teams use during ideation.

The Behavioral Persona

Behavioral personas are a recent evolution. They take the Nielsen Norman Group’s focus on relevant interaction to its natural conclusion.

Behavioral personas are cohort-based and backed up by quantitative and analytic data. Unlike classic personas, they represent an actual statistical group within a data lake and focus on how certain behaviors affect the conversion funnel. These personas don’t really care if they’re named sue, have a photo, or prefer to use social media on an iPhone. They care about actions that turn visitors into users, customers, and subscribers. Behavioral personas are all about trigger, response, and retention.

Behavioral personas tend to be dry and are better for post-launch evaluation than creative ideation. Tools like Amplitude can help you uncover surprising cohorts in the data that you’re unlikely to have thought of early on.

The Data Driven Persona

The data driven persona model allows Design teams to rapidly source insights about cohort groups then construct NNG style personas, which correlate to behavioral profiles in near real-time. They are a work in progress but strive to give us the best of both worlds. The creative team gets a human target , which is linked to a data cohort so that it can also be used to measure KPI growth down the line. If the data shifts, the design team reviews the persona the moment they are notified of a change.

If you want to experiment with data driven persona modeling, your best bet is to plug a valid data source (using an API connector to Amplitude or MixPanel groups) into a tool like UX360’s journey mapping software, which allows you to construct persona templates on the fly as part of the process. Just keep in mind that you’ll be beta testing a future state of UX, so it won’t always be a smooth ride.

• UX360 - Customer and User Experience Software Tools
• Amplitude | Product Analytics & Event Tracking Platform
• Mixpanel: Product Analytics for Mobile, Web & More

The User Matrix

While I like the idea of using a classic persona as a tool to humanize research, and I like the behavioral persona for evaluating creative outcomes, neither one is very good for planning a UX strategy.

Make no mistake — both are crucial to your success and you absolutely want to use personas to humanize the user on the other side of the data. Most designers got into the field to make a difference in the lives of real people, and we do our best work when feeling connected to them. Don’t neglect this!

When it comes to UX Strategy there are six things that I need to know about my user if I’m going to create meaningful work that improves their lives.

When I look at ideas that solve for my opportunity statement (as defined in part one of this article series):

• What does each user type find compelling?
• What turns them off?
• What do they value?
• What doesn’t matter to them?
• What tone do they trust?
• What do they worry about?

A user matrix is a shorthand view of those aspects, displayed in a six-up grid for quick reference. It’s something I came up with to help us rapidly author compelling content experiences during a design sprint. The matrix gives a useful snapshot into the values that drive a user’s engagement and decision making process.

The other thing a matrix does it allow us to instantly ask questions in a human-centered design format when evaluating creative. If I’m looking at a feature proposal I can reference my opportunity statement, behavioral goals, and the matrix to ask:

Does (this concept/content) encourage (a persona) to fulfill (a goal) in pursuit of (the opportunity statement)?

Is it compelling in a way that resonates and aligns with (a persona)’s fundamental desires?

Does this approach align with the values and desired tone of (user type)?

Back-fill the values from your creative brief (article 3) and user matrix. You’ll instantly be able to tell if an idea has potential. Because you have worked from an aligned statement of beliefs, you won’t have to spend hours fighting over people’s divergent (or worse, misinformed) opinions either. It’s a pretty magical experience.

Closing Thoughts

The key to a writing a good persona is to forge a relevant, personal connection between a user cohort and the brand. If that wasn’t hard to do, UX researchers wouldn’t get paid like engineers. Most companies seem to prefer the NNG model, but a lifestyle brand could make a case for adding things like “Jeremy is a divorced father who drives a 2009 Ford Explorer and likes surfing.”

As an extreme distillation of user needs as snap impressions, the user matrix is sometimes worth building right into your persona layout. I’ve personally found anything that don’t require a creative to read instead of skimming is worth it’s weight in peak-value Bitcoin.

To which you say “Ian, a bitcoin doesn’t weight anything” and I reply “Yes but the RAID array you keep it on at the bank is quite heavy” — but I’m getting off topic.

I’ve found both persona modeling and the user matrix critically useful to unpacking a design sprint (article 4)

Next Steps

At this point you’ve taken several steps towards creating design that matters to your users, and aligns with your stakeholders:

• You have articulated an opportunity statement
• You have aligned with the stakeholders by creating a validated set of assumptions about both the business and the user.
• You have humanized your user as a persona
• You have activated your persona as a matrix

This is all very powerful stuff, and in the next article we’ll pull it all together as a creative brief.

When our brief is finished, we’ll talk about how to launch a design sprint that works best for your organization, and finish with a bit about how that fits into the context of dual-track agile delivery.

—

At the time of this publication, I am a Principal UX Designer at Dell EMC’s Digital Marketing Studio in San Francisco. I learned HTML in 1997 and built my first commercial web experience in 1999. Professional designers and entrepreneurs can connect with me on LinkedIn or Twitter.

Leave a note when connecting on LinkedIn, especially if you have a weird title.

UX is Process: Actionable User Insight was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

In This Series:

1. How to Intake a New Project (you are here)
2. Actionable User Insight
3. Design from a Creative Brief
4. The Design Sprint that works for you (forthcoming)

Article updated on January 14, 2018 to include two different assumption worksheet formats.

Introduction

Stop me if this sounds familiar. There’s a wall a lot of aspiring and establishing designers hit. You want to practice UX the way it was taught in school and on the blogs but neither source taught you how to deal with multiple up-line authorities that don’t fully agree with one another.

The misalignment leads to waste, rework, and frustration. Eventually someone pulls the plug and either a businessperson or engineering team decides on a design, leaving you (the designer) to push pixels in Sketch or Photoshop. You know you’re polishing a turd but you’re doing it under orders from the person who pays your bills.

It’s not what you leaned in class, and it’s not how things are supposed to be — but what to do?

This article series is written primarily for the benefit of a community of designers who got into UX to make the world a better place but don’t know how to structure a project for success. It’s also written for students who are, with good reason, terrified about their first/next steps. For the veteran readers, it’s a nice review of techniques I’ve accumulated over the years. Perhaps you’ll find some process notes that are worthy of emulation.

Alright then. Let’s get started.

First: the most important thing you can understand right now is that UX isn’t a job, it’s a process that contains a series of jobs. You may be in one or more of those roles as the UX lead on your team (UX Researcher + Interaction Designer is a classic hybrid) yet as the saying goes “You can do anything but you can’t do everything.” (yes, I’m looking at you… unicorns)

UX Design is not just about software. Service and event design are huge upcoming fields and product design (better known as industrial design) predates software and the web by decades.

UX Design is, in a lot of ways, about creative and strategic process more than it is deliverables. The biggest procedural challenge faced by growing professionals usually starts with learning how to intake a new project, articulate a design challenge, align a group of stakeholders, then decide what a team is going to build. The rest, as they say, is just details.

The first step in this process may look familiar to anyone who has ever worked in a startup because, in a lot of ways, a UX Design challenge mirrors a startup design challenge. In both cases, we need to know several things before we can start to ideate or evaluate design concepts:

1. What is the high-level opportunity?
2. What assumptions are the design and business teams making?
3. How can we validate those assumptions, aligning knowledge and expectations with real data, to form a strong partnership for ideation?

Why this stuff matters

As a kid, did you ever play a version of a game called telephone?

It’s a game with a simple premise, and it’s often presented as a way to understand how rumors and misunderstandings get started when a group doesn’t communicate directly.

1. Put a bunch of people in a circle, the more the better (within reason).
2. Hand a piece of paper with a statement written on it to the first person in the chain and have them read it silently to themselves.
3. That person whispers what they read in the ear of the next person in the circle, who whispers what they were told to the next on down the line.

By the time the statement reaches the other end, hilarity ensues. It’s often nearly unrecognizable. You then jump to a few spots back along the line to see how it changed over time.

This happens all the time with the collective vision for product design, where the results are decidedly less hilarious. If you’re not 100% sure you agree, try an experiment. Go ask a few different people at your business the same question about your product or service. Make it something simple like “what our product does for people” or “who is this product is for?” 99 out of 100 times, you’re going to get some pretty divergent answers.

Now apply that trend to the vision for a new product, one that doesn’t exist yet. Viewpoints abound and all of them have some measure of value. Not all of the value statements are exactly the same though, which creates some real headaches when a designer tries to get their work approved for production.

In the end the highest ranking leader dictates design based on their gut, and the result is exactly what you would expect.

Spoiler warning: it’s not the decision maker who gets the blame when the product goes sideways after launch. In the Silicon Valley, this produces what we call a “resume generating event”.

Our journey begins with a single step: the clear articulation of an opportunity.

Identify Your Opportunity Statement

Every innovation starts in the same place but sometimes it takes a lot of heartache and tears to find it. There isn’t time for heartache or tears before the end of this article, so we’ll skip that part and just articulate the high-level opportunity we’re trying to solve for.

It’s pretty easy to spot a team that hasn’t done this. You’ll see a lot of emotion around the issue but a weak and muddled expression of what should be a fantastic product or service. If it feels like your company’s product is trying to be different things to everyone, while pleasing no one, you’ll probably find conflicted opportunity statements at its root.

Don’t be shy about backing up to this step just because you’ve got Series B funding in place and investors think they’re close to a breakthrough. Clarity of purpose begets clarity of design.

More often than not, when I ask for an opportunity statement, I’ll get a very technical answer back.

Me: What high level opportunity are we trying to solve for?

Stakeholders: immediately tell me what they want to design, and a bit about how it’s supposed to operate.

Unfortunately, that isn’t an opportunity statement, it’s an execution. I’ll add a bit of context and ask again.

Me: What OPPORTUNITY are we trying to capture? As in what problem does the execution I’ve just had described to me attempt to fix?

Stakeholders : “We want to use compelling content to position product X as a leader in the mid-market space, where our competitors have made inroads since the merger.”

That’s good! That’s less executional and it tells me the actual goal that will accomplish an opportunity statement. What we’re trying to get at, however, is one level of inception further up.

The goals that stakeholders are intimately familiar with exist in pursuit of the high-level opportunity. With that final bit of context in place I will ask the question a third time and hear something like:

“Mid-Market represents an undercapitalized segment in the storage space, and small gains at scale translate to huge ROI increases. We need to re-establish a dominant message in that space.”

Yes, this. This is the opportunity.

When you find your opportunity statement it’ll feel like a very tightly focused value proposition from a mini-business plan. This is not an accident. As we established earlier, a UX Design project is… just that. Those of you familiar with my work know that the sprit of UX is essentially entrepreneurial.

This opportunity statement will be the founding component of a creative brief, which you’ll read all about in the third article of this series.

The Assumptions Worksheet

Credit for the assumptions worksheet goes to Jeff Gothelf, although I’ve seen a dozen versions of it since he first published the activity in Lean UX, which should be required reading for any aspiring or professional UX Designer.

This activity expands on the idea that before we start designing a solution we should make sure everyone agrees on what we are trying to build, for whom, and why.

There are a lot of important questions that come up in this context. Jeff’s work centers around business and user assumptions but other teams have come up with versions that anchor questions to the lenses of human-centered design: Desirability, Feasibility, and Viability (or the four-lens approach: people, design, business, and technology).

I’ll provide two different versions of the assumptions worksheet here.

A Jeff Gothelf Style Assumptions Worksheet

Business Assumptions

• We believe our customers have a need to…
• Those needs can be solved with…
• My customers are (or will be)…
• The primary value a customer seeks is…
• Other things that create value for the customer are…
• We will acquire the majority of our customers through…
• We will make money by…
• Our primary competition on the market is (or will be)…
• We will beat them due to…
• Our biggest product/service risk is…
• We will mitigate or solve this by…
• We will define our success by the following customer behaviors…
• What other assumptions do we have that will cause us to fail if they aren’t true?

User Assumptions

• Who is the user?
• Where does the product/service fit into their work or life?
• What problems does our product/service solve?
• When and how is our product/service used?
• What features are important?
• How should our product look and/or feel?

Ian Armstrong’s Assumptions Worksheet

Important Note: If you don’t have enough information to answer a question, skip it. Not every stakeholder group is expected to have a well-defined position on other group’s concerns.

Business Assumptions

• What opportunity are we going to target?

• What is preventing us from doing that now?

• Who is our primary competition in this space?

• What is our advantage over them?

• What is our biggest service risk

• How can that risk be mitigated?

• What user-behaviors will define our success?

Technical Assumptions

• What is our biggest technical/engineering challenge?

• Do we have any regulatory risks?

• Will any internal policies get in the way of an ideal solution?

• What financial constraints are we under?

• Have we established a research and testing budget?

• What delivery deadlines are we facing?

Design Assumptions

• What branding guidelines are we using?

• What platforms are we going to support? o Browser (HTML, web app, isomorphic JS, AEM, Jive, Hybris, etc.)

— Native App (android, iOS, Alexa, etc.)
 — Video (webinar, live event, streaming, downloadable, etc.)
— Audio (podcast, download, transcription services, etc.)

• Is this a new design, redesign, iterative update, content revision, or clone?

• Are we missing any critical information required to design a solution?

• Will this require a design sprint or can it be handled by a single team?

• Do we think the design team will need to hire additional contractors?

User Assumptions

• Who is / will our users be?

• What problem do they want to solve?

• How are they solving this problem today?

• Why are they unhappy with the current solution?

• What features do they think are important?

• What is the primary value they seek?

How to use the completed worksheets

Like the primary objective, you’ll find there are often enormous divisions between what stakeholder groups and the design team believe about the incoming project. As you can imagine, a misalignment on something as fundamental as who the customer is, what they have a need to do, things that create value for them, or how we measure success within the user experience will make it nearly impossible to produce high quality work. All of your best ideas will die in committee.

As we’re fond of saying in the design business: a stakeholder is anyone who can derail the train, and there are many stakeholders.

Getting Into Alignment

For each of the questions you’ll want to review answers. I like to fill out my own worksheet based on my understanding if the business request. I’ll then run through each one and call out the thing being assumed:

I’ll then go through our existing research and see how many of the assumptions can be validated. This almost always requires checking in with the team that filled out the worksheet and, more often than you’d think, they’ll have an interesting bit of research to back up their claims. After I’ve got that information I end up with three three categories of assumptions:

1. Valid assumptions, with the source documented
2. Valid assumptions that are in partial or full conflict with one another
3. Invalid assumptions, that need to be risk-assessed

Conflicting assumptions between teams are unbelievably common and can often be reconciled with research, or by getting additional context. If an assumption is unverified and there isn’t a trustworthy source available, it will look like one of these:

0. If invalid, this will cause the project to fail
1. If invalid, this may cause the project to fail
2. If invalid, this may impact the efficiency of our user journey
3. If invalid, this is unlikely to have any measurable impact

Any Category 0 or 1 invalid assumption needs to be researched before beginning the design phase.

Category 2 is the sort of assumption that is nice to validate but it isn’t essential, especially if doing so would cause significant delays to verify. Stakeholders find being forced to wait for things... distasteful.

Category 3 is a black hole where things to go die; we don’t assumptions in this list because they are irrelevant.

Once you have performed the research necessary to eliminate all stop-level invalid assumptions you’ll have completed an aligned statement of beliefs, which becomes part of your strategic documentation. It’s basically a merged version of the answers, which all stakeholder groups formally approve.

Next Steps

Your opportunity statement and aligned statement of beliefs will be joined to a series of user personas (article 2), which together form the backbone of a creative brief (article 3).

Continue to the next article in this series

—

At the time of this publication, I am a Principal UX Designer at Dell EMC’s Digital Marketing Studio in San Francisco. I learned HTML in 1997 and built my first commercial web experience in 1999. Professional designers and entrepreneurs can connect with me on LinkedIn or Twitter.

Leave a note when connecting on LinkedIn, especially if you have a weird title.

UX is Process: How to Intake a New Project was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve recently been in a couple of conversations around responsive design that centered on how to name our various breakpoints. In both cases things came back to Bootstrap canon. Anyone who ever poked around in the Bootstrap LESS files back when it was the only framework that mattered would recognize these variables:

@screen-sm, @screen-md, @screen-lg

In a more recent conversation with an IT team I was faced with a proposal to add another t-shirt size to our ever growing breakpoint support list. On reflection, I had a few reservations. My reservations weren’t based on the time required to build another full iteration of components. Instead, I found myself concerned with what a continuation our old school bootstrap interpretation of responsive design represents: a technically expedient nomenclature that doesn’t account for the mental model of the user.

Right or wrong? That’s really a matter of responsive framework philosophy. I kind of have one. As you may have guessed, I’m about to explain it.

There are many valid configurations when creating a responsive framework. None of them are wrong. We aren’t here to get pedantic but, rather, to expand on an old definition in a user-centered way. Let’s start at the beginning of my responsive epiphany, way back in 2015.

(That’s probably several generations in tech)

At the EMC Experience Studio (pre-Dell) our conceptualization of a responsive design system was based partly on the technical constraints of the browser’s viewport but primarily on the mental model of the end user. I think it’s a subtle but important distinction. A user’s mental model and preferred interaction style are affected by the device they are on more than the number of pixels rendered, except in the case of mobile orientation.

In response to this idea, we supported a number of potential breakpoints that were conceptualized based on ergonomic use cases instead of pixel width. Again, this isn’t a new idea — but thinking about it in terms of object reflow (we’ll get to it), object affordance, and mental models isn’t yet part of our best practices conversation.

In many cases, object display and affordance will be radically different between device categories. For example, a user on a smartphone device typically has a smartphone app user’s mental model even if they are using a mobile web browser. Knowing this, we would use interaction design patterns like action sheets and thumb-menus instead of dropdown boxes and hamburgers. That’s why the dellemc.com website has a bottom navigation instead of a hamburger when you hit it on a mobile device.

Within a breakpoint, however, we would use tools and conventions to make the entire layout fluid (relative percentage based, visually speaking).

This brings us to an important pair of definitions: object reflow and fluid adaptive resizing. These aren’t new terms but it’s important to understand them before forging ahead. When taken together and combined with an awareness of user mental models, a new-ish definition starts to take shape.

Responsive Breakpoints and Object Reflow

A breakpoint is, in our responsive philosophy, a reflow point. A page reflow rearranges objects within the web browser to present the user with an optimal interactive experience, based on their device type and orientation. A reflow updates interaction models to better reflect the ergonomics of the use case, as well as the visual presentation. A reflow is about more than just the amount of real-estate available within the viewport, it’s about matching user behaviors and affordances to our on-page presentation.

There are seven logical reflow points within a responsive experience:

SMARTPHONE

mobile-portrait

mobile-landscape

TABLET

tablet-portrait

tablet-landscape

PERSONAL COMPUTER

small-monitor

large-monitor

omg-wow (typically a letterboxed experience)

A reflow is about more than just the amount of real-estate available within the viewport, it’s about matching user behaviors and affordances to our on-page presentation.

Fluid Adaptive Resizing

While a responsive breakpoint reflows content, there are many aspect-ratios and pixel-depth combinations within each one.

If this feels new to you, it may help to think of the breakpoint as a zip code, whereas all of the possible browser & resolution permutations represent buildings in the neighborhood.

For example, a maximized browser on a 13” MacBook Air is likely to use the same small-monitor breakpoint as a 24” low-end desktop computer. The mental model and overall layout aren’t all that different, and are best defined by a limited amount vertical space before the traditional fold (under 700 css pixels after accounting for browser chrome elements). Nevertheless, there may be a range of sizes to account for, particularly since a user’s browser window isn’t always going to be maximized.

Fluid adaptive resizing is employed to account for this variance.

The idea behind fluid object definitions is that, within a breakpoint, object sizes are defined in percentages instead of in pixels. To understand this, imagine that you have four boxes on a screen and each has a width of 25%. No matter how much you resize the browser window, unless you cross a reflow point, those four-boxes will be proportionally sized.

Tools involved in fluid design are legion. Here are three examples.

• Srcset & sizes (CSS3) to optimize the pixel density of a bitmap image
• SVG vector elements for lossless object and graphic element scaling
• A JavaScript-based tool like FlowType.JS for text scaling

There are many tools and standards to choose from. Their goal is to ensure that, within a selected breakpoint, the relative size of objects and their on-screen position remains consistent.

Within a breakpoint there may be a range of sizes to account for, particularly since a user’s browser window isn’t always going to be maximized. Fluid adaptive resizing is employed to account for this variance.

In Conclusion

Technically speaking, there’s nothing wrong with classic t-shirt sizing in a responsive model. There’s also nothing wrong with classic laptops from 2001, unless you need them to handle a modern workload. Within the context of today’s internet, t-shirt sized responsive breakpoints that pay only lip-service to user’s mental models aren’t keeping up with the modern concept of a user experience. The workload has changed.

Perhaps it’s time to update our standard thinking around responsive conventions at a community level?

One of the most important things we can do in UX, other than represent the voice of the user; is to bring psychological, visual, and technical considerations into alignment. Moving from a pixel-based approach to a user-centered approach when talking about responsive design frameworks at a foundational level is another thing we can do to advance the cause.

—

At the time of this publication, I am a Principal UX Designer at Dell EMC’s Digital Marketing Studio in San Francisco. I learned HTML in 1997 and built my first commercial web experience in 1999. Professional designers and entrepreneurs can connect with me on LinkedIn or Twitter.

Breakpoints are for reflow, the rest is fluid was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

Earlier this week I had a check in with a UX Designer I had a hand in training before we hired her at the Studio. Being a new transfer into the field, she likes to check with me when she faces a challenge for the first time. Deb Zell recently asked her to do some heuristic reporting on several inbound projects. The question that came up in our meeting was essentially “how do I report on this in a way that moves us forward?” — and I had to admit the existing structures were creating a lot of noise without a clear signal.

Thanks Ranjitha, that was an excellent question. I think I’ll write about it.

There’s an article on how to run a heuristic evaluation at UX Mastery, which does a solid job of outlining the classic process. If you’re feeling the Susan Weinschenk angle on heuristics (The Psychologist’s View of UX Design), Jordisan has crafted a great Google Sheets project around her work. As I started to relay all of this information to Ranjitha though, I realized all I was doing was giving her a more structured way to output raw data.

The mark of a professional UX researcher is an ability to report not just results, but useful insight along with next steps. I’ve got a method for doing that but I’ve never written about it before. Also hey everyone, thanks for reading.

What follows rests heavily on the shoulders of UX giants, all I’ve done is restructure their work.

When I run a heuristic evaluation I frame the entire thing around an intersection of user needs and business goals, which are expressed as a series of value propositions. Those of you who are familiar with my work in the broader UX community will recognize that as a the same value framework produced by Ideo’s lenses of human-centered design, which I spend a lot of time talking about. That’s intentional. It also serves as a great way to explain what a UX Designer actually does, in case your mom asks again.

Because we want to frame a heuristic evaluation around value, we open up with a mission statement:

Restatement of design objective & behavioral goals

• Identify the opportunity or problem statement being resolved
• Identify the business goals
• Identify the user actions required to support those goals

The UX professionals in the room will recognize this as a major component of a creative brief. Whether kicking off a new project or evaluating an existing one it’s important that we:

1. Identify a problem or opportunity set (as experienced by the user)
2. Articulate how that’s relevant to the business (conversion goals)
3. Understand what actions the user has to take to fulfill those goals (the user journey)

Everything else that follows serves this mission, including how the design heuristics are evaluated. This is a foundational tenant of goal directed design.

There’s a second problem though.

Classic heuristics are framed entirely around psychological concepts. They are wonderfully descriptive but often difficult to convert into actionable insight. On a design team we take action on specific areas:

1. Information Design
2. Interaction Design
3. Funnel Design
4. Visual Design
5. Content Design
6. Accessibility Design

So when a designer like Ranjitha reports on a Weinschenk metric like “In every moment, just the indispensable information is provided on the screen” under a category called “People have limitations” — how is that actionable?

How do we un-limit these poor folks?

As it turns out, the concept breaks out into multiple metrics under several categories

Information Design

• Flow of information is matched to to user task flow
• Provides immediate, transparent access to mission-critical or frequently needed information.
• Expository text is kept to a minimum
• Additional information is available on demand instead of by default (firehose effect)

Interaction Design

• The hierarchy of influence between elements is clearly apparent (Gestalt psychology)
• The most common/important functions are easiest to find (Pareto principle)

Funnel Design

• The funnel is well structured and meets the high level UX goals (funnel optimization)
• System appears to match the user’s mental models

Content Design

• Section titles are clear and descriptive
• Copy is written using familiar terminology
• Copy eschews the use of tropes that the reader may consider kitchey or inauthentic
• Linked resources do not pull the user out of an action funnel
• The experience uses consistent terminology

Violating any one of the listed bullets will cause non-essential information to appear, thus increasing cognitive load and reducing the likelihood of continued engagement or conversion. Trying to figure out how to report on a heuristic like “In every moment, just the indispensable information is provided on the screen” becomes incredibly complex as a result.

On the other hand if the main problems are failing grades on “expository text is kept to a minimum” and “linked resources do not pull the user out of an action funnel” there’s a laser-beam tight path from the heuristic to a proposed solution.

What we’ve now done is familiar to anyone who has worked on an Agile team: we’ve taken a broad set of Weinschenk metrics (epics) and broken them into task-oriented bite-sized chunks (stories). The idea is that we get at all the same psychological data but do it in a way that suggests a path forward.

The goal is to generate actionable insight. So far it’s working pretty well.

“Okay Ian, where’s something I can use?”

Oh right. That.

This is an ongoing project at the studio, so I don’t have a pretty application that you can fire up just yet. In fact I can’t even guarantee there won’t be significant changes to the document over the next few weeks — but we’ve got a living document (a draft) up in Quip that is receiving daily edits.

That’s not something I mind sharing: https://dell.quip.com/LVNCAbmJW7ox

If you have anything to add, please don’t hesitate to mention it in the comments below!

—

At the time of this publication, I am a Principal UX Designer at Dell EMC’s Digital Marketing Studio in San Francisco. I learned HTML in 1997 and built my first commercial web experience in 1999. Professional designers and entrepreneurs can connect with me on LinkedIn or Twitter.

A New Framework for UX Heuristics was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

A couple of years ago I had a conversation with one of my UX mentors, Diana Furka, about soft skills in design. Now that I’m in a position where I often interview and review UX Design candidates, I think a lot about our talks on the topic. They mattered. They pointed me in some excellent directions over time.

We all know the technical skills involved in UX. They range from fluency with design software to an ability to run a card sort or a conjoint analysis. We like to see a portfolio of work. We need to see a familiarity with lean UX and agile methodologies. In short we’ve got great lists of things that make a person technically proficient. That’s a good starting point when sorting resumes but we all know it’s just the beginning.

Those things aren’t what make a designer great. Greatness is quantified by soft skills, which many of us have a difficult time articulating.

Just last night I was lucky enough to chat with a woman who exhibited so many of the soft skills I associate with advanced UX that I spontaneously decided to take her under my wing. That’s the second time in six months I’ve convinced myself to do so, and we just hired Ranjitha Anantha at the studio as a result of the last one.

When you know, you know. But what is that mysterious quality?

In my professional experience there is a growth progression that starts with a deep curiosity about the world and eventually becomes directed empathy inside a shell of diplomatic design leadership. What follows is my articulation of that journey:

Curiosity: Curiosity is the root of intelligence, humor, and human connection. It is the starting point from which a designer launches and is axiomatic to the trade. Without curiosity we cannot create anything new.

Generosity: UX Design is inherently entrepreneurial and the entrepreneurial spirit is inherently generous. Designers are driven to leave everything they touch better than they found it.

Analytical: The ability to view a problem, opportunity, or pain point from multiple angles is a requirement for successful ideation. Our minds begin teasing apart problems and opportunities on contact, even before we have learned to re-shape them.

Articulate: To successfully design anything, we must first be able to describe it in clear, digestible, and actionable terms. To lead a team we need to be able to articulate a process. To defend a design we need to be able to articulate our strategy. Articulation is the primary vessel of effective communication.

Directed Intent: The ability to harness our talents and execute them on command, with intention. We no longer wait for inspiration but instead activate a mental process that results in creative output. We are specific in our designs. We predicate the success of our work on an ability to elicit specific behaviors from a group of users.

Process Driven: An advanced designer has developed and is able to articulate a consistent and repeatable process, which can be imprinted on multiple teams as a way to maximize their effectiveness.

Polymath: UXers have mastered a broad range of skills related to their process of creating value. The list isn’t specific. We don’t necessarily practice those skills professionally, but have achieved competence in them; often because it brought us joy too do so.

Judge of Character: Able to quickly and accurately discern authenticity and competence in people and practitioners without having to be an expert in the subject area being observed.

Empathetic Patience: The more time we spend in UX, the faster our minds move. It’s a side effect of regular practice with pattern recognition and complex systems. The ability to be patient with people who aren’t experts in our craft only becomes more important as our skills advance.

Parallel Processing: The ability to track multiple information sources in an environment and hold them all in our mind. The best designers can hold a truly daunting amount of information at the ready and offer it as insight on demand.

Synthesis: The mental manipulation of information results in an accurate synthesis vs a simple summary. Yellow and blue aren’t just green. They remind the user of spring when planning a vacation in February. Greens also create accessibility issues for people with deuteranopia so they shouldn’t be used in opposition to reds in a critical context. Incidentally yellow-blue color blindness is called tritanopia but the two types don’t generally occur together… you get what I’m saying.

Strategic Persuasion: People don’t do what we tell them to, they learn what is modeled to them. The most powerful ideas are the ones we come up with ourselves. Whether developing content or interfaces, we learn to let people close their own conceptual loops with the information we’ve provided them. It’s like drawing 90% of a circle with ideas and letting the receiver finish it.

Directed Empathy: It isn’t enough to simply be empathetic, we have to be able to focus on a specific user process and empathize with it from multiple points of view. This is really a synthesis of previously mentioned traits that appears in advanced designers.

Diplomatic Leadership: It’s one thing to see the underlying patterns in the world, and quite another to be able to manipulate them through design. Being able to bring people with us on that journey in a way that doesn’t alienate, disparage, or upset them though — that is the most noble trait of a design leader. We learn to manufacture excitement and demand in a place where intractability once held sway.

—

At the time of this publication, I am a Principal UX Designer at Dell EMC’s Digital Marketing Studio in San Francisco. I learned HTML in 1997 and built my first commercial web experience in 1999. Professional designers and entrepreneurs can connect with me on LinkedIn or Twitter.

Soft Skills in UX Design Leadership was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.