One of the laws of stress

I think about stress a lot.

I learned yesterday about an interesting study conducted in 1908 related to the application of stress and the affect on productivity, a study that is still impacting how organizations view worker productivity today.

Robert M. Yerkes and John Dodson conducted an experiment with a box. The box had set of smaller boxes inside. One of the smaller boxes was black, one was white. They would put a mouse in the box. If the mouse walks into the black box, it gets a shock.

Yerkes and Dodson wanted to know if varying the intensity of the shock affected how quickly the mice learned that the white box was the safe option.

Then they wanted to know if the same rules applied when the boxes were obscured with a screen, making it harder to tell them apart.

They found some interesting results.

For the simple task--black box or white box--the mice learned faster as the shocks got higher.

For the harder task--when the screen made it harder to distinguish the boxes boxes--the mice learned faster when the shocks were lower, but performed worse as the shocks got higher.

This led to this general principle: environmental stresses help performance, but only up to a point. This relationship became known as the Yerkes-Dodson law.

The Yerkes-Dodson law, via Wikipedia

Human biochemistry generally aligns with these findings.The body responds to both internal and external stressors with the release of stress hormones which negatively impact memory, attention, and problem solving.

Consider stresses that can affect performance. The last year has been an onslaught of external factors here in the US. The pandemic and its economic fallout. Incidence of police brutality and the subsequent racial unrest that gripped the country. An insurrection on the US Capitol.

Everyone is bearing witness to these incredible and stressful events, and experiencing the emotional impact of all of the factors above.

In the workplace, consider individuation of those factors; the pandemic has affected different people differently across broad factors like racial lines, economic lines. Personal and vicarious connections to racial and civic unrest weigh heavy on many. The frustrations of a virtual school society for small children, and on and on.

In an unfortunate turn, the Yerkes-Dodson law could easily be weaponized. It's a simple interpretation: break down each given job in your organization into the simplest tasks possible, apply stress to the workforce, reap the benefits of productivity. My immediate consideration is logistics. Whether it's Amazon fulfillment or UPS, the tasks at hand are monitored and optimized to be as simple as possible while ramping up quotas, targets, or other stressors.

But in the tech sector, so many job roles are living in an in-between space between the expectations of high performance and the perks and policies that are specifically targeted to reduce stressors.

As a manager, learning about the Yerkes-Dodson law shaped how I'd like to manage a team. Many of our design challenges are complex and under stress, these are exceptionally challenging. The pressures of the pandemic are putting people in to a high-stress state, even before they begin. If this most recent performance review season has seemed extra tough, then that's why--complicated, cerebral tasks like the self reflection and long-term thinking associated with career development can seem especially arduous for someone under today's conditions. As a result, I'll be working with my team to consider way to break down the tasks, and peel back the stressors, as best we can.

I'm going for an MBA

My educational history on Linkedin. Life is weird!

Well, here we go.

Why would a designer get an MBA?

Early in my design career, I was the only interaction designer at a burgeoning ecommerce startup. I found myself pushing pixels around my computer screen after hours in the latest of a string of late nights. I was in the process of transforming our company’s aging, buggy, and quirky checkout flow into a more stable and usable version that could allow the company to scale with confidence. The checkout flow of any ecommerce site is the linchpin of the business; any problem can have significant downstream effects on revenue, service level commitments, and customer satisfaction. It made sense that the VP of marketing would stop by to look in on my progress and ask a few questions. 

“How do you think this will affect conversion,” he asked. He pressed further, “how do you know it’s worth the risk?” His questions were straightforward, but I struggled. “This will drastically improve the conversion rate for a wide swath of our customers,” I said, based solely on my opinion that the design looked better than the old version. I had no concept of how to measure that improvement and, most importantly, I lacked the vocabulary to describe the downstream outcome for the business. 

In the thirteen years since that late night, my competency with business metrics has deepened significantly. My design process now goes much further to align business and customer outcomes. I have taken an active role in facilitating design projects with numerous business stakeholders, both as an in-house designer and as an independent consultant. I have guided teams through the Design Sprint process, leading customer research efforts, and designing new product experiences. 

In spite of my best improvements, challenges remain in connecting business strategy with the design process. Business leaders typically only experience the impact they have on customers through a narrow set of quantitative metrics. Design leaders, while working directly on the products that affect customers, sometimes lack the vocabulary to articulate the impact of design decisions on business outcomes. This tension is where my career lives, every day. 

While I have a design background, I have regularly taken steps to learn the language of business with greater fluency. It’s not hard to imagine the steady stream of business books and Medium articles, the webinars, the various workshops. Over time, this served me well, but now  that I am assuming greater responsibility through leadership, I’m ready for a greater investment. The MBA is the next step.

Why this MBA?

I will be attending the Online MBA through Boston University Questrom School of Business. I landed on it for a combination of reasons.

Online format: I was looking at this option before the pandemic, but with social distancing rules in effect for everyone's safety, an online option has made a tremendous amount of sense. Day to day logistics of transitioning from work to class will be far easier (or at least faster) through an online program.

Diverse cohort: I'll be joining the second semester of incoming students for this program. So far, the program has accepted students from all over the world and in a wide range of backgrounds. The incoming class averages ~12 years of work experience, as well.

Generalist curriculum: I have some confidence in my specialization as a designer and design leader and I'm seeking greater foundation in business fundamentals, data, risk, and strategy. This program is targeted for people who people like me who are not trying to change career paths.

Cost: as I began researching MBA and Executive MBA options locally, they all ranged from $70-$125K all in, and those prices could change per-semester. This program's $24K cost, paid $4K at a time, is an amount I can live with.

The greater BU community: This is a lesser, but interesting factor as far as selecting this particular program. I don't have any connection to BU (yet), but I have been encouraged by what I have seen thus far. I am pleased that BUQSB has committed to the online MBA program with the hiring of a dean for online programs, Dr. Monica Moody Moore. Perhaps the most resonant development I found is BU’s commitment to racial equity, demonstrated in the selection of Dr. Ibram X. Kendi to lead the formation of the Center for Antiracist Research. Dr. Kendi’s work on antiracism has been an inspiration and I am thrilled to know that his work will find a vibrant new home at BU.

And so it goes. I'm looking forward to starting in January and following this path wherever it may lead.

Building a Design System Without a Team

Update: I changed the title of this post from "Design Systems for Small Teams" to "Building a Design System Without a Team."  This is a more accurate description of the content of this post and addresses the key issues: building a design system when it is impossible to dedicate full-time resources. 

When a new design system is announced, I'm right in there with everyone else, digging into the public documentation website, examining the versatility of their responsive assets, clicking through to examples, and, of course, visualizing my own team's ability to do the same. But the shine wears off quickly and it gradually seems impossible.

Looking at design systems from AirBnB, Google, IBM... Eventually, there's a wake-up call: You're not in the FAANG. The design systems you're looking at online are built by dedicated teams, specialists hired to do that work. They develop specific skills and processes, whether they are full time members of the team or agencies with highly capable teams of their own. 

If you are on a small product team, it is unlikely that you are in a situation fitting the above description. You're more likely to be generalists and stretched thin. 

If you maintain the expectation that you will be able to deliver what those big teams deliver, at the same cadence, and in the same manner, you're going to have a long string of bad days. 

How am I going to pull this off with 20% of one designer's time and sporadic development commitment? We can't be this detailed or specific or thorough. We can't dedicate a team to the design system. We don't have engineers dedicated to the design system. We can't even fully dedicate a designer to the design system. We don't have a 'design ops' person, let alone a team. 

Your Responsibility

I'm speaking here to design leaders. That may include senior IC's. That may include management-only types. But If you're someone who takes on the design system project and helps define the process and infrastructure for creating and maintaining that system, then I'm talking to you.  

For the sake of this discussion, a design system lives in four places:

Design Assets: The library of assets that designers use in their work in accordance with the design. Sketch symbols, Figma components, etc. These tools are specifically for the design team. 

Codebase: The front-end code base, that lives actively in production that executes the design ecosystem, reflects the design tools. This is specifically for the engineering team. Naturally, in organizations where designers also code, there can be relationships drawn for collaboration & contribution, again depending on the team's dynamics.

System site: A realization of the design ecosystem in the format of a publicly accessible site. This tends to include visual examples and code snippets for each component. This also reveals the taxonomy and hierarchy of components, along with the intentions and limitations around their use. There are ways to split the responsibility for this between the design and engineering teams, depending on the team's dynamics. 

The design ecosystem: devoid of medium, this is the set of rules and guidelines made visible that define the brand, product, and resulting experience. The design team owns this, in tight collaboration with stakeholders like content strategy, marketing, leadership, etc, if your company has each of those. 

A functioning, living, breathing design system will be realized through the creation and maintenance of these four things. 

So, what first?

While you may not be able to commit a full-sized team to the effort, the system will need an owner, an individual contributor on the team who can be the steward of the system for the long run. This does not mean they need to be the final arbiter of what goes in the system, although that can help a lot. On my team, it was our intrepid designer Mai who took the reins. 

