Introducing Teamwords: The Working Deck

We get asked a lot about problem solving. Not about business problems, per se, but people problems.

People seem to understand OKRs, Agile, and MVPs. Acronyms and abbreviations have specific and fixed definitions you can find on Google — and though you can get into long arguments about whether something is a tool or a process or a disruption at work, people are still, well, people. They change and then they don’t change. They’re heroic and then they’re petty. Confusing and clear, sometimes in the same meeting.

Yes, the pesky things are problems with people. No matter how sleek and refined our company needs to be, how much faster we have to get to market, or how many more hours we must be available night and day to meet the demands of customers, we’re still talking about people at work. They’re the one thing that hasn’t 100% changed about how business gets done.

So companies ask how to create better “cultures of collaboration.” Make teamwork a working norm. Rethink how cross-disciplinary talent can be best configured, how to optimize their working spaces for breakthrough innovation blah blah blah… Again, the same problem of applying jargony buzzwords to people and how they work together. Then upper management wonders why they weren’t very successful in making things better.

Words are powerful. So powerful that most of the problems we encounter are failures of vocabulary. We assume that everyone uses the same words and that they mean the same things to everyone. JIRA means JIRA, right? We see it and recognize it. But, think about the word supportive. How do you see that word in how your team works? How do your coworkers see it in your work? Have you ever sat around with your team and talked about that?

People see their values in behaviors. But when people come together in teams, they usually revert to abstract fluffy words, and leave the specifics for later.

We’re on teams that value transparency or that promise to be adaptable or disciplined, but when we feel like that isn’t happening, we rarely have particular behaviors to point to. We just have a vague feeling that someone’s not being disciplined enough. And You’re not disciplined might not be the best conversation starter at that Tuesday morning meeting. For one, it’s pretty personal. And second, even it weren’t personal, what can you do with that feedback? If someone says you aren’t being disciplined, you have to find the behaviors that go with that word — the indicators that mean disciplined to your teammates. Otherwise, the word on everyone’s mind is misaligned.

New projects come, new clients go, and the new norm is new people on new teams all the time. But the value words are still the same. Which is troubling: Everything is changing, but companies are acting like we can all sit around saying adaptable still means adaptable and that no new behaviors will emerge for us to describe it. And while corporate mandates and mission statements are great, they don’t always influence the day-to-day efforts of real people on real teams.

So, with all of those factors at play, we started thinking about how we could help teams rapidly align themselves, and most importantly, define behaviors that were unique to them. After several months of research and testing, we released a collaboration product called Teamwords: The Working Deck. It’s designed to help teams align themselves whenever they need it. Anyone can pull out the cards, find the value words they need, and list the behaviors they’re looking for from their team members.

Though we created a starting activity that’s included in the deck, we knew that the cards needed to be adaptable. We didn’t want a tool that only got used for, say, that once-a-year team offsite, so we developed a number of different ways to use the cards, both for groups and individuals. During our testing, we uncovered exercises that ranged from funny icebreakers to deep personal explorations. In other words, the deck reflected our philosophy: We turn words into actions every day, and our tools should be able to help us wherever that happens.

Bringing clarity doesn’t necessarily mean bringing rigidity — there will be plenty of new behaviors that a team will want to explore and champion on every project. And that’s fine. At least there’s a starting point. We’ve begun the conversation around what words mean, why they matter, and how we turn them into action.

If you want to reduce team misalignment in the workplace, close the gap between what people say they value and how they actually demonstrate those values. And now we’ve got a way to talk about how we’re going to work together on a team, through all of the strange stages of a project, moving past those buzzwords and unrelatable jargon.

—David and Mary Sherwin

(P.S. You can learn more here about Teamwords: The Working Deck.)

FrieNDA Revised Template v1.26

 

Hello George and Joanna,

I’m looking forward to having brunch with you on Sunday and catching up. It’s been so long since we last talked. Can’t wait!

Just so you know, there were some sensitive things I wanted to discuss as part of our conversation. Would you be so kind as to print and sign this, and bring it with you?

Thanks! And say hi to the kids for me,

—Hollis

P.S. If you have any questions or want to make changes to the attached document, just let me know. I’ll just need to have my lawyer review them.

 

FrieNDA Revised Template v1.26

This Friend Nondisclosure Agreement (this “Agreement”), effective  [month and day], [year] (“Effective Date”), is entered into by and between [insert name] (“Me”) and [insert names], (“Recipients”) (each herein referred to collectively as “Friends”).

In consideration of previous conversations and the conditions contained herein, the Friends hereby agree to the following:

1. Purpose
The Friends wish to discuss issues of mutual interest (“Issues”). In connection with the Issues, Friends have disclosed, or will further disclose certain Confidential and Embarrassing Information that the Friends may wish to forget entirely.

2. Confidential and Embarrassing Information
“Confidential and Embarrassing Information” means any and all information disclosed between Friends, including, but not limited to, any information disclosed prior to the Effective Date of this agreement, either directly or indirectly in writing, orally or by inspection of items that relate to Issues (including, but not limited to, napkin sketches, images, emails, text messages, video and audio recordings, Vines, snaps, animated GIFs, emojis, and so forth), whether designated or not as “Confidential and Embarrassing” at the time of disclosure.

Exceptions. Confidential and Embarrassing Information shall not include information that the Friends (i) had disclosed as a matter of public record (you can’t fake births and deaths); (ii) posted to social media (including snarky comments that received no Likes); (iii) publicly disclosed more than five years ago (Google never forgets).

Compelled Disclosure. If Friends are legally compelled to disclose any Confidential and Embarrassing Information, you have the right to be notified by the Friend first. This right can only be forfeited by death, bike accident, or request to deliver a TED Talk. (TEDx talks do not apply.)

3. Nonuse and Nondisclosure 
Friends shall not use Confidential and Embarrassing Information for any purpose outside of their 1:1 conversations. If Friends are in long-term relationships or partnerships, expect that after each disclosure they will consider said Information and form additional opinions with their partner that they may disclose to you at a later date as “Advice”.

4. Maintenance and Confidentiality  
Friends shall take appropriate measures to protect the secrecy of and avoid disclosure of Confidential and Embarrassing Information. They shall not write down or make copies of that Information. If Confidential and Embarrassing Information is shared that you didn’t anticipate, for whatever reason, all parties agree that (i) if it was shared publicly, it will be immediately deleted (though see Google Exception, Section 2); (ii) they will reach out to those impacted by the Information to reinforce its confidential nature; (iii) they shall not speak of that Information henceforth or use it in a punitive fashion under the guise of providing Advice.

5. No Obligation
Nothing in this Agreement shall obligate Friends to proceed with a conversation. If at a future date both parties agree not to be Friends, this agreement is still enforceable and in full effect.

6. No Warranty
ALL INFORMATION PROVIDED BY FRIENDS IS “AS IS.” SOMETIMES PEOPLE SAY STUPID THINGS AND YOU JUST HAVE TO DEAL WITH IT.

7. Return of Materials
If Friends ask you to give back the items that you have loaned them, immediately do so. If you have lost or destroyed them, replace the items within a reasonable period of time, even if they were disposed of during a cleaning binge triggered by Advice. If said items are irreplaceable, work with Friend to identify what would be appropriate as compensation. Otherwise, you are in breach of this agreement (see Section 10).

8. No Myth
If in discussion of Issues, Friends shared their Personal Thoughts, Feelings, Hopes, Dreams, Aspirations, Insecurities, and/or Vulnerabilities, neither party may claim that their Friendship is stronger as a result.

9. Term
This agreement lasts forever, and will be passed down to any successive generation that Friends may produce, including AI computer agents. Have you seen Transcendence? Initial here: [   ]

10. Remedies
Upon breach of this agreement, all retaliatory actions are allowed. Except for dueling with pistols.

11. Notice
If Friends have been out of touch for at least one year, (i) this agreement is still in full effect, (ii) there is no assumed malice between both parties, and (iii) you have probable cause to remove them from your social networks.

12. Miscellaneous
Amendments to this agreement must be co-signed by both parties, but only after splitting the bill for Sunday brunch.

 

IN WITNESS WHEREOF, Friends have executed this Agreement as of the Effective Date.

 

________________________ 

Signature

 

________________________

Name

 

________________________

Date

 

 

________________________ 

Signature

 

________________________

Name

 

________________________

Date

 

The Most Abused Word in Product Design

Product. That’s the single most abused word in Product Design.

Products are things that are manufactured for sale, and must be purchasable. The buyer will likely have access to it after they’ve paid for it. 

It’s that simple, and that complicated for today's designers. The word Product has become a portmanteau for the following: Physical products, Internet-connected things, consumable packaged goods, software applications, digital services and platforms, real-world services and experiences, and anything else that can be made and sold which won’t fit into the previous categories.

Applying design to a broader range of things we use in the world—that’s often good for both customers and businesses. However, that’s not so good for those who have decided on a whim to update their title on LinkedIn to read Product Designer. It's also not so good for hiring managers who want job titles to have Product in it. We are seeing this play out in weird job titles and job descriptions, probably written by people who don’t realize they’re compounding the issue: 

• Visual Design/Product Design Manager (actually UI Design in Scrum/Agile)
• Senior Product Designer-Visual (also UI Design)
• UX Product Designer (pure UX/UI Design)
• Head of Product Design & Development (Industrial Design and Physical Product Development)

And I just looked at the first scroll of a set of job listings.

It’s appropriate to say that your company makes products, and that you have a VP of Product, and that thing that you sell isn’t an old-fashioned manufactured physical product. The writer of an article I read yesterday in the New Yorker went so far as to call an LED product a “product-as-service” because the word Product didn’t really do justice to something that you would lease. (That was thoughtful.) 

So, here's my advice. Be cautious about saying that if you’re working on anything that can be sold, you’re automagically a Product Designer. Because if you say you’re doing Product Design, you’d better nail the basics. A Product Designer should be adept at identifying customer problems (“jobs”), as well as formulating and testing product assumptions and hypotheses around what solutions will help people achieve those jobs. Whenever possible, this should be happening through well-constructed experiments.

When I see work from a Product Designer and they are not doing the above things—or worse, they are not even aware that these are things that Product Designers are supposed to do—we are creating a new set of problems for design organizations, and a new set of demands that design education needs to snap to attention and fulfill. Product Design may require tools and skills that aren't always emphasized in Industrial Design or Graphic Design or UX Design or Interaction Design or Service Design or any of the other flavors that are in the Skittles grab bag of design education. Since the word Product has been so heavily diluted, a Product Designer may need to exercise skills drawn from any of those disciplines depending on the kinds of customer problems they are trying to solve—plus Product Design basics.

It’s unlikely that we can stop this Product Big Bang. But what we can do is be more precise about what we expect from designers, and designers can be more thoughtful about how they want to represent their skills when working on products.

So, what’s the second most abused word in Product Design?

The Designer’s Bias

A few years ago, I saw a presentation from a creative director about how he helped brand an experimental elementary school. Before he shared his work, he said: “We promoted the school through videos on YouTube. My first job was as a filmmaker, so every time I see a problem, I want to solve it with a film.”

Since then, I’ve heard hundreds of people make the same kind of statement in everyday conversation: “I’m an engineer, so every problem can be solved with software… I’m an architect, so every problem can be solved with a building… I’m a carpenter, so every problem can be solved with a table.”

There’s a bias operating here. Let’s sum it up as: Every problem I encounter can be solved with things I have the training and skills to make.

Biases are neither good nor bad. They simply are. But we need to acknowledge our biases explicitly if we want to create our best work as designers.

There’s good reason for this. Go back to the statement above, about the carpenter. Let’s not treat it as a joke. Let’s play it out.

Give a carpenter a problem, and the solution will probably contain wood, concrete, or other forms of joinery. The tools she has available will be biased towards working with those materials: pencils and levels, hammers and nails, saws and glue. If she’s an apprentice, she’ll shadow other carpenters as they solve problems and craft solutions. If she isn’t capable of solving a problem on her own, she’ll reach out to people that have the appropriate skills to help.

It’s unlikely you are going to ask a carpenter to solve the problem of how to remove kidney stones with a new treatment technology, or create the next big smartphone, or increase the number of conversions for your large-scale e-commerce website. And yet this happens with designers every day.

As human beings, we get into trouble when we don’t notice how our biases influence our decision making. And designers aren’t immune to this. We’re biased towards solutions we have the skills and means to materially create. We’re biased by the tools we have at our disposal. We’re biased by our schooling and our apprenticeships in the working world. We’re biased by the communities of practice we build up around ourselves. And we’ve invited in an additional layer of bias that is unique to design—that applying the design process to problems large and small is a primary way of creating positive change in the world.

I’ve seen these biases crop up in recent work I’ve seen by design students that are fresh to the profession, by designers in professional practice, by design leaders at startups large and small, in speeches by thought leaders and government officials and people in positions of influence. Most disheartening though, was that these designers were surprised when I asked them very basic questions about how they acknowledge their bias as designers.

If we are being strategic about doing design, we bring our bias into the work because it’s what needed to look at things from a different perspective. But we have to call out what those biases are, both in how we see the world and in the work itself. We need our collaborators to help us acknowledge our biases as designers. In return, we can acknowledge theirs, and build on that understanding to make better decisions.

Designers may be well suited to facilitate the necessary problem-solving work with teams, but we aren’t the only people capable of doing it. Designers don’t “own” problem solving. We make a set of tools available that people can bring to bear on problems, if they know how to use them. Besides, not every problem can be solved by design alone. In fact, if you’re going to try and influence a really big problem, you need more than just design skills. In our work with collaborators from other disciplines, we need to be doing a better job of leveraging this truth.

Otherwise, we will be living our own joke: “I’m a designer, so every problem can be solved with design… Every problem can be solved with a thing that can be designed… Every problem can be solved via the design process… Wait, exactly what problem are we trying to solve?”

"Making Models: R&D in the Social Sector" in frog's Design Mind

This week, I published an excerpt from my dialogue with Renuka Kher from the new book LEAP Dialogues: Career Pathways for Design in Social Innovation in frog’s Design Mind magazine. You can read the excerpt here.

I’ve collaborated with Renuka on multiple initiatives between Tipping Point Community and global design and strategy firm frog, including T Lab. T Lab is a six-month long program that brings together nine Problem Solvers to design and test new solutions to help with pressing social issues in the Bay Area, such as access to child care, availability of early education, and support for people recently released from prison.

In this excerpt from our dialogue, we answer questions such as:

• What should R&D should look like for nonprofits or nongovernmental organizations seeking to create new social services?
• How should funders approach the notion of “risk” when investing in social impact work?
• What skills should designers have to successfully participate in social impact work?
• What kind of time commitment should a designer make when working with a nonprofit client or a community group?

The book is beautifully edited, designed, and printed—you can learn more about it here and get it on Amazon.com.

Challenge: Sounds Like a Story

 

For three years, I taught a class at California College of the Arts' BFA in Interaction Design program about the use of story in product design. For the first half of the semester, sophomores created a wide variety of stories as art in physical and digital media. For the second half of the semester, they would then create the same types of stories in the context of design problems. The challenges we used in the class and as homework were in the style of what you’d find in Creative Workshop, but focused on stories as the material output. As an example: Students would get comfortable making sequential art, then use the same tools to generate product scenario storyboards. They would create hypertext fiction with a series of random story prompts, then use the same medium and tools to help shape a design research readout.

In the process of creating the class, there were many story-based challenges that we couldn’t fit in. This was one of my favorites. Please do let me know if you try it, and are interested in sharing the output!

 

Sounds Like a Story
Time limit: 2 hours
Tools: Audio recorder, sound and/or video editing software

Challenge:

Go out into the world and quickly collect a set of non-verbal sounds with an audio recorder. In a sound or video editing program, arrange those sounds into a 60-second audio segment that you believe a listener will respond to as a story. Write out on a sheet of paper what you believe the story is trying to express. Find someone to listen to your audio segment, give them a separate sheet of paper, and ask them to write out what they think they’ve heard. See if the listener will write out a story as a result of listening to the audio segment, and if the details of their story resemble yours. 

Take it further:

Instead of making your own recording, start your work with a recording from an online archive of royalty-free audio. Try to limit yourself to just one or two audio files, and work quickly—it's easy to get immersed in the editing process.

 

Need some inspiration to get you started? Check out the podcast The World According to Sound by Chris Hoff and Sam Harnett, where they create 90-second sound collages that will stretch your brain.

 

The above image is from Public Domain Pictures and available here.

Handmade Illusions

Consider this thought experiment: I give you two books. One of them looks like it was produced by selecting photographs on your hard drive and publishing a hardcover book through Apple. If you had created it, you would have spent about ten minutes putting it together in iPhoto. In the other book, it looks like the photographs have been hand-printed on archival paper via a giclee printer and mounted into a hand-stitched hardback book, with a few alignment errors and flaws. 

Which book would you rather have? Why?

Now, imagine that there are 5 copies of the Apple-produced book, and 200,000 copies of the one that appears to be hand-printed. Which one would you rather have? Why?

I wonder what new platforms will emerge to exploit perception of handicraft, and what new technologies will enable them.

One of my favorite pictures we own is from 20x200. (The above image by Todd McClellan.) Their platform does an excellent job of balancing limited editions with affordable access to art, though by “limited” we are talking about a few thousand prints. 

But if an artist wants to reach the largest possible audience with their work, they will pursue multiple routes with the same work. Hence, the photographer also sells a hardcover book with the same photographs for $20.23.

I like this print better on my wall than in a book on my coffee table. But I wonder what stories I would tell myself if the photographer had printed it for me by hand.

What Is Hard to Discover

When reading The Information by James Gleick, the following quote from Charles H. Bennett leapt out at me: “The more subtle something is, the harder it is to discover.”

So many ways to read that statement. 

I am bullish on the Internet, but one of my fears is that decades from now, art forms that trade in subtlety will become like the Cook Islands. Few people will have heard of the place. Very few people will live there. The tourist trade will not be brisk.

There have never been so many ways to take an idea and broadcast it to the universe writ large. And yet the more subtle your idea, the higher the risk that it will be disregarded until someone invests the attention to discern it—no matter how many eyeballs might consume that idea. 

I just re-read a novel whose ideas took me fifteen years to grok, in terms of the layering and subtlety. My mind was blown as a result. I had to give it my due attention for days. Again.

What algorithms will reward this type of re-reengagement? Will Amazon really tell me to go back and read again that book I bought in 2006, because it thinks I’ll find it more enriching today?

Data Doesn’t Tell Stories, People Do

Many years ago, I was interviewing a portfolio manager about how he uses financial information. He said something that has resonated with me to this day: “Every number that I include in my quarterly reports to clients has a story behind it. I won’t meet with my clients until I know what that story is—no matter whether it’s good or bad about their portfolio’s performance. Otherwise, they’re going to bring their own story to it.”

It’s a common error of judgment for designers to assume they know what stories will be told from data. We create donut charts and graphs and tables and many other sorts of data visualization that are meant to communicate particular meanings. 

But data doesn’t tell stories. People do. 

Ask yourself: “What stories do you think people will bring to the data?” Take your designs with real data in place—if legally allowable—and see if the story in your head and the story that your users tell you are the same. 

You’ll always be surprised at what you discover.

Bespoke Ubering and Old-School Blogging

We were having a snack with our friends Penny and Dan before they went to a show in downtown Oakland. Our car was around the corner, and we offered them a ride to the concert. “It’s okay,” Penny said. “We don’t want to be a bother. We’ll just take an Uber.” Mary insisted on giving them a ride, so we walked back to our apartment to get our car. When Penny got in, she said: “Thanks so much for the bespoke Ubering.”

I feel this way about the economizing of blogs. I said a while back on The Twitters that blogging had become like the community farmer’s market, while the Mediums and Pulses of the world were the supermarkets. Most people/authors gain huge benefits from their participation in platforms versus old school blogging or (god forbid) writing an article for a print publication. The tradeoff, however, is hidden in the fine print: The content can be leveraged in relationship to syndication, advertising, and other forms of monetization that are outside the author’s means of control. Few of those things matter until you want to do something with your content other than retweet it. Perhaps we will only have our organic free-range blogs distributed at Walmart.com.

That may not matter to you. The Internet exists to copy information, yours and mine included. But we are still limited to those shapes and forms by which our copies transition from physical to digital mediums. Some are classical in form, some are just down the street.

When I look at Tumblr, I see a new incarnation of the florilegium. When I look at Nextdoor, I see the coffee shop bulletin board with its passive-aggressive notes back and forth about who left the king-sized mattress on the street corner. When I look at old-school blogs, I see the brightly colored community newspapers you pick up at the grocery store when you’re heading for the exit. (Just without the eye-piercing ads for local plumbers and medical marijuana distributors.) They sit in the bright green rack next to those large candy machines that dispense gobstoppers for 25 cents. You leaf through them, and something catches your eye that you wouldn’t have learned any other way. If it’s relevant, you pass it along to someone else. If it’s not, there’s a convenient recycling bin in the corner, which you can hit up before you catch a Lyft to your next appointment.

I'll Be Brief

When I was a baby, I didn’t start speaking until I was over two years old. When I started talking, it was in complete sentences.

For me, writing has always been a way of feeling out what’s complex or hard to understand. When writing things down, I often feel like I need to get out a complete thought—even if that means going to a level of systematic depth that the communication may not require. 

While this habit may be rewarded for the creation of design documentation or books, it doesn’t always lend itself to open dialogue and public discourse. Blaise Pascal once said in one of his letters to a friend: “I have made this longer than usual because I have not had time to make it shorter.” No mathematician worth their salt would circulate their ideas until they could express them in their most elegant, defensible form. 

Right now, I’m most interested in writing short forms, and how they add up to dialogues where ideas can riff and play off each other in rapid, improvisational fashion. I find myself admiring the required restraint in this call and response. While short forms of writing don’t always result in a concise QED, they do offer trailheads to other vistas you can explore on your own power.

This is the terrain we traverse today. Many of us spend our days conversing in Facebook posts and tweets and instant messages and texts and Slack and so forth—but how good are we really at that as writers? In our craft?

If you’re doing it right, you know based on how other people respond to the words. Not in a creepy, Lexicon sort of way, where poets can make you do whatever they want—in their tone and mood.

Nineteen years ago, I remember editing an interview by a famous writer, where he said that he wanted to be capable of shifting your emotional state while reading one his stories based on how you transitioned from one syllable to another in a single word. At the time, I thought he was crazy. A paragraph or a sentence, sure. But in the middle of a word?

Now, I’m not so sure. There are so many pieces of writing we encounter today where reading only a few words will start your blood boiling, and there’s a tiny input box beckoning to you for a response.

How Project Teams Actually Work: Six Insights to Help You Create Better Workplace Teams

Congratulations. You’re now in charge of a project team that’s kicking off in a few days. Your boss sends you an email that ends with: “Let me know if you want some advice when the team starts Storming.”

Why the capital “S” in that email for “Storming”? A few Internet searches later, you’re buried in a pile of Wikipedia entries, recent articles from the New York Times, and academic books talking about how groups develop over time. In your reading, you find that way back in 1965, psychologist and professor Bruce Tuckman proposed a theory that shapes how many of today’s businesses approach team building. You’ve heard some of these terms come up before at work, but they didn’t make much sense at the time: Form. Storm. Norm. Perform.*

This. Is. Awesome. His work really resonates with you. Now you have better perspective on what you’ve experienced before when you were working on project teams. And now as a team leader, you’ll do your best to help coach your team through the challenging Storminess to as much Performance as possible. Onwards to the project kickoff!

Whoa. Not so fast there.