Out of the four concentration areas, you need to start somewhere. I advocated for starting with design tools, namely a pattern library for the design team to use while creating new designs.  

It may sound selfish, but if you have any hope of propagating any design standards through the organization, you have to start with the design team and assure that work in flight is designed to spec with consistent execution.

Build out a shared library of patterns for the team. Make sure everyone is using the same grid, type, form fields, buttons. As projects com into the team, apply the new assets. Look at every project as an opportunity to bring more of the digital experience into alignment.

Keep your side of the street clean. 

Gain allies

Seeing the design team get in order and deliver consistent, high-quality work has a positive downstream effect as work is delivered. 

Development team members, realizing that the work from the design team is consistent, will soon realize that they save time component-izing their work, too. The challenge is getting both teams to accept the immediate reality that components in the code base will just trickle in, project by project, Jira ticket by Jira ticket. At this point, there's a bit of a leap of faith; building components in the hopes that components will make a system.  

It's not unreasonable for members of any team to second-guess the need for a design system. It is reasonable, predictable, and manageable. 

Project by project, the components stack up, and the proof is in the engineering team's estimates; as components take hold, front end estimates shrink due to efficiencies built in re-use.

My team saw the best results focusing on projects that included form fields: the components are a little complex so the savings associated with reuse is significant.

Gradual Reach

Two more tools can be powerful in extending this lightweight approach to building out the design system. 

A kanban board with tickets created for each component to be made. First column on the left is a great inventory of all components that have not yet been built as part of any project. Final column on the right is components released to production. A few columns in between for design stages, accepted for for development, etc. We've used this simple set up as a complement to what's in the codebase.

A tool like Zeroheight helps a lot for building out a first iteration for your system site. Those geniuses have set up a way to point their site at your Figma, Sketch, or XD pattern library file and--BAM!--it spits out a site of the design system. Not bad! It makes another great tool, in conjunction with the kanban board, for engaging an engineering team on the intended output of the design system.

Once there is some momentum in place, then it sets the stage to begin conversations over the design ecosystem. How can this system be extended to other design materials, content strategy, and brand assets? In some ways, it feels remedial to revisit the system from these other angles, but it is part of the process of extending the reach of the system.

Leveling up the product experience this way takes time, but it gets there. It's cheap, it's scrappy, and it's doable when there's no team to commit to the work. 

So, don't be intimidated by what IBM, Google, Adobe and other big companies are doing. The most important thing to do is to make progress in standardizing the experience of your product, period. On a small team, it doesn't have to happen overnight. 

A lunch for my 8 year old

The Ritz towers

When it’s lunch time, it’s not uncommon for my 8yo to balk, turning up her nose at the day’s meal. She usually comes around with some cajoling, but I find the process exhausting.

Today I told her I wanted to see how high we could stack up her lunch using ritz crackers. I grabbed an arm full of miscellany out of the refrigerator and we went to work.

The savory tower is turkey, shredded cheese, a baby bell cheese, topped with a dorito.

The sweet tower is peanut butter, jelly, chocolate frosting, blueberries, and a peach slice.

She was engaged, enjoying it, and cleaned her plate. It was a win.

In her usual day to day, I feel like she’s under stimulated. As so many working families have done in the pandemic times, we’ve adopted a completely lax stance on screen time. And, as so many working parents have probably ascertained, I feel like it’s nowhere near what she needs. This lunch was a brief respite, offering a tiny challenge in the face of a giant challenge.

Reflections on XOXO 2019

XOXO felt like many things.

There's a feeling I get around genuinely creative people. I remember feeling it in college, surrounded by artists, photographers, actors, and designers, many of whom continue to be artists, photographers, actors, and designers.

I don't get to feel that feeling very often. Sure, I may go to a design meetup or other function, but it's not the same.

I felt it again at XOXO, along with a few themes that percolated into view.

Twitter then and now

The feeling of optimistic connection reminded me of SXSW in 2007. That was the year Twitter really first really appeared. Virtually everyone at the conference learned about Twitter for the first time while at that conference and singed up. It was still SMS-based and very limited compared to what it is now.

I remember coming home from the conference and telling other designers I worked with, "well, I don't know what it is, really, but I know it's going to be something."

The story about Twitter at XOXO in 2019 is very different. It is an algorithmic Nazi reward system. It is an addiction. It is a weapon It is the drug. It is the network of support for your dearest community. There were calls to log off, and examples of how it saved lived. Needless to say, our relationship to Twitter is now far more complicated, and not all for the better.

Imposters are people too

But maybe more importantly, SXSW 2007 was also a time when I was in a funky place about design. I was working as an Associate Art Director in a marketing firm, stumbling my way through some campaign work for a DSL ISP and not doing a good job of it. I was lost.

2019, I spent 6 months without full-time work, stumbling my way through freelancing and really not sure what was next. Somehow, the previous 15 years of design work weren't quite the asset that I would have liked them to be, instead weighing on me as an obligation and expectation for what I should be achieving.

When I first lost my job this year, I thought it was going to be like launching a startup on a vacation--an amazing journey. Instead, I spent the next six months disappointing myself and feeling ashamed of it. I didn't invest the time to learn the prototyping tool I thought I would need. I didn't reach out to meet developers who could help bring an idea to life. I didn't test the popularity of my idea with some kind of vaporware sign up page.

I didn't do any of the things that I have coached startup founders to do. I didn't do any of those things, even though I had the resources to do it--and that's probably the most shameful part--as if I spent six months of the year betraying the creative trust.

My only reconciliation of this time is that depression played a huge part in it, too. The suppression of creativity, the amplification of personal shame, it's all in depression's wheelhouse. I'm still working through it, slowly and quietly.

I confirmed my attendance for XOXO during this time, booking travel and making commitments, but not really sure what would happen.

A cleansing breath

During my first day at XOXO, I was texting with my wife a bit, checking in. She asked how the conference was going and I said that I could only describe it as "a detoxifying sensation." Due dates, competing interests, prioritization, responsibilities... they all sort of left the body for a time. The pressure of my own creative future, while uncertain, was relieved.

At XOXO, those stresses were replaced with nourishment from attendees and speakers. Attendees were open, friendly, and welcoming. Many attendees have their own creative works that they were sharing with others. Each speaker at XOXO is at the height of their game; creating, sharing, reflecting, struggling, persevering through struggle. The galvanized the room with their vulnerability and candor.

And it is in stark contrast to what I'm seeing in other parts of my professional life, where a sexual predator is suing a conference where he committed multiple acts of harassment because that conference is following its own code of conduct and forbidding him entry and he's mad. It's disgusting. And reading about it, mostly on Twitter, makes my blood boil.

So grateful

This being my first time at XOXO, I'm left to connect my own dots for what makes this event so special. Attendees and speakers are a huge part of it, but it doesn't happen on its own. And so I am left with immense gratitude for the Andys, the fearless founders and organizers of this conference and festival. They have created this event with visible attention and care, listening openly to the community and curating a thoughtful and welcoming event at every step of the way. I will never forget it.

XOXO Day 2

Another great day!

Conference presentations

Tracy Clayton discussed her battle with depression and how online addiction helps and hurts. She reminded us all: Log off, Fam.Emma Kinema is organizing gaming industry workers, one unfair work environment at a time. Support the cause »Harry Brewis (hbomberguy) played Donkey Kong 64 for 36+ hours to spite a transphobic comedian and ended up raising ~$350K for a trans support organization.Hundred Rabbits is a couple lives on a sail boat and develops iOS apps. Their presentation was a living testimony to reducing life's distractions.Black Belt Eagle Scout / KP, an indigenous activist and musician told us the story of the Chinook nation, her mother's forced adoption to a white family, and then performed a beautiful song about the emotional journey of coming out to her mom. She also advocated giving to the Chinook tribal nation, that they may reclaim their tribal treaty land of Tansy Point »Soleil Ho told us about the colonialist nature of food criticism and how she is now shouldering the burden and gift of upending that legacy at SF Chronicle.Caitlin Doughty showed us that she was always into death and that we have a lot to learn.

Story: Live podcasts in Revolution Hall

You're Wrong About: a breakdown of the Janet Jackson Super Bowl Halftime show, the fallout, and Les Moonves' legacy of being awful.Everything is Alive: an interview with a chainsaw.Yo, Is This Racist?: Listening to voice mails from people asking, "is this racist?" Spoiler alert: it's totally racist. This also included an incredible moment from a member in the audience, questioning whether their teenaged enthusiasm for hip hop culture was problematic.The Allusionist: a breakdown of titles like Mr, Miss, Ms, Mrs and many, many others; where they came from, what they mean, and why there's ridiculous from today's perspective.Punch up the Jam: Holy shit, the most rollicking teardown of the Ghostbusters' theme song, remixed and torn apart and turned into something amazing. I am honestly still sore from laughing.

XOXO Day 1

There were opening remarks from Andy and Andy to kick things off, but I missed almost all of it because I was dealing with ATT. That made me sad. 