Tuckman’s theory is catchy and easy to explain to people. His different group stages capture an essential quality about how we label group behavior, often in retrospect. All of us have told stories about when our team was “Storming” or “Performing” in a water-cooler conversation or over a late-night beer. Tuckman’s group stages have gained enough cultural currency that we’ve done little to question their validity and how his theory applies to workplace teams. (Ourselves included, and we teach this stuff.)

But Tuckman clearly stated when putting forth his theory that there was no empirical data to support it. His work was derived from studies of therapy groups, HR training groups, and laboratory groups, not business or classroom environments where people are actively working together in teams to solve problems as part of a larger organization. Few studies were conducted with the intent of validating it rigorously. We had to go back and read everything Tuckman wrote about his theory to get a handle on this detail, and then we had to dig into the literature that followed his to see if anyone else had empirical proof that his framework… well… worked.

It wasn’t until almost 30 years had passed that Pamela Knight at Defense Acquisition University (DAU) attempted to validate Tuckman’s ideas and see if they applied to project-based teams at her school.

Knight tracked the efforts of small, short duration technical teams composed of 4 to 8 team members. The teams worked together on projects at DAU over a short duration, no more than 40 interactive hours during a single month. These university attendees had substantial workplace experience and came from multiple government agencies, often collaborating with other companies to solve major challenges. Though these teams were in a classroom, Knight argued that their behavior was more like that of work teams “because [their] assigned tasks… emulate real-world problems that the team members are asked to solve in a work team environment within their own organizations.” Teams were presented with complex problems, requiring both analytic and creative effort from the cross-disciplinary members: conducting requirements analyses for missile systems, preparing for and conducting contract negotiations against other teams, creating case studies and estimates for weapon systems, and so forth. Not easy stuff.

Knight discovered that these types of project-based groups do not work in the same way as Tuckman’s theory. Her findings also diverge from what we’ve seen in articles across the Internet, where Tuckman’s group stages are described as events that a team may complete and then move onward from without revisiting them. Unlike Tuckman’s model of teams moving through explicit stages, the teams at her school shifted dynamically between Norming, Performing, and Storming after they were Formed.** We like to visualize it like this:

From our experience working on and leading hundreds of project-based teams, we are inclined to agree with Knight’s DAU model as being applicable for workplace teams. As a result, we’ve changed our approach to teaching team building to include the following insights from her research:

1. Forming is a critical first step for starting a project team. The first interactions you have with your new team are the most important ones. In fact, if you don’t plan out how you work with your team in the first few hours you’re together, you may have missed the best opportunity to make the team successful. You will not be able to return back to this Forming step. The attitudes and behavioral patterns of your team members are set at the start, and they can be hard to change afterwards.

2. Forming requires paying attention to both what you’re trying to accomplish as a group and how you want to relate to each other as a group. When starting a project team, focus your attention first on understanding your co-workers separate of work tasks. What do they want to accomplish in life, and how does this project relate to their personal and professional goals? Make sure you give each team member equal time and space to share.

3. As part of Forming a team, everyone will need to be aware that Storming is a leading indicator of team performance, not an undesirable behavior to be rooted out. Knight saw in her research that “a team that Storms much more than usual is not an indicator of below average performance. In fact, the percentage of Storming decreases as team performance decreases.” Or, to put it another way: If your team is avoiding dialogue about issues both large and small, then performance is likely to suffer. Team members need to be able to share what they’re thinking, even when the sharing points directly to Storming.

4. Storming and Norming should not be labeled as a negative or positive phase of your team’s behavior. While Performing is often considered an “ideal state,” Storming or Norming are necessary at key times to advance the team’s efforts. We tend to think of Storming as a negative or undesirable behavior. However, Knight reframes it as a balance of both “cooperatively challenging, reevaluating, and improving the overall team process as they work together to accomplish the task they were given” as well as interpersonal conflict, friction, or hostility independent of task activity. You may need to signal or trigger events and label them as Norming, Storming, or Performing behaviors, rather than to say that a team is in a Norming stage or a Performing stage.

5. Storming events will happen while the team believes they are Norming or Performing. Storming isn’t a phase that your team passes through and then sails on through calm and balmy waters. Try to label events as Storming and work with your team to help them reflect on why there is conflict and what impact it is having on team members and the overall project. Allow the team to develop vocabulary to describe both productive and destructive Storming behaviors.

6. Storming may not always be visible to team leaders. Storming behavior—whether negative or positive—may happen less frequently if a manager is present or participating in team work, compared to other types of group interaction. “Cooperative professionalism is encouraged while emotive conflict, resistance, friction, and hostility are often discouraged when a neutral authority with significant power (the instructor or the boss) is observing the process,” says Knight. If you’re managing the team, continue to talk with your teammates individually to understand if there is unproductive Storming behavior occurring that needs to be addressed. You should encourage team members to avoid triangulating issues, and directly address Storming behaviors with members of the team. This can help build trust between team members.

Do these insights resonate with your experience? Do you have wisdom or additional research to share about what leads to high-performance workplace teams? We’d love to hear your stories regarding what’s worked best for you on your projects, no matter what industry you work in.

—David and Mary Sherwin (a.k.a. The Sherwins)

 

Footnotes

* In case you don’t know much about Tuckman’s theory, he splits the activity of groups into two realms: group structure, which focuses on how people relate to each other personally separate of their shared tasks; and task activity, which is about how people interact with each other regarding accomplishing tasks. Group-structure activities and task-oriented activities can happen on their own or simultaneously. The stages of group behavior often get visualized like this.

** If you want better indicators regarding whether your team is Storming, Norming, or Performing, these are indicators derived from the Diane Miller Group Process Questionnaire which were used by Knight to acquire data for the DAU model:

Forming: At 0–25% of project timeline

• The team attempted to discover what was to be accomplished.
• Individuals tried to determine what was to be accomplished.
• The team tried to determine the parameters of the task.

Norming: At 40% of project timeline, switching back and forth with Performing

• Individuals identified with the group.
• Group norms were developed.
• The team felt like it had become a functioning unit.
• Group cohesion had developed.

Performing: At 45% of project timeline. switching back and forth with Norming

• Solutions were found which solved the problem.
• A unified group approach was applied to the task.
• Constructive attempts were made to resolve project issues.
• Problem solving was a key concern.

Storming: Happens throughout the project timeline through discrete events

• There was conflict between group members.
• Individuals demonstrated resistance towards the demands of the task.
• The group was experiencing some friction.
• Group members became hostile towards one another.

"Following the Green" Presentation on Design Business with David Conrad

Interested in starting your own design business, but don't know how to do the "business" part? This comprehensive presentation covers how design studios make money, the ways design studios organize themselves to support making money, considerations for managing your studio's finances, and a method for creating your own studio operating model. Many of the tools and perspectives in this presentation were identified in collaboration with Design Commission, a successful design business headquartered in Seattle, Washington.

I delivered this presentation with David Conrad, Studio Manager and Co-Owner of Design Commission, as part of AIGA Seattle's "Design Business for Breakfast" series. Much of the information here was then included in my book Success by Design: The Essential Business Reference for Designers.

You can view the presentation on SlideShare and download the associated Excel spreadsheets here. Enjoy and may your business be successful!

Removed from the Image

Light knifed across the stark grey ceiling. Pain curled in my gut. Sweaty salty upper lip. Knees pulled to my chest. Slitted curtain. Slipping into and out of lucid dreams: Late summer bright suits and sundresses. Grass blades tickling my back. Fighting for a share of blanket on the hilltop. Birds formed a wheel overhead. When I shut my eyes, my body shook itself awake.

*

Stepping off the bus after a bracing three hour ride from Barcelona to Cadaqués, I sit on a dirty bench waiting for a woman to meet me with the apartment keys. The afternoon sun hammered down. Behind me, tourists wandered up and down the narrow streets. The dark blue harbor was littered with white buoys and fishing boats. Children played on the rock beach with their families, splashing among the rocks in sandals and colorful swimsuits. I fished my camera out of my backpack, took a photograph.