Then I went to theTim-Tam Slam meet-up and drank coffee through a cookie and then ate the cookie and it was amazing.

Then I met a former teacher who is now doing social-emotional work with kids. She is handing out free mini-zine guides that tell you what to do when you're freaking out. And her husband who is a cool developer. They live in Austin.

Then I had a crazy Japanese lunch of fried and pickled things, though I'm not entirely sure what.

Then I noticed my phone was running low, so I left to charge devices.

Back to the festival, a chance to play with PlayDate, the crank-based gaming handheld.

Went to a meetup with a bunch of designers.

Dropped in on the ADX maker space to check out a few projects like handmade boats, sculptures, vintage cars and a skin care product line.

Jumped into the Video segment for Nerdwriter, Hair Love, Earworm, Say It Loud, Some SmallBu productions, and closed it out with Unraveled.

And now, to bed, what a day.

XOXO Day 0

Landed in Portland and made my way to the XOXO Festival's opening party.It's my first XOXO and of last night is any indication, it's going to be a good time.The opening party included...

• Jousting using VR joysticks
• Good Filipino food
• Readily-available water
• A churro truck
• Tons of friendly people

Looking forward to more!

So, what's your process?

The process depends on the context of the project. Here's the process I favor for an in-house product design effort:

Phase 1, Discovery: Get to know the people who are likely to use the product, the scenario when they encounter the product, and what objective they're trying to achieve and clarify what problems are standing in their way. Conclusion: a prioritized understanding of the problem that needs to be solved.

Phase 2, Design Strategy: Formulate a hypothesis for how to achieve their objectives, and in trying to solve it, go nuts--generate a ton of ideas and solidify a strategy for the content of the experience. Then prototype a chosen solution in a way that looks and feels real(ish). Validate the hypothesis by having real people use the prototype. Conclusion: a clear strategy and direction for a design solution.

Phase 3, Execution: Bring the validated solution to life by elevating the visual and interaction design while refining the content. Once released, observe, measure, and learn how people use it. Conclusion: the design is in market and the team learns from the success or failure of the effort.

In an optimal project setting, I could be able to have some involvement into every stage in this process, whether conducting the work or supporting the team by removing roadblocks they encounter.

Partners

Working as a designer, and leading a design team, is collaborative work. Each step of this design process requires engagement from other partners and stakeholders along the way. It is a team sport.

Within Phase 1, Discovery, there is usually a fair amount of overlap with product managers and researchers. Customers and internal business stakeholders are key to the process as well. In Phase 2, Design Strategy, input from content strategy, while validation from stakeholders and customers is again critical. Product management can help refine key metrics and technical partners can inform opportunities. In Phase 3, Execution, I will lean heavily on visual design and development to execute and business intelligence to assess the performance of the product.

Built for flexibility

Ultimately, this workflow acts as a utility belt. In each phase of work there are a variety of tools to choose from, depending on the context of the project.

The Discovery phase relies on talking to people who represent the users of this product: competitive analysis, content audits, interviews, usability tests, task analysis, even surveys as a last resort. The output of this phase is to synthesize the findings of the research into a tangible concept for everyone on the team to understand; personas, scenarios, content guidelines, problem statements.

In the Design Strategy phase, we have a variety of tools to work with. A well-defined hypothesis can bring direction to a team's work. Activities like sketching sessions, card sorting, affinity mapping, among others can help drive new ideas to address the hypothesis. Prototyping those ideas at a low fidelity is the sure fire way to gut check the strategy and quickly refine critical interactions, content, and overall strategy.

In the Execution phase, the options focus towards precision. Visual designs, fine-tuned interaction prototypes, front-end development, style guide and content refinement all come into play. And once the product hits the market, its success needs to be measured to verify that it delivers on the promise of the original hypothesis. This measurement and observation is the connection that fuels the cycle, feeding he team's ongoing insight and understanding of the customer.

Any of these methods, workshops, deliverables, or techniques can fit into an existing Agile working framework with a little focus and collaboration across the team.

Having different tools for different scenarios helps keep my work sharp, delivering the most value to the business in the most efficient way possible.

Dealing with the real world

In reality, not every project will have the opportunity to engage all these stakeholders all the time.

It is common, but not ideal, for a designer to arrive in a project in Phase 3: "We know what we want, just make it happen." And you might see a team slice off any plans to learn from the product in market. The problem here is that the designer might know how to do what you want, but they aren't going to be as effective if they don't understand why you want it.

It's a little better if a designer can enter the process at Phase 2: "We figured out the situation, design a solution." Sometimes, some of the steps, like validating an idea before executing it, get left out. The issue here is that a designer might be defining a strategic solution without a full understanding of the context surrounding the problem.

Ideally, a designer is an active participant in Phase 1: talking to people who will ultimately be affected by the output of the design effort imbues a personal responsibility to deliver an effective and valuable solution. Involving a designer at this step reduces the risk of misdirected effort.

Even if starting a project already in a execution phase, I think it's still possible to do good work. Entering a project late in the game can give a designer the opportunity to prove their mettle to other stakeholders and partners, leading to better opportunity on the next project to demonstrate the value of good design.

Designing with AI (some day)

A few years ago, when we first got an Alexa-bot, I wanted to do a little test. My daughters were about 9 and 5 at the time, and I wanted to see how they reacted to it. I showed them how to give the cylinder its basic commands, playing their favorite music and telling us what the weather would be for the day. They picked it up right away, although the 5-year-old's higher voice didn't always catch the robot's ear. But, more importantly, I noticed something that I always found very telling, even if I can't put my finger on what it means...

I made sure to refer to Alexa in a generic way, "it." My daughters immediately, called it "her." It's not a leap, probably just anthropomorphizing based on the default voice, however I was struck by how easily and quickly it happened. They didn't have any hesitation in referring to this black plastic cylinder in the same fashion as a human being.

Who's there?

This has long left me curious about the potential for our interactions with AI. IVRs have long been commonplace and chat bots are facilitating an increasingly more robust interaction between companies and their customers. Every call that starts with "You have reached the [company] automated system" or IKEA's "Anna," the prototypically Swedish personality of their chat bot. Something I think I took for granted was the notion that interacting with a robot could be incredibly helpful and efficient, but I took for granted the idea that I would know I was doing it. Then this appeared...

https://www.youtube.com/watch?v=D5VN56jQMWM

Last May, Google's CEO demonstrated how Duplex AI takes a command from a person "make me a haircut appointment on Tuesday morning anytime between 10 and 12," and then calls a hair salon and sets up the appointment by using a lifelike voice and interacting with a person. The crowd goes wild.

I wasn't a fan.

What I saw was a non-consensual interaction with an artificial intelligence system. It was, at the least, rude. For example, when someone speaks on the phone, isn't is customary for them to identify themself? If you take a call from someone and they don't identify themselves, aren't you suspicious? And if the woman running the hair salon were to ask, "to whom am I speaking?" how would the Googlebot answer?

We didn't get to find out in that clip, and these are knowable and addressable problems, but it made me uneasy that without this customary courtesy in place, the engineers in attendance still considered it a triumph.

This is not to take away from the truly remarkable technical achievement this phone call represents, but it reaffirms the stance I have had on AI for a long time:

I am not worried about the emergence of AI, I am worried about the implementation of AI in a systemic technical culture that moves fast, and with a certain ethical carelessness.

Unclear anxiety

Among designers, I have been apart of conversations that are a bit anxious about the future of AI from multiple directions.

• So are we designing conversations with robots?
• Will a robot take my design job?

I can confess: I have has some of this same anxiety once in a while and a lot of it comes from a lack of knowledge. Reading about AI is somewhere between a deep dive into a technical black hole and an over-cologned sales pitch about the value it will deliver.

Getting some clarity

I had the pleasure of attending a workshop at the ServiceNow office examining the still-to-be defined future of AI's impact on the design industry. The workshop was primarily run by Cody Frew a Sr. Manager of User Experience Design for ServiceNow’s Platform Tools, and Laura Coburn, a Sr. UX/UI Designer for ServiceNow’s Vulnerability Management Product.

It was a pretty interesting session! They covered a little history on AI, where it came from, where it is today, and where it's headed.

In a light summary, we looked at the history of AI's emergence which is full of ups and downs. Then understanding AI as three things...

• Artificial intelligence, the interactions that act like people
• Machine learning, the ability for machines to identify patterns in ways people can understand
• Deep learning, the ability for machines to develop insight into situations, think: robots that win at chess or go

(It turns out, there is a fourth layer, neural networks, but that's a conversation for another day.)

Then the conversation shifted some of the ways that AI is already percolating into the design community and processes. For instance, AirBnB's sketch-to-code uses computer vision to translate sketches from a whiteboard into components in their design library. Netflix uses some really complicated and really fascinating algorithm tech to generate all those placeholder images that they then test a zillion times over to entice you to click on them. To some extent, Netflix designers would shift roles. Instead of mocking up title cards, they would allot more time to evaluating and tuning the results of the algorithm's output while, in a new way, partnering with the tech, to introduce new visual concepts back into the scope of the algorithm. When machine learning merges with high-speed automation and human creativity, the role of the designer can shift.

So where else will there be automation? And where will the automation affect people's jobs?

The workshop guided us through a skills assessment, rating ourselves on a scale of 1-5 in various different design skill areas, each with specific tasks or areas of knowledge. We filled in a diagram, 1 a the center, 5 on the perimeter, creating a spider graph (or RADAR graph or whatever you want to call it).

My assessment, in all its self-biased, self-reported glory.

Once our self-assessments were ready, the speakers passed out some delightfully retro transparencies to lay over the skills assessment. The transparency represented how each area of knowledge is split into specific capabilities, and how each skill capability presumably stacks up in a world where AI has permeated the tools and skills of designers.

With the future-state transparency in place. So shiny!

In short, the future state of design is mostly focused on wrangling people through workshops, research. That felt good for me. Interaction design, prototyping, and writing would go through some realignment, which I found interesting.

There was a fair amount of conversation about the reduced need for pixel-perfect specs and front end web dev, identifying that the bots will take this over in spades, but that the skillset will shift towards information visualization, something that is still nuanced. There were some visual designers and front end developers in the room that didn't seem happy about that.

Does it change the process?

This workshop left me to evaluate how the design process would change with the introduction of AI. Naturally, there's an impact, but where? Here are some hypothetical high-level areas where the design process could be affected by AI in the near future.

Design research: Participant recruitment could be made more efficient by using AI to identify candidates for participation in research. ML would identify behaviors across products through the deep analysis of retargeting tracking and other data. Once consenting participants are identified, they could opt in to having their smartphone collect ambient data, communicate with other enabled devices, forming anonymized webs of tracked behavior data. Behavior models could be augmented to create norms of probably interaction based on user decisions in situations across different media, previously untracked.

In addition to participant engagement, existing customer contact could be mined at new levels. For instance, natural language processing could cull through recordings of customer service calls, revealing trends and attitudinal metrics. Currently, customer service reps have a few seconds to give each call a single disposition code, however some data always fall through the cracks since a call can cover multiple topics. Calls could be more accurately re-dispositioned, rated in tone, and more accurately tied to business outcomes.

Problem definition and visualization: Based on trends found when modeling user behavior data a system that could identify user personas and their interactions and ultimately identify where obstacles may be causing problems for those personas. Drafting a user journey could be automated or accelerated by a smart visualization tool that is able to layer multiple channels of interactions into a set diagramatic visualization language A sketched whiteboard of a user journey or other workflow could be translated using computer vision and digitized into a workflow diagram (sort of like Lucidcharts on steroids)

Prototyping: Sketched UI designs could be realized against a fixed development framework, like Google Material. This means a designer could work with stakeholders to rapidly sketch options for their product challenges, while turning them into developed prototypes. Additional gestures or visual shorthand would be introduced to program interactions into the prototype. Once the prototype is in place, it could be 'dry fit' against the behavior models culled through ML, showing the likelihood that a user completes a task as designed.

Ethics: Many discussing the introduction of AI into the design and technology fields raise ethical concerns, but few are proposing solutions. I see two key areas for improvement.

First, with an advanced understanding of criminal and unethical behavior data, create an algorithm or other programmatic method that can be used to automatically QA a product for potential abuse and systematic biases of the humans and algorithms involved. Use AI to protect against the risk emerging in AI.

Second, reaffirm human understanding within the design process, to reality-check design work each step of the way. Designers (and all members of the product development disciplines) will need to incorporate a new question into their acceptance criteria and do so further upstream, repeating the question throughout their process: How can someone use this product for harm? Our collective ingenuity often outsmarts the systems we put into place, but our vigilance can overcome it.

We'll see

There are many more areas that have potential to be augmented and accelerated by AI. More importantly, just writing the description above, I was immediately stricken by how potentially invasive it could be, allowing private entities like corporations access to incredible amounts of data, with the ability to tie that data together in ways never before imagined. At a minimum, when developing products using AI, we simply must inform people that we will be using this technology, that we will be combing their data in new ways and connecting it to other data. Informed consent will be critical as experimentation will become increasingly consequential. Checking and rechecking our work against negative unintended outcomes will become just as important as conceptualizing a new product idea.

It is also important to understand that these abilities will not be evenly distributed in the world. Some companies, people, governments, or communities will have access to remarkable power of artificial intelligence. I am not confident that all of those early innovators will be sensible in implementing this technology. Hopefully, we can support each other in building out our own understanding as a community.

My kids, who didn't hesitate to anthropomorphize a robotic cylinder, are the first generational wave of pioneers in this new frontier that we will be building for them. Hopefully they are the first recipients of a understanding, and not the first wave of victims of our hubris.

Ethics in Design

You have seen it

When I started in the design field, I had trouble finding a job that was a good match for both my entry level skill set and my hunger to do exciting design work. At that point, getting steady work took precedent and I took a job with a company that brought with it some ethical baggage. Am I sure I want to do this? What about what I had heard in the news about this company?

At the end of the day, I simply needed work and while it wasn't exciting and the company raised eyebrows with some, I figured I would get from it what I needed: experience and a paycheck. I compromised.

Later in my career, I was freelancing at a senior level and had the immense privilege of choosing between different clients. I looked at each and asked "if I do my job, what happens?" This lead me to working with a company whose work significantly reduced carbon emissions in the environment--something extremely important to me. I didn't have to compromise in taking the job.

Later, while working at a company that had an altruistic mission, I was faced with some product experience decisions that could increase some risks in the sales process of the company's most profitable product. I negotiated working scenarios where we had to strike a balance between a sales-focused experience vs a customer-focused experience. In other words, do we speed someone through a transaction as quickly as possible, or do we hold their hand through the process, explaining and re-explaining every step of the way even at the risk of them abandoning the transaction.

I remember arguing that a product might be creating risky situations and feeling as though I was the only one. I was going up against the rest of my product team, our bosses, company leadership. I had to make peace in the moment--how was I going to move forward in a way that I could live with but still execute something that the company could benefit.

There were times when I compromised, and times when I didn't.

As a society, we're still figuring out the potential reach of digital technology, and these lessons are emerging in each meeting, critique, and office debate.

As a designer working on that technology, your ethical standards will be challenged at some point. It may happen before you even start the job, as you consider whether to do work at a company. It may happen when debating the strategy for a new feature, determining whether you're executing on what is important. It may happen when working in the details of a design, determining if your work will influence people's behavior in a way that is helpful or harmful. It will happen.

So what do we do?

First off, it makes sense to know where you stand. Know what is important to you. Ask yourself the question, "if I do my job, what happens?" and make sure the outcome is something you can be proud of. If that doesn't work, make sure it's something you can live with. And if you can't do that, look for something else.

But what about when we're doing work, discussing product strategy with our team, or evaluating screen-by-screen experiences?

This is where we could use some guidance.

Looking to others

Other professional fields have dealt with this. Not surprisingly, the fields where there is an immediate risk of harm are where the ethical standards have become the most apparent. The Hippocratic Oath is an example of a set of values for doctors. The oath originates in ancient times, however the modern version of the oath was developed in 1964 by Louis Lasagna, Academic Dean of the School of Medicine at Tufts University:

I swear to fulfill, to the best of my ability and judgment, this covenant:
I will respect the hard-won scientific gains of those physicians in whose steps I walk, and gladly share such knowledge as is mine with those who are to follow.
I will apply, for the benefit of the sick, all measures [that] are required, avoiding those twin traps of overtreatment and therapeutic nihilism.
I will remember that there is art to medicine as well as science, and that warmth, sympathy, and understanding may outweigh the surgeon's knife or the chemist's drug.
I will not be ashamed to say "I know not," nor will I fail to call in my colleagues when the skills of another are needed for a patient's recovery.
I will respect the privacy of my patients, for their problems are not disclosed to me that the world may know. Most especially must I tread with care in matters of life and death. If it is given me to save a life, all thanks. But it may also be within my power to take a life; this awesome responsibility must be faced with great humbleness and awareness of my own frailty. Above all, I must not play at God.
I will remember that I do not treat a fever chart, a cancerous growth, but a sick human being, whose illness may affect the person's family and economic stability. My responsibility includes these related problems, if I am to care adequately for the sick.
I will prevent disease whenever I can, for prevention is preferable to cure.
I will remember that I remain a member of society, with special obligations to all my fellow human beings, those sound of mind and body as well as the infirm.
If I do not violate this oath, may I enjoy life and art, respected while I live and remembered with affection thereafter. May I always act so as to preserve the finest traditions of my calling and may I long experience the joy of healing those who seek my help.

"The Hippocratic Oath Today" NOVA, PBS

The oath is remarkable in its brevity, breadth and depth: education, treatment, bedside manner, humility, privacy--it's all in there. One of the oath's strengths is its emphasis on the relationship between the doctor and the patient. However, there is no mention of how to run the business of medicine, where so many challenges lie in today's society and economy. The is no mention of pharmaceutical company influence, pharmaceutical pricing, insurance markets, or the impact of for-profit corporations on patient care.

As designers, it is also difficult to relate to the relationship that a doctor has to the patient: who are we in this construct? The doctor? And who is the patient? A client company? The customer?

But how bad can it get? Amazingly bad.

Some answers may be found when branching out out from medicine itself to medical research, where another advisory document acts as a guide for ethical standards. First, a little history:

Starting in 1932, a group of African-American men were placed into an experiment conducted by the US Public Health Service and Tuskeegee University, a historically black college in Alabama. The goal of the study was to research the untreated effects of syphilis until the time of a person's death, however this goal was not revealed to the men participating in the study. Out of the 600 men, 399 had syphilis at the time, while 201 did not. The men were given free medical care and other benefits for participating. They were told they were being treated for 'bad blood," a colloquial term used to refer to any manner of ailments, though they did not receive the correct care for syphilis.

The men were told that the study would last only six months, but they were ultimately observed for 40 years, living with the disease without their knowledge, and dealing with the consequences. The experiment was designed in a way that it could not be considered complete until all participants had died and been autopsied.

Even when confronted with accusations of unethical practices throughout the 1960s and 70s, the Centers for Disease Control, which had taken over the study, insisted on continuing the work for the sake of research. The CDC's efforts were supported by prestigious organizations such as the National Medical Association (representing African-American physicians) and the American Medical Association.

Ultimately, an investigator for the US Public Health Service in San Francisco,  Peter Buxton, took the story to the press. Ted Kennedy called for hearings and in 1972, forty years after it had began, the study was finally terminated. Only after a lawsuit from the NAACP was a compensatory settlement was issued to the remaining survivors and their families.

It is considered the paradigm of unethical experimentation in American history.

An ethical response

In July of 1974, in the wake of the scandal, the National Research Act was signed into law, creating the National Commission for the Protection of Human Subjects of Biomedical and Behavioral Research. The commission was formed to analyze research practices involving human test subjects, assess the risks of these practices, provide professional ethical guidance, and deliver a definition of informed consent for each research setting, especially for vulnerable populations. Their findings and guidance were provided in, The Belmont Report, a 10-page guide to conducting research on human beings.

OK, this is where it gets interesting for designers again.

The report starts with defining medical practice vs medical research. Practice is work done solely to improve an individual's wellbeing. Just because someone deviates from conventional practices doesn't mean they're doing research, even if they call that work "experimental." The definition of research quoted in the report gets interesting....

...the term "research' designates an activity designed to test an hypothesis, permit conclusions to be drawn, and thereby to develop or contribute to generalizable knowledge (expressed, for example, in theories, principles, and statements of relationships). Research is usually described in a formal protocol that sets forth an objective and a set of procedures designed to reach that objective.

The Belmont Report, Boundaries Between Practice and Research

Most of our work as designers of digital products and experiences bears a striking resemblance to research in this case. We are doing work to hypothesize, test, and learn.

To drive ethically effective research, the Report advises three core ethical principles:

Principle 1: Respect for persons

The respect for persons comes in two parts:

1. That people are autonomous, capable of determining personal goals and acting with self-determination
2. That people who cannot act autonomously deserve protection

In our field as product designers, respecting the autonomy of individuals is of paramount importance. The autonomy of individuals can often be overlooked or de-prioritized in favor of the collective interests of a business as expressed through their own internal metrics for success.

Principle 2: Beneficience

Beneficience is defined as an act of charity, mercy and kindness as an extension of a professional practice (I had to look it up, too). As such, the report calls for all research efforts to do no harm while maximizing possible benefits. Ultimately, this strengthens the commitment to the individual involved, obligating any researcher to knowingly assess the risks that will be posed to a test participant.

Principle 3: Justice

The Report poses the question clearly: "Who ought to receive the benefits of research and bear its burdens?" Historically, the burden of medical research subjects fell to those who simply couldn't say 'no,' whether they were hospitalized, imprisoned, partially or fully incapacitated. This can not stand. Screening test subjects requires constant scrutiny to mitigate biases and assure that vulnerable segments of the population are not being targeted.

Advised application of these principles

The report also advises the application of ethical principles to research as follows, paraphrasing here:

1. Only proceed with informed consent. This means that participants have access to and comprehend all information about the experiment, then volunteer to participate.
2. Take measures to assure that the research is justifiable. Assess the probability and magnitude of risks, to the best of your ability, against the possible benefits of the research outcome.
3. The selection of research subjects should be consistently evaluated for fairness in mitigating bias and eliminating the odds of taking advantage of vulnerable populations.

Taking it on

I found the Belmont Report fascinating. I wanted to distill it down into principles that can be woven into parts of the design process. Having experienced ethical dilemmas concerning the impact of my job, the role of a product, or the unintended consequences of a feature at various parts of my career, I wanted to explore how an ethical framework could be applied through the design process.

I also wanted to take a moment to consider that the label of 'research' applies to more than one facet of the design process, and the application of these ethical principles would vary accordingly.

In interpreting the Belmont Report's principles for use in a product design context, I settled on these three:

1. Respect people as individuals
2. Provide more benefit than harm
3. Examine any affected population

And in practice

1. Utilize informed consent
2. Evaluate the benefits of the research
3. Select participants fairly

These principles sound great in a blog post, but do we need to take this into account for product design?

So what about us?

As designers of digital products, we're loathe to think that anything we would do would approach the harm of the Tuskeegee experiment. But we should be wary of letting hubris set in.

It is well-documented that experimentation with Facebook's feed may have influenced the emotional state of approximately 689,000 users, without their knowledge, consent, and without total scope of the potential impact.

Metrics used to define success of an app or site tend to lean towards engagement behaviors, such as daily active use, time on site. Engineers and designers have found that getting the user addicted to the experience of the product is a surefire way to boost their internal metrics. Even the inventor of the infinite scroll, Aza Raskin, admits he didn't consider the far-reaching outcome of that feature.

But, he said, many designers were driven to create addictive app features by the business models of the big companies that employed them.
"In order to get the next round of funding, in order to get your stock price up, the amount of time that people spend on your app has to go up," he said.
"So, when you put that much pressure on that one number, you're going to start trying to invent new ways of getting people to stay hooked."

Aza Raskin, interviewed by The BBC

But here's the hard truth: there will be no peace. There will be no perfect state of balance between ethics, design, and commercialization. This is a challenge of progress, not perfection. So how do we make progress towards products that engage but do not substantially risk harm?

Finding a way forward

I have been working with user experience design in an Agile environment for nearly 15 years. In that time I have seen an increasing commitment to product design in a manner structured around the scientific method, especially developing a hypothesis for testing.

A sampling of the 160,000,000 results for query: design is a hypothesis

The principles of ethical research stated in the Belmont Report can be carried into product design work in two key areas: design discovery research and the product design process.

Do design research

There is a relatively clear parallel between the process of research described in the Belmont Report and the practices of design research in the discovery phase of a given project.

Design discovery research is predicated on reaching the right audiences, honoring the complexities of their life experience, and proposing beneficial solutions.

The ethical crisis facing product teams emerges when considering whether this research is happening at all. Many teams move forward without discovery research, instead using the experimentation and validation of the product as their research framework, whether it's called that or not.

Having no familiarity with the human beings on the receiving end of a product, viewing them purely as consumers and their use of the product as their only value is a fundamental departure from both the Belmont principles and basic user-centered design practices.

This absence of understanding has also become so common as to the point of normality, not only in the big companies highlighted above, but in the countless smaller companies fielding product teams that are under-served, under-resourced and under-powered. The research process is overlooked or undermined on a regular basis on these teams.

I would also argue that viewing your customer or audience in purely quantifiable means additionally diminishes the role of their humanity, further narrowing and biasing any perspective on them as a person.

Putting out ethical fires

When taking a course of action to improve the ethical outlook of your team, the first step is recognizing them and, most importantly, addressing them while they are in progress. Lu Han, Product Designer for Spotify makes an excellent point:

"One way to recognize when a trade-off is being made is to pay attention to the language being used."

Designing for Tomorrow - A Discussion on Ethical Design, Lu Han

She goes on in her article to highlight phrases like "just put it in the T&C" that are warning signs of potential ethical risks. The sad part? The phrases she identifies have been VERY COMMON.

Opportunities for built-in ethics

The time has come for us to realize that ethics is simply not too much to ask.

Consider this: in response to the Tuskeegee scandal, the Belmont Report did not advise spot-treating ethical violations as they happen, but instead recommended firmly-rooted principles for creating ethical standards.

To ingrain ethical standards into the practice of design, there are two larger points of integration, design principles and Agile development.

Design principles

In the technology sphere, design principles are fundamental ideas used by design teams to inform a standard of practice. These typically revolve around visual characteristics...

Made up principles for a design team:

• Unified: provides a cohesive experience that clearly communicates the brand to the user
• Simple: never distracts the user with anything unnecessary
• Useful: provides necessary functionality
• Delightful: sparks joy for users, turning ordinary tasks into a delight

I just made these up... but they sound so familiar somehow, right?

The idea being that the team, when working, would critique their work against these principles and determine if it is on par with their standards. But you can see how superficial these principles can be, focusing on lightweight form and function, and avoiding deeper product considerations.

This presents a key opportunity for inserting ethical standards as design principles, and integrating them into the design team's day to day considerations for all their work.

That would be nice. But design principles have an Achilles heel. Two of them actually.

First, the principles are aimed at the designers. But the designers aren't the only ones making the decisions that can have a negative impact the product and on the customer. Product managers, software engineers, QA engineers, salespeople, customer service representatives, the General Counsel, the CFO, the CMO, the CEO... lots of people are making decisions that have an impact on a give team's product and the people who use it. It's just unfair and unrealistic for designers to be the only guardians of good in this equation.

Secondly, when the design team is crunched for time, under-resourced, and on deadline, sometimes principles get overlooked entirely. I don't like to say it will happen, but it can happen.

Solving these problems means that ethical commitments to design have to happen on multiple levels, ideally with commitment from leadership.

Design critique towards ethical principles

As work is in progress, design feedback is a critical refinement tool. Feedback should already avoid reactionary and directive feedback, favoring a more productive critique structure:

If your objective is to achieve _____, then doing _____ does/doesn't meet that objective because ______.

... and explore introducing an additional step in the process to highlight ethical risks.

If your objective is to achieve _____, then doing _____ could create an ethical risk when ______.

The Belmont principles of respecting individuals, beneficience, and justice would provide fundamental guidance in these scenarios.

• ...this doesn't take into account the customer's intensions...
• ...this has a consequence of XYZ, whether intended or unintended...
• ...this will create a disproportionately problematic situation for XYZ vulnerable population...

.... and so on.

Frame the critique to consider both the quality of the work and the outcome of its execution, whether that outcome is intended or not.

And this scrutiny extends to all processes and materials within the design process.

Additional ethical enhancements to agile methods

Beyond situationally addressing ethical issues or as they come up, and carrying principles as a design team, there remain opportunities to apply ethical principles into the product design process by interfacing with the tools and ceremonies employed by other members of a typical product team working in an agile environment.

Setting ethical objectives

The objectives for a project can take different forms depending on the operations of the team, including team-level OKRs, problem statements, or as narrow as a hypothesis for an individual project. Have these objectives been considered against ethical standards?

Ethical prototyping

As a design hypothesis is refined and designs are developed and refined through critique, the work can enter a prototyping cycle for evaluation, testing, and rapid validation. The prototype itself can leverage a design library that has been refined to be accessible for broader populations, while testing script and participants can be formed under ethical research standards. Additionally, as a team, when the prototype experience comes together, ask yourself: could this have unintended but serious consequences? At a minimum, write them down and discuss trade-offs. Even better, consider alternatives that mitigae that impact.

Ethical sprint grooming

In working with my development teams, I treat sprint grooming (previewing and evaluating upcoming user stories) as a design critique with a technical audience. I have used the opportunity to bring them into the project; sharing research findings, gaining additional buy-in, and presenting prototypes as design work that will be produced.

In many cases, there are trade-offs at this point, cutting features in favor of speed to market. With a new focus on maintaining ethical standards, this dialogue opens up an opportunity to examine these trade-offs from a new angle, evaluating their impact and unintended consequences.

Depending on the trade-off, there might be a showdown at this point, and that is an opportunity to clarify and refine. Don't fear the conflict, open to the opportunity.

Ethical acceptance criteria

Acceptance criteria is a critical collaboration area for successful collaboration between development and design, and it is often overlooked as strict technical requirements. Recently, on my team, we instituted visual design

But here's an idea that we can explore: augmenting the product design process by introducing the Belmont principles as a rubric for quality could protect against ethical risks.

I can tell you, I don't know what this would look like. But it's worth a shot. Try starting with some ethical Gherkin language.... GIVEN a user knows they are trying this feature...

Ever forward

I do not think this will improve overnight. Or even in a week. Or a month. And i don't think it will even become a movement. It's only a matter of reaching forward, reaching higher, one project at a time, one company at a time, one designer at a time, one team at a time. I would challenge you and your team to start small, but aim high.

Introduce these principles to your team:

1. Respect people as individuals
2. Provide more benefit than harm
3. Examine any affected population

Start with a critique session. Then another critique. Then another. Push your work and your team's work with higher standards.

Or, start by kicking off a project with a question for stakeholders: are there any unintended consequences that we should keep in mind that may affect a certain population in a negative way?

Try evaluating objectives against longer-term outcomes, looking for potential unintended consequences. For each intended objective outcome, ask "then what?" and "then what?" and "then what?"

But most importantly, don't give up.

When I started my career, and I was in a position whee I needed to compromise my beliefs in order to get and hold a job, I hated hearing people in the profession encourage me to "stick to my guns" and never compromise my beliefs. I thought that was so arrogant, because the pressure I felt to get and hold a job was massive.

So I want to be clear, I don't expect sainthood from professionals, but I do expect quality. And the scope of quality is growing to include an ethical and principled perspective.

Please feel free to reach out to me with your thoughts. This is, and always will be, a work in progress.

###

NOTE: I first heard about the Belmont Report from awesome service designer Sarah Fathallah, in her recent interview in Communication Arts.

Correction: I misstated that the Tuskeekee study participants had been unknowingly infected with syphilis as part of the study. The post has been updated to reflect that 399 of the participants had syphilis, and clarified the nature of the care that was administered during the study. Many thanks to reader Kit Oliynyk for assistance in these corrections.

Engaging the Sales Team for Design Research

 When designing in enterprise and b2b environments, it's tempting to believe that the customers are easy to get to for the purposes of research, feedback, and product development. I mean, our sales and customer support teams talk to them all day!But that's not the case, not by a long shot. Connecting with business customers is an under-appreciated challenge unto itself, even on the best of days. For starters, your customers are business customers. They understand that their time is valuable--because they're being paid to be there! Time is money! And the time and money spent doing their job don't have a vested interested in helping you do your job.On top of that, you probably have people at your company who go by the name of Account Management, Customer Success, or just Sales (which I will collectively refer to as 'sales reps'), and they probably think talking to customers is their exclusive domain. You have to take a minute to appreciate their perspective.Your sales rep probably hasn't worked in the product development process before, so they don't have a reason to believe it would be useful to them or to the customer. If your sales rep thinks bringing you into the mix can jeopardize their relationship with their customers, then it's a no-go.The last thing your sales rep or your customers needs is some nerd from corporate talking tech and design or defending defective design work, wasting everyone's time. Sales reps need a reason to believe this misstep won't happen.I’ve been down this road at a company that works in financial services (talk about a 'time is money' mentality--it's called interest). Our B2B customers were home improvement contractors, who range from small, independent and sometimes un-tech-sophisticated contractors to mid-size contractors who have sometimes-sophisticated operations and even in-house dev teams.For us, engaging the sales team to help with product development took about 18 months, which is not quick. But in that time, we went from from "Why should I let you talk to my accounts?" to "hey, can you talk to one of my accounts? They have some feedback." That was a tectonic shift in perspective and a long, non-linear journey that often felt like two steps forward, one step back.The nuts and bolts of who to talk to when, what meetings and conversations to have, etc, tends to vary from organization to organization. In the meantime, here are a few lessons learned from my experience, grain of salt optional:

Get insight from sales reps themselves

To start, I interviewed a lot of our sales reps as proxy users. Many of our sales reps used to be the kinds of contractors they now service and they were themselves SMEs in the field. I got their attention with pre-release prototypes. From this, I was able to get general (admittedly biased) market discovery. Perhaps more importantly, I showed them that I valued their opinion and experience.

Establish a feedback loop

Early on, my team was always chasing after the sales team, trying to get to customers, and getting nowhere. Then, we learned that the sales team had to write up weekly reports about their portfolio and include any “market color” that they found along the way, which included a ton of valuable input for our product team--even feature-specific suggestions from customers. Our product team had no idea these reports were even happening. Once we got on the distribution list, we were drinking from the firehose. The reports provided good starting points for digging into problems or developing new features, and reaching out to those individual reps.

Close the feedback loop

This is really hard.One of the most frustrating things was demoing a prototype of a new feature, our sales team totally buying into it, and that feature either taking a really long time to get to market or never getting to market. This was a major knock on our credibility and strained the relationship.You have to understand that sales happens in real-time. There are no sprint cycles, or product releases, just relationships that ebb and flow based on current performance and opportunities. As a result, a sales team can be a pretty what-have-you-done-for-me-lately organization.On the other hand, when you do get their feedback, you document that you understand it, you demo an update, and you come back to them with the date it will be in market in a timeline that benefits your customers, you'll be like a conquering hero. "Someone finally listened!" was simultaneously flattering and depressing.