What wasn't visible in the picture was a stiff, unceasing wind. Over that hour, it continually kicked dust up into our faces. My eyes itched and watered. I shut my eyes, replaying the winding path through the cliffs to this cove.

From the depths of memory, I was reminded of a passage in Gabriel García Márquez's story "Tramontana," where he and his family hide in their Cadaqués house from the tramontana, "a harsh, tenacious land wind that carries in it the seeds of madness, according to the natives and certain writers who have learned their lesson." At one point in the short story, the narrator decides to take his children out after many days of wind to see the harbor because "the weather still had an unrepeatable beauty, with its golden sun and undaunted sky… [until] at last, we were convinced that the only rational course of action was to remain in the house until God willed otherwise. And no one had the slightest idea when that would be."

The day after I arrived, there was a torrential rainstorm. I stood for hours beneath the eaves of a garage, listening to the thunder, stepping into and out of the deluge. Slate stairways became swollen tributaries feeding the Med. Having fled the never-ending California drought, I smiled and smiled.

*

The room tipped back and forth. Tired. Hungry. Groping for the bedside table. Water and sleep and water and candy. I am proof you can survive on a single package of gummy bears. I proved this by sucking on each bear individually until it collapsed into a puddle on my tongue.

*

This week, I planned to wander the Costa Brava. For a few days, I would wander downtown Cadaqués and spend my time on the rock beaches, working on my tan and finishing the first book in the Song of Ice and Fire sequence. Mid-week, I was going to hike the four miles up into Cap de Creus Park, packing in water, bread, and cheese. Hike my way up dry scrub-scarred cliffs. Trace the footsteps of Éluard and Hemingway and Márquez through olive groves. Meander slate-paved zigzag streets. Drink silty red wine tapped from a cask in the corner of a sleepy cafe. In the margins, I would meditate and write. I had a list of topics prepared months in advance, for this time away from work and everyday life. I had put off writing about these subjects. I thought they needed uninterrupted attention. Fear, addiction, failure, depression, loneliness, anxiety. The things people confront daily, yet rarely face head on.

The streets of the city were impossibly pictureseque. Even recently constructed apartment buildings had a precise geometry, no matter which way you looked at them. Green slice of lawn, punctuated by a football. Two scooters angled in by symmetric slate staircases. Rowboat resting under gnarled trees. Wet pastel shirts flapping on a clothesline strung outside the forest.

*

Book slap on the tile floor when it fell out of my hands, waking me. Fished the book off the floor. Thought I finished the second paragraph this night. Nine in the morning? Twenty-one in the evening?

*

On my second day, I hiked over to Port Lligat, north of the city center, where there is a clear view of Dalí's house. You could see how much work he had done over 40 years with the architecture, the interior design, and the overall decoration of the property, shaping it all to his artistic whims and routines.

Dalí set up a mirror in his bedroom in a particular location by the window, so when the sun came over the horizon at dawn, its first rays would shine in his face and wake him. He would go paint for hours while his wife slept in her own separate bed on the other side of the room.

*

I fingered the blister packs of medication, Braille lettering raised on a blue serifed box. Spent five minutes contemplating a miniature piece of toast. Didn’t know they sold these pre-made in plastic trays, forty for a euro. No idea how they stay fresh on the shelf.

Taking a bite. Willing the food to stay down. Washing it down with water from a 1.5 liter plastic water bottle. Half a dozen empty on the counter. Admiring the form of them for an hour. Each bottle fitting perfectly in my hand. When drained, almost no energy required to collapse them. Water we have little choice but to drink, bubbling through sand from an unknown source, immortalized on a colorful bottle sold for 79 centos.

*

Brief Skype conversations with my wife. The connection was just good enough for voice, sometimes a little video if we were lucky. We’ve been married for over fourteen years. We would be apart for two full weeks. She was a thousand miles away, in Lithuania, on a writing fellowship.

There was the echoing laughter of families during the siesta, heading off to nap away the heat of the afternoon. I ate ceviche and omelette and drank Amaro during late night dinners. Watched a man paint in his studio, the canvas looking like a video game celebrating what the Olympics might look like two hundred years in the future. Caught the scent of petrol from mopeds buzzing their way up slender alleys. Walked the streets at midnight, placing my hands on the rough white walls of buildings, feeling their stored heat.

Dusk cycled into darkness as I dragged a white lawn chair into the darkness of the back porch to read fantasy and eat dried apricots. Mosquitos fluttered around my ears. Turned up the volume on the crickets. The wind blew unceasingly against the apartment building, but in the courtyard, I was shielded from the chill.

*

The pharmacy was five blocks away. It took me half an hour yesterday to walk there. Wrote the symptoms out. I should start by listing the symptoms and I should go back. This blurry language bled out of my head when I was sixteen. Maybe they are still open. There are no words on the red paper I am writing with the ballpoint pen its cap still on. The medicine isn't working. Maybe I should take more. I couldn’t explain the symptoms. My Spanish was broken. I don't know Catalan. Google Translate you don't know what to say.

*

I was doing an excellent job of avoiding writing, so I decided to take another walk with my camera. Wandering through a church graveyard about ten minutes from the city center, I saw immensely detailed tile illustrations, celebrating activities that the person loved doing before they died. I study each one intently: boating, gardening, spending time with family.

I carry a small beat-up journal when I travel. I've had this one for over two years. I use it to record my attachments, things that I realize when I'm reflecting on everyday life. Only one statement can appear per page, written in big block letters. I can only read a few pages in the journal before I am overwhelmed.

Lying in bed that evening, after cooking myself a bachelor's pot of rice and vegetables, I read the entries from front to back. All I could hear was the echo of the words as I took them in, the feelings they stirred up.

"I am attached to being cared for as the best way to prove that I am loved. I don’t consider what I do for myself as being valuable and caring for myself."

"I am attached to worrying. :)"

"I measure my self worth based on newly considered things, rather than living with any one thing until I discover I will never fully know it."

You can't live in a feeling forever, inhabit it like a home that you left long ago or hope to reconstruct it from sticks and glue when you see it falling into disrepair. When two sound waves are in a particular phase with each other, they cancel each other out. Both of them had to come from somewhere.

*

I think I'm getting better. I remember eating. On Skype with Mary. Debating whether or not she should fly here to help me if I can't travel back.

I've had it worse. In my early thirties I lost ten pounds off an already thin frame due to an infection. In this case, I was bedridden, smelly, not caring about my personhood, not caring about the plan or the quick epiphany or the last dog days of vacation where the sun glimmered above the patio while people ate tapas and bread dredged in salt and olive oil, pacing rooftop decks before returning to their lives that were always there in front of them, every detail not tentative. What would happen in two hours, let alone two days. I can't imagine moving five feet let alone the thousands of miles.

*

Late afternoon siesta, but I can't sleep. Staring at the blank page of the ceiling, I will myself into a swimsuit and walk to the closest beach. Shucking off my sandals, I slosh my way into the water, rainbow-slicked with oil and seaweed. Taking a deep breath, I plunge under the chilly water. Push my way out past the barrier. When I come up for air, the wind tousles my hair. It isn't until a few hours later, after eating a plate of pasta and sauce, that I begin to feel weak, curl up under a blanket under my couch, and vanish.

*

On a red park bench outside the church halfway to Port Lligat. Can't stand yet. Morning heat already rising. Clutching a water bottle in one hand and my stomach with the other. Another half mile to reach Dalí's house. Still not well, but feeling the edge of better. Breathless. Maybe I'd get there today. Maybe not.

Scrolling through photos on my camera. Almost all taken before I was ill. Sculpture. Painter. Courtyard. Sea. Tomb.

I stare up into the tree above me as it shifted in the wind. Clouds: patterns forming and reforming themselves. This world I had no control over.

Márquez: "At the end of two days we had the impresssion that the fearful wind was not a natural phenomenon but a personal affront aimed by someone at us, and us alone… But it must have been something like the dark before the dawn, because after midnight we all awoke at the same time, overwhelmed by an absolute stillness that could only be the silence of death. Not a leaf moved on the trees that faced the mountain. And so we went out to the street… and relished the predawn sky with all its stars shining, and the phosphorescent sea."

I put the camera aside. Shutting my eyes. Why isn't this enough.

 

Stones on Wood

The toddler in the snowsuit slipped on a rock and slid into the burbling stream. His mother pointed at him, laughing to her two friends standing beside her. I thought: I’ve never seen that happen in an art museum.

We were inside the first room of Olafur Eliasson’s Riverbed, which was on display at the Louisiana Museum of Modern Art outside Copenhagen. It was part of a series of situational artworks where natural landscapes were partially recreated within the environment of a gallery space. The year before, Mary and I had seen Lava Rocks at a museum in Aalborg, where we had to don a pair of museum-provided Crocs and gingerly step our way through a giant white room full of sharp red lava rocks. The combination of the crunch-crunch-crunch sound and light streaming in from the windows above made for a static non-terrestrial landscape, as if it were Mars from the legs down, while from the waist up we were within the environs of a hospital.

But while Lava Rocks’s primary modes of engagement required us to stay focused on keeping upright as we explored the various terrain in the room—lest we injure ourselves—Riverbed was set up in a slightly different way. First, the artwork moved through a series of rooms, and the floor was graded as if you were hiking your way up a hill bank to find the source of water. You could duck through short doorways to move in and out of the rooms, as if the gallery environment itself had been reshaped by the natural material. You climb a staircase that has been overtaken partially by a trickling waterfall. In most rooms, the only sound you could hear was the rushing of the water downhill, which was so pristine I found myself searching the walls and ceiling to see if there were speakers piping it inside. The only thing the exhibit required of us, other than the ability to walk, was to cross the stream in order to view every room.

What struck me most about this work was what it lacked. In Lava Rocks, I found myself considering how the rocks were birthed from fire and cooled into these shapes, and imagining myself in those environments. In a similar fashion, when experiencing Riverbed I found myself considering what you might find exploring a local stream: wind, sunlight, dirt, animals, insects, birds, plants, trees, lichens, fungus, worms, and all else that animates our natural world. All that was left here were the water and the rocks, and the sense impressions that they would leave us as we ground our way up the sloping room, with an inkling of what we would find at the start of the stream: the end of the work, and the beginning of your recollection of the experience. 

I found this re-creation of nature both constrained and expansive. I call the work constrained because the interplay between the gallery space and the raw materials (rocks, water) was intelligently assembled to evoke a few physical and sensory interactions—Eliasson meant for the destabilizing nature of the rocks against shoes, for example. But I call the work expansive to speak to the almost unlimited vocabulary of things people can and will do, based on how the environment was constructed. I couldn’t help but wonder how much thought had been put into the arrangement of natural materials as to how it could inspire these interactions, which rarely happen in an art exhibit. In just a few minutes observing those at the exhibit, I saw:

• One man determinedly walking to the source of the water, as if truly hiking
• A group of children running from room to room, being pursued by a parent
• A young man filming the flowing water with his smartphone
• Three men standing around having a conversation in a lower room, as if out for a smoke break
• An elderly woman sitting down on a big rock to have her picture taken, like on a mountaintop
• A girl filming her friend crawling through one of the low doorways, then leaping into the air to celebrate

In an interview, Eliasson talked about how he would watch these people, and then try to literally recreate their movements, “so I can see what I have lost.” His perspective is that he can only control so much of someone else’s experience—and that the whole notion of him dictating an artistic experience is flawed:

“The interaction we have with our surroundings is actually a cultural construct. The way we engage with the world is based on our model, not on truth… What I also present you with is not real. It’s stones on wood. So I’m not trying to say I’m trying to show you the real thing. We are living in models and that it is always how it is and how it has always been… What is real is the way that you choose to handle your own model…

We don’t take in the exhibition, we produce it by walking through it. That is to suggest that the authorship of reality lays within the beholder, the user, the museum visitor. The museum is constituted by the visitors… [That’s why] we should trust the visitor to take the authorship, to become creators.” (transcribed from a video interview associated with the exhibition)

In this case, the child who was producing the exhibit alongside me was starting to cry, as he had gotten wet and the water was chillier than anticipated. His mother swooped him up off his feet, as six more children in a school group bounded past, giggling with excitement. In a world where so much contemporary art places demands on you to sense something quite particular or precious, it’s refreshing to spend so much time in an artistic experience where you are able to shape your journey so explicitly.

Designing for Positive Behaviors and Habits

At sunset, the lingering light painted a neon red line above rolling hills. As I drove north on Highway 101 at 70 miles per hour, the landscape scrolled in parallax, the road receding into night. Up ahead, I could see a white car moving much slower than the speed limit, drifting from the righthand lane into mine. In moments, I would either be passing this car, or it would be crashing into me.

So what did I do? I honked right before I was about to pass. And as I motored past, I quickly glanced over my shoulder to see why this driver was behaving so erratically. The driver’s face was illuminated by the blue-bright glow of her phone in her left hand.

What would possess someone to take this safety risk? Think about how you first learned to drive a car. Maybe you sat in a classroom, listened to lectures, took tests and read manuals. Then you sat inside a car with an instructor, and you stop-start-stopped your way through the obstacle course/parking lot. If you took driver’s ed in school like I did, you may have had a practice car with dual controls, and the teacher would brake for you if you were about to take out yet another orange cone. With the right nudges and active guidance over time, you were able make your way through the obstacle course, drive a few miles in white-knuckled terror on the freeway and maybe even parallel park.

Now flash forward a few years. You’re late to work, so you grab your mug from the coffee maker and run to the garage. Tossing back a big gulp, you back out while pulling on your safety belt, managing the steering wheel with your left leg without thinking while you’re trying to Bluetooth sync your phone to the car stereo so you can listen to a podcast. What was once a hard fought-skill had become an autonomous behavior, which was now layered on top of many other behaviors, often in direct conflict with each other.

Human beings are pattern-making machines. From our first moments in this world until we die, we manifest particular actions in reaction to some form of stimulus or trigger. Sometimes this happens with conscious intent, but much of the time it isn’t.

As interaction designers creating software that can be used at any time in any place, we’re seeing that our products are more tightly wedded to people’s daily behavior than we might have anticipated. Through what we design, we aren’t just creating new capabilities and capacities for people to achieve what they want to accomplish. We are also encouraging new, unintentional habits and patterns of behavior that can have long-term, sustained effects. And few of us have had the formal training to do this in a responsible way.

It’s only the past few years that dialogue about this topic has become common across the product and service design community. Just off the top of my head, I’m thinking of B.J. Fogg at Stanford for his critical research into behavior design and for his instruction of multiple generations of product designers on how to approach this topic and Stephen Anderson for his cataloguing and evangelism of the use of persuasive design techniques. Then we’ve got Chris Nodder’s work showing us the “evil” persuasive techniques that companies use and the work of Nir Eyal, who boiled down all of the above plus many other resources into a digestible book and practice-focused model.

There are many more books, articles, videos, and research in the wild about habit formation, persuasive design and so forth. Some are good, and many of them are great. These people have been researching this topic for a very long time, and there’s a lot to gain from their effort.

In my work as a product and service designer, I’ve had a chance to try out the different methods and techniques that they propose. What I’ve found is that while they have helped my teams think through the mechanics of individual interactions as part of a product, there aren’t a lot of good tools that help with big-picture thinking about what constitutes positive behavior change, and how to collaborate with your users in responsible ways to design appropriate solutions.

In the above talk from HOW Interactive Design Conference, I answered two questions I’ve heard over the past few years from many designers:

• How can I work as an interactive designer creating products and services that make people’s lives better?
• Where should I start if I want to make a product for positive good?

In the talk, I shared a three-step process that I developed to stand up the first iteration of a product or service that’s intended to encourage positive behaviors and habit formation. In the coming months, I'll delve more deeply into the details of the above process. Here's a high-level summary of each phase.

 

1. Defining the promise of your product