Find the squeaky wheel

One of your sales reps has a customer who is always making suggestions. You need to use your feedback loop to find who that is. That customer will be more likely to find value in spending time with someone from your product team, participating in research, and being heard. Conversely, it’s worth acknowledging for your sales team most of your B2B customers will think time spent with the product team is value they are giving to you.

Commit to being the face of the product

Sales is a face-to-face business. On top of that, many of our sales reps were on call virtually 24/7, taking calls from customers at all hours. When I presented some prototypes of upcoming features at one of our regional sales meetings, I ended with a slide that was only my name, my cell phone number, and my email address. I told them that they can contact me at any time. They never did call, but they sat up and noticed. It connected with them at the time because I was speaking their language and meeting their level of commitment helping them and our customers.As hard as it can be to cross this chasm to get to your customers, you gotta do it. You have to get out there. The sales reps that have close relationships with your customers can be one of your most powerful allies in achieving your goal of greater customer insight. It's a key way to get true feedback from enterprise customers. And it's also critical to helping your internal team understand they they are not the customer. Connecting with your sales team will help you in both the short and long term by gaining valuable insights and growing your relationship with the folks that talk to your customers day in and day out.

The 6-1-1 Sketching Session

What's all this then?

A 6-1-1 is a structured sketching exercise. You may recognize it as a miniature version of a design studio workshop (example) or you may also see that it is very similar to some of the methods popularized through Lean UX and Design Sprints. I developed the 6-1-1 as a lightweight workshop while at LivingSocial in response to two main forces:

• the emergence of Jeff Gothelf and Josh Seiden's work in Lean UX, which I found very influential and was implementing at the office as a practice
• the energetic environment of the company; exciting and creative but sometimes lacking in direction and focus.

When to do a 6-1-1

When you have a problem that you are trying to solve and...

• You are having trouble coming up with solutions
• You are having trouble agreeing on solutions
• You are having trouble focusing on a solution
• You need input on solutions from a diverse group of stakeholders
• You need to get shit done fast
• You need to get a lot of input from a a lot of people and bring focus to that direction as quickly as possible

In any of these cases, or in any combination of these cases, a sketching session can act as a powerful tool for bringing alignment and buy-in within your team and ultimately with the greater cross-functional set of stakeholders involved.

Prep for the session

Write a clear and concise problem statement. The session itself will rely heavily on understanding of a problem. Do the work; research and clarify a problem that you are trying to solve. If you don't have this, the session will crash and burn.There are numerous effective formats and structures for problem statements (user stories, jobs to be done, etc), so use the one that you and your team find effective. Make sure it includes:

• who is affected by the problem
• where and when they encounter the problem
• what the problem is

...but leave it at that, and be very careful not to bias the conversation towards a solution!It's worth pointing out the importance of emphasizing who is affected by the problem. Communicating the affected person, in the form of a persona, is a powerful method for gaining the empathy required for your 6-1-1 participants to put themselves in another person's shoes.Gather the materials. Don't let anyone off the hook because they don't have a pen or a piece of paper. Get everything that will be needed ready in advance.

• Room with whiteboard
• Timer (phone is OK, but something bigger/louder is usually better)
• Pens, pencils, markers, etc.
• 6-up sheets for first round (paper with 6 boxes on it)
• 1-up sheets for the 2nd round (paper with 1 box on it)
• Big post-it pads for the final round

Find a cross-functional group of people. If you only invite design and product people, then you're going to have a bad time. Actually, the session might go really well, but you'll have a bad time when you end up releasing a product that only works for designers and product people. Mix it up. Definitely get people involved who talk to your customers on a regular basis; phone reps, field reps, etc. Get your development team to leave the cubicle behind for a couple hours--BONUS: getting your development team involved now will set a collaborative foundation that will pay off later. Get content people, finance, legal, executives--anyone who has a perspective on the customer experience.Prep the invitation. The invitation is actually pretty important. Since this meeting is a lot more interesting than some boring old status update, there is a chance that people will actually read the invite. So,  it should include:

• An explanation of the sketching session
• The problem statement
• Assurances that they don't have to be great at drawing (more on this in a bit)
• Complete and detailed agenda
• An optimistic tone that shows everyone on the invite that they'r opinion is valuable

Set up an after-party. One the sketching session is done, you will need to meet with leadership to validate if this approach works and outline for them how you want to move forward. I recommend having this very soon after the sketching session.

Example  Meeting Invitation

Here's an example of what to include in the meeting invite:

You are cordially invited to attend a sketching session for our ####TOPIC###. We’re going to run through a 6-1-1 sketching session, ending with our direction for a new prototype.Problem Statement: ####insert problem statement here####A note on sketching: Please remember that this is not a drawing exercise. The objective here is to communicate ideas that could solve the problem. If you can draw a triangle, a square and a circle, then you can draw some representation of every interface that has ever been designed. Finally, Don't be afraid to be unrealistic with your ideas. Our most unrealistic ideas often become our most innovative solutions.

Agenda

Seeion time: 90 minutesDiscuss the problem: 10-15 minutes We'll start by making sure we all have a complete and shared understanding of our problem.Sketching, 6-up: 8 minutesOn a 6-up sheet, sketch 6 ideas that address the problem.Discuss & critique: 5 minutes per personAt this point, everyone in the session shares their ideas. It’s important not to judge any of the ideas at this time in terms of feasibility of even sensibility.All ideas are available to trade and steal.Sketching, 1-up: 5 minutesAfter consolidating (stealing) ideas from each other, each participant creates one sketch that reflects the best approach to address the problem.Discuss & critique: 5 minutes per personAt this point, everyone in the session shares their 1-up ideas.All ideas are fair game: trade and stealSketching, Collaborative 1-up: 15 minutesOne person assumes the role of the draftsman.The team collaborates on a final sketch that represents a single, consolidated approach.Output & next stepsSketches, ready for business validation, for use in creating stories & prototypingparking lot of other ideas

Before the session

• Get in 10-15 minutes early.
• Distribute the materials around the room
• Write your problem statement on the whiteboard.
• Write the rules on the board (more on that in a minute).
• Set out any refreshments you might have brought.
• Get ready to greet everyone with a smile.

Begin the session with rules

Welcome everyone to the session and thank them for their time.Start off with the rules of the session. I like to use the rules to set the tone: fun, a little irreverent, but focused.Rule #1: No job titles. Emphasize that everyone has something to add from their area of expertise. I like to take this opportunity to call out any senior leadership in the room if I have some rapport with them, "Hey, for the next 90 minutes, you're not the CFO, you're not anyone's boss, but you are someone who knows a lot about corporate finance and markets and for that, we need your help."Rule #2: No drawing, only sketching. Sometimes I like to show a picture of some really amazing pencil work like MC Escher, Leonardo Da Vinci, or maybe mix it up with one of those charcoal drawings of Tupac that you get at the boardwalk. Then emphasized that we're not here to draw, we're here to sketch. I like to do something that I heard from Jeff Gotthelf in a LeanUX workshop; I draw a square, a circle, and a triangle on the whiteboard and tell them, "if you can draw something like this, you can draw every computer screen or mobile app that has every existed. Stick figures are OK, even welcome. We're not here to be artists, we're not here to make it beautiful, we're here to solve a problem and communicate with each other."Rule #3: It's OK. If you sketched something and it didn't quite come out the way you wanted--it's OK. If you didn't think of as many ideas as you wanted--it's OK. If someone else at your table is running away with it or is falling short--it's OK. If you feel overwhelmed or confused, ask for help--it's OK. No one is getting graded on their performance, this isn't going to go on your review, just listen, sketch, and relax.

Get to know the problem

Ask someone in the room to read the problem statement off the board and ask them what it means. Then ask, "who else knows about this problem?" Listen and course correct if necessary. Then ask for another perspective from anyone else in the room. Refine the problem statement if necessary. Be ready, just in case, to defend the problem statement without being defensive. Outline for everyone that solving this problem statement is their objective for the day.

Facilitation