When working with a client, it can be easy to use different techniques to encourage habit or behavior formation, without being able to qualify exactly why that habit or behavior is desired by a person and beneficial for them in the long term. People use products and services because they want to accomplish a certain goal for particular motivations that may not be clear you as a designer. Many of the goals people want to accomplish—losing weight, saving money, stopping addiction, and so forth—require multiple habits be put in place and sustained not for a day, or a month, but a lifetime to achieve a desired systemic effect.

At the start of the design process, you want to clarify what type of net benefit a person is looking to achieve from your solution, and how that solution relates to larger societal issues. This net benefit, which is the promise of your product or service, is your hypothesis for how people may value its use as part of their everyday lives.

 

2. Generating a behavioral vocabulary

When I’m moving through the first iteration of a product or a feature that’s focused on behavior change, I ask my team to determine the vocabulary at play. We identify what people are doing (specific verbs), the objects within the interactive system being acted on or changed (specific nouns), and how those actions add up over time to create or reinforce a particular behavior. These behavioral “chunks” are the building blocks of your product or service. This can be part of your immersion as a team before you do formal research and design.

 

3. Testing behavioral routines that encourage positive habit formation

Once you’ve established the baseline vocabulary for your potential product or service, it can be tempting to just create and ship something big to get feedback for an entire routine or a systematic set of behaviors. “We want to help people lose weight, so let’s make an app where you get a push notification whenever you’re about to eat a meal to make sure you eat less, then you take a photo of what you’re going to eat, then you write after the meal how much you ate, so that way you end up eating less, and then…”

This is dangerous thinking for any designer. You have to curb this impulse and start by designing for the smallest units of behavior possible, the tiniest habit that could potentially changed, and then see how that change may impact a person’s overall behavior (with their permission, of course). As an example: When designing a solution to help people better save and spend their money, my team spent time interviewing people with different spending and savings behaviors. The first part of each interview was for us to understand their existing savings and spending patterns, and the motivations regarding why they were able or unable to meet their personal goals around saving money. Then, based on the stories they shared with us about when they had struggled to save money, we provided potential solutions to gauge if the vocabulary of the solution fit their needs. If it didn’t, we collaborated with the person to revise the hypothetical solution based on what they thought would be best for them for discrete situations.

“Small wins are a steady application of a small advantage,” says Charles Duhigg, author of The Power Of Habit: Why We Do What We Do In Life And Business. Once you have enough feedback to gauge initial fit for a solution, you can put that increment of the product to a test. I like to start with solutions at the lowest fidelity possible. Instead of creating a software prototype, we might write out instructions for a person to follow on a sheet of paper, then have them snap a photo and send it to us. Or we might manually send a text message or an email to prompt a certain action instead of doing it through an automated service. Once you see how long a habit takes to form, you can think about how to sustain them and whether they can become long-term behaviors. You may also discover that how people use your solution inspires a different, more effective way to form a habit. This helps you better refocus and improve your product or service solution and build it out.

 

Building New Habits and Behaviors into How We Work

We are heading towards a new destination as designers, collaborating with many disciplines to create the future of almost any digital or physical device we can imagine. And unlike when I was learning to drive my car, there’s little habit-related support for me for me with all of these new and constantly changing products. My teacher can’t remotely stop me from texting during an important meeting and there’s no guidebook to remind me to shut off Facebook in the middle of dinner. Much of the effort is on us, both as the creators and users of interactive products, to integrate new habits and behaviors into how we work, asking the right questions that respect others and what they want to achieve. It’s my hope that a process like this will help make that possible.

An early version of this essay appeared on HOW Design.

Pick a Number, Any Number—As Long As It’s Five

The car saleswoman leaned over the desk, placed a sheet of paper down in front of us. “This is a version of the customer satisfaction survey they’re going to send you next week in the mail.” It was a garden-variety survey about the car purchasing process, with a five-point scale that ranged from Excellent (5) to Poor (1). She plucked a pen from the desk before her, then drew a hard blue line down the page between the 4 and the 5.

“If I’m rated anything less than a five,” she said, “then I’m not doing a good job. It’s either a five or I’ve failed.” She continued to describe how even one 3 or 4 in a month could lead to her not being considered a top salesperson. Then she wouldn’t be able to take her family to Hawaii or the Bahamas at the end of the year, courtesy of the car manufacturer, as a thank you for her performance.

Talking about the whole situation after dinner, my wife Mary said:

Buying a car sucks. Everyone knows it. There’s no way in hell this survey thing is working. If they’re all getting fives and the company says less than five is a failure, then why does buying a car still suck? These surveys send employees to Hawaii—they aren’t actually influencing the overall customer experience.

Surveys can be useful instruments for gathering data from people, but survey questions can be bent or manipulated in ways that destroy their benefit for everyone. In the end, is anyone actually using this data to improve customer service? Or are they just using it to punish service providers?

Rather than relying on the illusory difference between a 4.5 and a 4.7* for quality service, I’m more interested in how someone answers the following simple question: “Was this service great? Yes or no, then tell us why.” In the case of car surveys, this type of open-ended question is one of the few places post-purchase where direct service improvements are solicited. Matt Jones at Edumunds says “at the end of Customer Satisfaction Index (CSI) surveys, there is a comment section for the car shopper to address any concerns that may have come up while doing the deal. These comments do not affect the overall scoring of the salesperson. If a car shopper thought the music was too loud in the dealership, for example, saying that in the survey comment would likely be a better option than giving the salesperson an 8.”

So next time you think about using a graduated scale in your survey, know why you’re using it, what biases those delivering the survey may introduce, and whether there might be a better research instrument to achieve a more relevant result.

* We see this in services like Uber, where if a driver's rating dips below 4.X stars they may not be able to participate in the service. Absolute perfection required.

Three Engineering Acronyms Every UX Designer Should Know

How DRY is your design? Does every element in your design have CRUD? Can you narrow the GIGO gap?

I find it hard to think about creating UX designs without considering the underlying logic an engineer will use to bring it to life. Successful UX designers are often trained in markup and coding, working within modern web design principles supported by constantly updated libraries housed on Github. However, there are many principles that are used by software engineers that can help new user experience professionals make design decisions that are more likely to be implemented successfully and scale appropriately. Here are three that I use regularly in working with my design teams. 

 

Just How DRY Is Your Design?

DRY stands for “Don’t Repeat Yourself,” and it’s an engineering mantra every designer should know. “We’ve got to DRY this out,” I’ve heard many engineers say when they’re thinking through how to build on-screen components, establish relationships between page templates, refactor how a back-end service should work through an API, structure a database model, set up automated testing protocols, and so forth. (The acronym originates from The Pragmatic Programmer by Andy Hunt and Dave Thomas.)

The DRY principle has equal application for how designers approach what elements they should include in their screen designs. Exploring many divergent potential design ideas is what allows us to create the best concepts to build and test with users. But we often cause issues by varying our designs in ways that require engineers to create multiple and varied instances of the same objects, styles, and screen structures. We burn time managing these details rather than repurposing key elements. In the long term, users can become confused by so much variation in the large and small details of our designs, and we will need to refactor our design and associated code to simplify the experience.

You need exceptional reasons to justify building out so many exceptions for your product. Apply the DRY principle to your UX and development work by asking these questions of your design ideas, as well as when you enter into critique with your team.

Design Pattern Replication: Are there major variations in the design patterns we’re using across screens? If so, should they be made more consistent? This applies to both overall screen templates and layouts, just as much as the design of modules that slot into your screens. As an example: Say that you’ve created a blog template for your corporate web site where you have a specific carousel design for when people upload and display their images for users. On the home page of your corporate web site, you have a completely different carousel design and implementation. Should they be the same design and code base, or different? If so, why? Can you justify the need for a difference, or should you DRY it out?

Screen Templates and Content Relationships: Is the content hierarchy reinforced across different screen templates? Are we creating too many templates, when only one or two would suffice? Are we thinking modularly about what modules and components will inhabit them? Are we presenting the objects in these templates in a constrained way? As an example: If you have eight ways you allow the user to display a text block or image on a screen, you are creating dozens of potential layout issues and exceptions in how those screen templates are engineered. What if you only had six ways to display those items? Four? Two?

Component Reuse: Do these components we’re using on this screen appear anywhere else in the system? If so, are they consistent? If not, should we consider making them global components, which can be reused over and over again? This approach can apply for anything from radio buttons and drop-down menus to navigation and search patterns. This approach also applies to how you size and present those components across devices, if you’re reinforcing cross-screen consistency and/or fleshing out a responsive design.

Type Handling: Are our decisions around type handling consistent across screens? Do our h1, h2, h3, and other elements match in size, weight, and spacing? Do the typefaces that we’ve selected render appropriately across the devices that we’re targeting? 

Color Use and Reinforcement: Are we repeatedly selecting and applying our color choices in a way that reinforces specific intents for our users? As an example: You use red as a color for when issues come up during in-line form validation for users looking to sign into your product. Are you sure it’s a good idea to use the same color for headlines on your home page and for buttons asking for you to leave a comment?

If you have a strong brand system and design language in place, it’s easier to answer the above questions and make sure your designs are DRY. If you don’t, then continuing to ask and answer these questions from sprint to sprint will help you drive towards a more explicit design language for your product.

 

Does Every Element in Your Design Have CRUD?

Most things that we design allow our users to create all sorts of content. But as designers, we often leave out the explicit actions that people need to properly interact with that content. And if we don’t specify these actions in advance, we might risk leaving out critical functionality that makes our interactive websites and products unusable.

 All you need to remember is CRUD: Create, Read, Update, and Delete. The term was first spread widely by James Martin in his book Managing the Data-base Environment. These are the key actions (verbs) that people require when using a software system that involves the creation and management of content that is held in a database. You see this principle applied to all types of software, from managing content in a corporate CMS to allowing user-generated content within a product.

Here’s how each action should be considered in your designs.

Create: Provide people with the ability to add an object into the system, including any key supporting details or metadata that support how it’s read and updated. As an obvious example: When you use Facebook and want to post to the News Feed, you tap on a button that allows you to create the post and upload it into their system, including text, links, photos, videos, and any associated metadata that’s required to support how that object will render to yourself and other users. The metadata may be explicit, such as time posted to the system or location, or implicit, such as what other friends happen to be near you and also posting. UX designers should have an awareness of all these data elements when they design a flow for content creation within their product or system. 

Read: Allowing people to view this content once they’ve created it. You will need to choose what elements that the user creates will be rendered, and where it appears in the system. The user may need to sort, filter, or adapt the view of that content object to make better sense of it, as well as take other actions related to that content object. As an example: If you’re managing a web storefront, you may create an item for purchase, and the user will need to be able to read information about it in order to buy it, save it to their wish list, and so forth.

Update: Once you’ve put content into the system, you may need to update some of the details associated with it. You may only be able to edit select fields related to that object, depending on the case. As an example: Revising a comment that you have left on a website may only be allowed for 15 minutes after you’ve posted it.

Delete: If you don’t want the object to be within the system anymore, you need the ability to remove it. The challenge from a design and engineering perspective is not only providing the ability to remove it from rendering, but also to consider the cascade effects of that deletion across your entire design and all screen types. Don’t assume that the user deleting the object should cause it to be wiped from the system completely, especially when the deletion has to do with the user’s profile or identity within the system. As an example, if you go to cancel or delete an account, you may want to ask the user if they want the data to be held in case they want to reactivate the account. Doing this absolutely depends on the context of your system! As a sacrificial example: If you’ve created a website that’s meant for secure, anonymous storage of a person’s legal documents, deleting your account might require the destruction of all objects associated with that person based on what you’ve promised to your user.

You’d be shocked how many websites or products build minimum viable products without including one of the above actions, causing major issues along the way.

 

Can You Narrow the GIGO Gap?

Most people know the term GIGO: Garbage In, Garbage Out. In essence, if you’re bringing garbage into a system that you’ve created, that system will inherit and recombine that garbage, then presenting it to the user as part of what they experience. (Unless we’re talking about the content we see regularly on fail blogs and humor websites.)

As a UX designer, I want to reduce the ratio of garbage coming into the design that could impact the user, both in what is provided by back-end systems and databases in terms of data, and in what design decisions that I am making that enforce the appropriate level of quality for the resulting output. There is always a gap between the two. Narrowing that gap is one of the constant struggles that you will have as a UX designer, and it’s one of the top reasons why a designer’s intent is not realized in a website or a product.

Ask the following questions of your team to try and narrow the GIGO gap.

Database Schema: Do the content elements and functionality shown in your design exist in your system’s database? If so, what is the level of consistency and specificity in how it’s stored? If there are gaps, how hard would it be to add those fields? In doing so, are there larger impacts that you hadn’t considered? New relationships between those data elements? Missing metadata? New models for content relationships?

Content Audit and Quality: How robust is the actual content that is in the system and stored in your database? Does it meet the quality standard that you’ve set in your designs? If not, how much time and effort will it take to improve it? Does that dovetail with how much time it takes to update the database to store those changes?

Back-End Services: Does the way that content and data is served to the user need to change based on what you’ve designed? Does new functionality that you’ve proposed require new services to make them a reality? Is the quality of that service part of the GIGO gap? If the database and content has changed, what will need to be revised to properly consume and serve that content? Are the proper API contracts in place to allow them to be served for use by your user interface?

Front-End Development and UI/UX: What’s the minimum viable functionality and content revision that can create the greatest impact for the user? If a proposed function or type of content isn’t available for a period of time, does removing it degrade or destroy the design solution you’ve set up?

User Feedback and Metrics/Analytics: How does the user give feedback about what they perceive as garbage in the system? How does their feedback dovetail with the overall data and analysis you’re doing about user behavior?

By answering the above questions, you’ll identify the necessary gaps to fill, and be able to prioritize and plan how they can be improved with your teams.

 

What Engineering Principles Do You Use?

Are you also using engineering principles in your UX design work? Please leave them in the comments, so we can make stronger design solutions and become BFFs with our engineering collaborators.

Thanks to Michael Devin and Matt Conway for discussing the above principles with me over the years and helping me apply them.

My New Role as Director of User Experience at Lynda.com

In the past five years, I have dedicated much of my effort to helping people learn the skills they need to succeed and pursue their passions, both in professional practice at frog, as a teacher at California College of the Arts, and as a writer of design books that encourage learning by doing. That's why I'm excited to announce that today I joined Lynda.com as their Director of User Experience. In my new role at Lynda.com, I am responsible for the design of their product across devices and platforms, leading a team of UX designers that want to help people around the world reach their fullest potential.

If you're like me, Lynda.com has been there for you when you needed it most. At pivotal moments in my career, Lynda.com has provided me with the training that I needed to advance in my career. Lynda.com has been a premier resource for advancing our individual and collective practices as designers, creators, and businesspeople. For this reason, I'm thrilled that I'll be able to collaborate with their team to make it even better. (And if you're passionate about making a difference in the online learning space, you should join me! I am currently hiring a few UX designers and senior UX designers to join our San Francisco office.)

In addition to this, I have other news. Upon leaving frog as a full-time employee, I have been named a frog Fellow. I am humbled to have been chosen for this rare honor, and will continue to advise select social impact, design education, and project-based learning initiatives at frog in the coming year.

Thank you for supporting my efforts for these seven years I've been blogging about design on ChangeOrder, and here's looking forward to many more!

See the Sticky Notes at SF Design Week's Studio Crawl

I play drums in an all-frog cover band, the Sticky Notes. We’re playing a free show on Tuesday, June 17th at the frog design studio at 660 3rd Street (3rd and Townsend) in San Francisco. Our studio will be open to guests from 6–9 PM with a DJ, and we’ll be rocking a mix of classic and modern songs from 8-9 PM.

This is part of the SF Design Week’s Studio Crawl. I hope to see you out there!

And, of course, mad props goes out to Amalia Sieber for the great band poster she created for us.