As you guide the team through the scheduled exercises, keep time and keep a positive spin on the activity.Sketching, Round 1, 6-up instructions: We're going to start with the worksheet you have in front of you with six boxes on it. Before we start, write your name and the date on the sheet. OK, so, we're going to come up with as many solutions as possible to solve the problem we just talked about. Crazy ideas are welcome! You can work through the same idea more than once because you might kit it from a different angle the 2nd time around. You can imagine unlimited technology and resources and everything works all the time--no limits, nothing is too crazy, nothing is too boring, nothing is impossible. Any questions? 8 minutes. Go.Timer: 8 minutesSharing, round 1: OK, so now that we're brimming with ideas, we're going to share them with each other. But, and this is very important. The only thing we are going to do is share them. We are not going to critique them or offer feedback, but only to share. As you go around the table, each person gets about 5 minutes. While other people are talking, take notes on things you think are a good solution to the problem, you will use these in the next round.Give them about 5 minutes per person. If you hear feedback or critique beyond any reactive "I like that" or "that's interesting" then remind the team to stick to sharing and we can build on the critique in the next round. Sketching, Round 2, 1-up: OK, sounds like we had some great ideas within the group. I saw some great sharing, and heard some great ideas. Next up we're going to use the sheet with one big box on it. Put your name and today's date on it if you haven't already. So, we're going to approach this round a little differently. We talked about our problem (read the problem). We sketched up all kinds of solutions. You took notes on the solutions that you heard and you have your solutions that you came up with. Next, on the sheet with one big box, I want you to sketch the 1 approach that you think would be the best solution to the problem. You can integrate the solutions from other people in the group. All ideas are fair game, so you can steal other people's ideas, remix them, turn them upside down and backwards, and re-imagine it as one solution that you're going to sketch on this sheet. And you're going to do it in under 5 minutes. Any questions? OK, 5 minutes, go!Timer: 5 minutesShare and critique; OK, time's up. Next we're going to share our ideas, but we're going to do things a little differently. We're going to go around the group sharing our solution. I want you to listen for themes that emerge as people share their solutions. What do these solutions have in common? What bubbles up as a good idea within the group? Take some notes of the key themes you hear and write them on your sheet. Go ahead and share, about 3-5 minutes per person.Time box of 3-5 minutes per person. The team shares their work with each other and themes start to emerge. Facilitate the conversation towards capturing themes.Sketching, collaborative: OK, it's time to pull it all together. What were the themes that emerged in your discussion?Someone from the group read the themes, write them on the whiteboard.OK, fantastic. Next, let's elect a draftsman from the group--you take the marker. Now, we'll work collectively on the giant post-it-pad to try to weave these themes together. As we go, we can talk through the themes.

• What stands out as a rock solid must have solution for the person that is described in the problem? For who they are--when and where they are?
• Which ones really make sense for us?
• Which ones stand out as something special, either a competitive advantage or something we do especially well?

Prioritize the themes to make it clearer what's a must-have and start sketching against those themes. Work through the list of themes until the output sketch meets the criteria.Review and critique the final sketch. Thank everyone for their time, creativity and effort!

What now?

Catalog the output. Once there is a final sketch, take pictures of all the sketch worksheets and catalog them all in your resource of choice: team wiki or whatever.Send out a thank-you note. Send everyone involved some sincere thanks and a link to the sketches. Remind them that they're making a valuable contribution as part of the design process.Develop a hypothesis. The design that was revealed in the session is, in and of itself, a hypothesis for solving the problem that you started with. Verbalize this hypothesis.Afterparty and validation. Remember that "after party?" Here's how that's going to work. Set up a presentation for leadership who may or may not have attended:

1. Walk through the problem
2. Outline the structure of the exercise
3. Take a minute to compliment all your participants for their intrepid contributions (this is what makes it an afterparty--the good vibes)
4. Outline the new direction and a hypothesis

Seek their validation and reality check. Is this a direction that you should pursue as an experiment? Is this something that our company does or could potentially do?The output of that meeting may require some refinement to your direction, but you should be in a good position to take the output sketch and push towards a prototype as quickly as possible.If you're cool and you have a mature style guide with prototyping templates ready to go, then hey, good for you. If not, your next step is to pull together something that works for you. The team at Google Ventures emphasizes that a prototype is meant to be a facade for an experience, and this is a good approach. This sketch should set a foundation for that facade; a direction and hypothesis for you team to investigate.I hope this explanation was helpful. I'd be happy to talk about it--don't hesitate to get in touch!

A Sample Design Collaboration Cadence

In order to maintain a decent level of collaboration within a design team, while maintaining a productive pace, and keeping transparent about upcoming roadblocks and needs for solutions, and finding opportunities to support each others in our design practice.... I ended up with a cadence of quick and straightforward cadence of check-ins and working sessions.This assumes that the members of the design team are not embedded solely with individual development teams, but are shared as a committed resource. Individual designers will be dedicated to team-specific meetings like stand-ups, groomings, etc, as necessary, depending on your organizational structure.

• Weekly, 30 min: Team meeting
  • The design team as a whole meets to check in on any news or updates that stem from higher organizational issues and raise any concerns for their own work.
• Bi-Weekly, 30 min: 1:1s for personal development
  • Could be weekly if needed, of course
  • Opportunity for mentorship and management, pursuing opportunities for growth. As a manager, I'm asking these questions:
    • What is going well? 
    • What could be going better?
    • What do you want me to do more?
    • What do you want me to do less?
• Bi-weekly: Team critique sesh
  • Designers take the initiative to set the stage for collaboration on their work through critique or other exercises
• Monthly: 1/2 day: Team boost sharing skills or presentations
  • Opportunity for designers to share more deeply and broadly with the team, showcasing skills, providing training to others, presentations etc.

A Design Practice

Over the course of my career, a framework has started to come into view for a establishing or augmenting a design practice. The framework has three key ingredients:

• Craft: What do you do?
• Infrastructure: What do you use to do it?
• Personal Growth: What are you getting out of it?

Attention to these three areas provides a foundation that is both flexible enough to work in organizations of different sizes and workflows, but clear enough to stay relevant under different methodologies.

Craft

"What do you do exactly?"This is the collection of executional tools we have at our disposal. This includes typical UX activities like card sorts, personas, prototypes, and critique, among others.

• Specific executional methods: typically the work that goes into design deliverables; personas, prototypes, card sorts, sketches, etc. There are dozens of options, appropriate at different stages in of a given design project.
• Participatory workshops: tactical, focused exercises such as kickoff meetings, research interviews, sketching sessions, etc.
• Processes: Executional activities and their resulting output is bundled into a process such as a Design Sprints or Lean UX sprint schedules, which provide a linear path for interactive discovery, design, and validation.
• A commitment to quality: throughout the above practices--and in many ways because of the above practices--there is a sustained commitment to quality. A thorough and focused practice keeps a designer performing at their best.

Infrastructure

"What do you use to do it?"This is typically what we would refer to as design tools; the software, team structure. But this concept goes further to include conceptual infrastructure like design principles that provide thematic support to all the aforementioned methods.

• Organizational infrastructure: team organization through clearly-defined team structure and roles--there's a lot more to this, of course.
• Technical infrastructure: software such as design and prototyping tools, file sharing, communication platforms, all of which facilitate the delivery of good work; also, reusable technical assets associated with style guides, templates, patterns.
• Facilitation infrastructure: provided through the use of meeting agendas and other materials that are re-used in workshops or other sessions--key for healthy engagement with stakeholders
• Thematic infrastructure: tenets such as principles, values, and methodology; tools that guide the team through tough decisions and elevate the team's thinking around solving challenges. Principles are the outcomes we seek in the work we create. Values are describe how we want to work. Methodology is the school of thought that ties together the methods at use on a project.

Personal growth

Everyone on the team is advised to approach every project as an opportunity for personal growth. I have found, historically, that not very many people look at their work this way, as an opportunity for growth. But those who do benefit both personally and professionally."What are you getting out of it?"

• Preferably, this starts with an introspective self-assessment to understand an individual's strengths and weaknesses and understand the need for addressing these opportunities
• Each project should be evaluated as a growth opportunity
• What opportunity do you have to improve your "on-screen" skills, the nuts and bolts of the design process?
• What opportunity can you find to improve your "off-screen" skills, your ability to work with stakeholders through facilitation, active listening, salesmanship, critique?
• Not every project has to be a growth opportunity, but we keep revisiting this as a means of maintaining that trajectory

Putting it in motion

High-quality design methodology, both in process and execution will always be critical to any high-functioning team. An efficient infrastructure liberates the team members from the burden of re-building and wrangling repeatable assets, cuts down on variability and error within the product experience, and removes the cognitive burden associated with smaller design decisions from the team while the work is in flight. But none of this is worth doing if it is not a vehicle for one's personal growth. We spend more of our waking day working than anything else and it should ultimately be a nourishing and rewarding experience.So I'll leave you with a hypothetical example of how a team would carry this through when starting a project.Let's say you start a project with a kickoff meeting (method). In this practice, the team would have a pre-set agenda for a kickoff meeting (infrastructure). The agenda had been tuned over time to assure that three criteria were met:

• Define the problem space and objectives
• Select design methods
• Make a commitment to complete the work

In the kickoff, the team works together to get a sense of what they need to do for the project. They refine and agree on a problem statement (method) and an objective that they aim to meet (method).Next, the team assesses what methods they want to use to reach that objective. Is field research the best way to get the qualitative data we need? Is there existing data from our analytics platform? Is Should we do a sketching session with the team to develop a direction for a prototype? Should we use the Design Sprint methodology for this problem?Finally, there is some assessment of the path forward, an estimation of how long it will take and, based on the needs of the project and the strengths and weaknesses of the people on the team (personal growth), a determination of who should do the work. So, if it's a mobile app project and a associate designer is looking to expand their repertoire with mobile, they could take the project on with a commitment from a senior designer to advise and mentor along the way, helping them ensure that the aligns with the team's values and the work is in line with the team's design principles (infrastructure).Naturally, once the team adopted this perspective, all their dreams were fulfilled!