Book Notes: Discussing Design

discussing-designCommunication is an important soft skill for product designers. In Discussing Design, Adam Connor and Aaron Irizary discuss the importance of critique in the design process.

A lot of communication within a design team comes in the form of critique. Adam and Aaron explain how to deliver and receive critique. (For communicating with PMs and engineering, I’ve really enjoyed another book: Articulating Design Decisions by Tom Greever.)

You can improve as a designer by delivering useful feedback to other designers. The same way teaching is a great way to solidify knowledge, delivering useful feedback requires you to think about different aspects of design and organize your thoughts.

What kind of critique is useful? Let’s take a look.

Critical thinking

I love Dribbble — it’s a positive place on the internet, and that’s a great thing. However, it’s not the best place to look for effective critique. Adam and Aaron’s three key elements to effective critique can help explain why:

“1.) It identifies a specific aspect of the idea or a decision in the design being analyzed.”

People complain that Dribbble feedback isn’t useful for finding flaws and improving design. “Good job” and “Great work!” aren’t specific at all.

“2.) It relates that aspect or decision to an objective or best practice.”

A lot of time, the work shared on Dribbble is a detail shot or some other form of a very small part of a larger project. There isn’t enough shown and sometimes there isn’t an objective at all to relate critique to.

You should be basing design decisions on objectives and best practice. When starting out, it’s good to lean on best practices to build out something that mostly works. It’s okay to stray away from best practices if your solution works better for a project objectives.

When critiquing, think about design aspects that are going against objectives or best practices. Otherwise you might simply be saying that your arbitrary choice is better than their arbitrary choice.

“3.) It describes how and why the aspect or decision work to support or not support the objective or best practice.”

Good critique requires effort on both ends. Presenting something while also explaining all the factors involved — constraints, timelines, background info — takes effort. Parsing this info and fully understanding the problem being designed for also takes effort.

Combined, this is probably why there’s not a hugely popular community for useful design feedback. If people took the time to do that on Dribbble, it wouldn’t be a light, fun place to go to. It wouldn’t be Dribbble.

Feedback that doesn’t nail these three elements might fit into another category. Let’s take a look.

Reactions and directions

Discussing Design describes three types of feedback: reaction-based, direction-based, and critique.

Reaction-based feedback includes the quick emotional responses you’ll often get when showing something for the first time. “Nope.” and “Good work!” are examples. You can tell how useful feedback is by asking the following questions:

“…are the people from whom you’ve asked for feedback reflective of your design’s actual audience? Are they looking at it the same way your potential users would? Does this reaction divulge anything specific about any of the design decisions you’ve made so far or their effectiveness?”

With reaction-based feedback, the answer to these questions is usually “no”.

If you leave a meeting with a list of changes, that’s direction-based feedback. It answers “yes” to some of the above questions, so there’s a time and place for it. But it can be an issue:

“Similar to reaction-based feedback, direction-based feedback without any explanation indicates nothing about the effectiveness of your decisions in meeting the design’s objectives. Sure, if the person giving you feedback is the one who will ultimately approve the design, she might supply you with a to-do list that you could act upon to get her approval, but getting that approval and creating an effective design are not necessarily the same things.”

Sometimes you might hit the three elements of critique and it still won’t be useful. How come? The timing might be off.

Critique Timing

Connor and Irizarry provide a good rule of thumb for when to critique solutions:

“For example, the best time to critique a solution is after it is 20 percent baked but before it’s 80 percent baked.”

When you’re in that 20%–80% sweet spot, it’s good to receive critique often. Discussing Design refers to “Dailies” done at Pixar. I went to the bookshelf (read: searched my Kindle) to check out what Edwin Catmull had to say about Pixar Dailies in Creativity Inc.:

“The first step is to teach them that everyone at Pixar shows incomplete work, and everyone is free to make suggestions. When they realize this, the embarrassment goes away—and when the embarrassment goes away, people become more creative. By making the struggles to solve the problems safe to discuss, then everyone learns from—and inspires—one another. The whole activity becomes socially rewarding and productive. To participate fully each morning requires empathy, clarity, generosity, and the ability to listen. Dailies are designed to promote everyone’s ability to be open to others, in the recognition that individual creativity is magnified by the people around you. The result: We see more clearly.”

Engineering won’t have time to incorporate design improvements after the 20%–80% sweet spot. Before the sweet spot, it’s better to continue creating without stopping for critique. How come? Each task requires a different mindset.

Mindsets: Creative vs. Analytical

Many writers write and edit separately because they require different mindsets. One mindset is creative and the other is analytical. Adam and Aaron discuss how these different mindsets apply in design and critique:

“When designing something, the brain operates as a toggle, switching between creative thinking — where individuals are generating ideas or assembling parts of ideas — and analytical thinking — where they are determining whether what they’ve designed so far is in line with what they are trying to achieve. Experienced designers, artists, engineers, and others have learned how to be deliberate in controlling when to make this toggle, periodically pausing their creative work to take a step back and critique what they have so far.”

Discussing Design lays out some techniques to facilitate effective critiques.

Design Studio

In the Google Ventures design sprint methodology, diverging and deciding are separate steps.

Teams generate as many ideas as possible with mind maps and Crazy 8s. At the end, participants select the best ideas based on the objectives.

Discussing Design describes a similar technique called Design Studio. They mention Todd Zaki Warfel adapting the technique from other design disciplines to the digital world. Back to the bookshelf, here’s an excerpt from Warfel’s book, Prototyping: A Practitioner’s Guide:

“In the world of architecture and industrial design, a design studio is a process, not just a physical place. This process is taught in every respectable architecture and industrial design program. You’ll be hard pressed to find a design studio class in computer science.”

“In studio classes, you design or prototype and present to your peers. Your peers critique your work, highlighting the strengths and areas that still need some work.”

Adam and Aaron describe a three-charrette activity to quickly go through multiple rounds of design and critique. Like Crazy 8s, it involves timed sketching. Their activity goes like this:

  • 8 minutes for six sketches of different concepts
  • 8 minutes for iterating on their strongest idea
  • 20 minutes as a team to sketch one idea

Sum Up

Here are some key takeaways from Discussing Design:

  • Quality: Objectives and best practices are your guiding light for effective critique.
  • Timing: Critique is most useful when it takes place during the 20%–80% sweet spot.
  • Mindsets: Creation and critique require different mindsets and should be separated.

Embracing critique and following these principles will help you be more effective in delivering and receiving critique.

Book Notes: Founders at Work

founders_cover

In Founders at Work (2007), Jessica Livingston, founding partner at at Y Combinator, interviews 30 startup founders.

The Steve Wozniak interview alone is worth the price of admission, but it also happens to be posted free in its entirety on the book’s website. Check that out to get a sense of the questions, answers, and how thorough each interview is. (Put another way: the book is very long and also very good.)

The companies were founded from the 1970s to the 2000s. The interviews take place a few years after the dot-com crash, and slightly before iPods, phones, and internet communications devices became a single thing.

There were a lot of “Ohhh yeah” moments—the nostalgic kind, not the Macho Man kind. And they sort of come in two forms: 1.) memories from the founder stories where I could remember how that technology impacted me90s things like Hotmail and WebTV were real fun for me, and 2.) memories from “present day” 2007 before mobile took over the world—like Digg driving heavy traffic to sites.

pg had this to say in an old HN thread about the book:

Screen Shot 2015-03-28 at 9.55.37 AM

“Startups are basically comedies.” I highlighted a ton of things and picked a few to share—let’s start with some scenes from pg’s own comedy.

Paul Graham — Cofounder, Viaweb (and some investment firm)

Screen Shot 2015-03-21 at 8.44.09 AM

Years ago, working out of an apartment wasn’t quite as accepted. Here, Paul Graham talks about trying to look legitimate when, you know, business people visited.

When that first giant company wanted to buy us and sent people over to check us out, all we had in our so-called office was one computer. Robert and Trevor mostly worked at home or at school. So we borrowed a few more computers and stuck them on desks, so it would look like there was more going on.

It really does sound like a sitcom. And the fun doesn’t stop there. Here, he talks about power going out in Cambridge. After running the generator indoors and deciding it was too loud (not, you know, too dangerous), they put the generator in the street and ran an extension cord:

It was running through our office at chest height and you could kind of twang it and it would go “boinnnnnggg.” Then we started the gas generator up in the street and that was just about bearable, so we ran the servers on that for a couple hours until the power came back.

pg: scrappy. Founders at Work has a lot of stories involving hardware: servers getting overloaded, learning to use a shrink-wrapping machine for CD distribution, servers going offline so someone could drive it somewhere with a T3 line, etc.

Steve Perlman — Cofounder, WebTV

Webtv wh_account

When I mentioned “Ohhh yeah” moments, this was a big one for me. My cousin had a WebTV and so whenever my family visited his we’d use that to browse the web. And I have no idea what we’d even look at. At night we’d use his dad’s computer to play TetriNet.

With so many people connected in the Valley, founders also share early-day anecdotes from companies that aren’t their own. Here, Steve Perlman talks about Apple and dialog boxes:

The following is not something from my personal experience—it’s a story told to me by the Mac team—but they said that, when they first did the dialog boxes for the Lisa, instead of saying “OK,” it said, “Do It.” They found that people were reluctant to click on that, and they couldn’t figure out why. Then, once they had a test subject there who just wouldn’t click on it, they said, “Why didn’t you click on that little button there?” He said, “I’m not a dolt. Why would I click on that?”

So they changed it to “OK”. Don’t be a dolt, test with your users.

Mark Fletcher — Founder, ONElist, Bloglines:

Screen Shot 2015-03-21 at 8.34.02 AMScreen Shot 2015-03-21 at 8.38.38 AM

A lot of common themes run through the interviews. They’re things you hear about all the time about startups and building products. Here, Mark Fletcher talks about finding a problem to solve:

I started ONElist because I wanted to start a mailing list for my parents, and at that time you had to download software and you had to have a computer connected to the Internet. It was just really difficult for an average person to put together a mailing list. So it was the same thing. I guess my advice is: solve a problem that you have, first and foremost, and chances are, other people may have the same problem.

How do you find a good problem to solve? Solve your own. Ben Trott and Mena Trott, founders of Six Apart, created Movable Type because there wasn’t a great existing solution for Mena’s rapidly growing blog. Stephen Kaufer built TripAdvisor after trying to plan a trip and finding the end steps of booking had solutions, but planning where to go and stay wasn’t a great experience.

Another theme Mark Fletcher talks about is iterating:

So just get something out there. If you find really early versions of ONElist or Bloglines on archive.org, the websites are horrible. They are crap, they don’t have any features, they just try to do one thing. And you just iterate because users are going to tell you what they want, and they’re your best feedback. It’s critical just to get something out quickly. Just to start shipping and then you can iterate.

Founders at Work was published before The Lean Startup when lean methodologies and MVPs weren’t so widespread. Some of the concepts surely existed, but others wouldn’t work when releases were months or years apart. Charles Geschke, cofounder of Adobe, talks about Xerox in the 70s, “They said, ‘Oh wait a minute. At Xerox it takes us at least 7 years to bring a product out.’” Not to mention iterating after that.

Joshua Schachter — Founder, del.icio.us

Screen Shot 2015-03-21 at 9.12.23 AM

The variety of people and companies profiled is great. Some grew to thousands of employees, some stayed small, some were funded, some were bootstrapped. Some bordered on ruin and others say things along the lines of “I don’t know, it actually went pretty smoothly!”

Here, Joshua Schachter talks about building del.icio.us in his spare time:

I could come in and look at it, figure out what I’m doing, do it, and be done for the day in 15 minutes. So if I could get one thing done a day, I was happy.

I love this. Success comes through a lot of paths and it’s good to see that something millions of people found useful was built in (sometimes very) small chunks of free time.

Stephen Kaufer — Cofounder, TripAdvisor

Screen Shot 2015-03-21 at 9.16.19 AM

Again, a lot of companies built things we take for granted now. I booked a trip to Spain with some friends last year and, along with other sites, TripAdvisor was part of that. Still it was this whole production to plan out.

I can’t imagine planning without those resources. Stephen Kaufer talks about planning a trip before TripAdvisor and learning an island wasn’t all that great through a chat room. Here, he talks about finding content for TripAdvisor:

Then we hired people to read every single travel article we could find on the Net, and classify that article into our database, and write a one-line summary. It’s a fairly significant effort, and people that we talked to said, “You’re nuts. You’ll never finish.”

Do things that don’t scale.

Ron Gruner — Cofounder, Alliant Computer Systems; Founder, Shareholder.com

Screen Shot 2015-03-21 at 9.21.15 AM

The most entertaining stories are the most ridiculous. Ron Gruner shares a story about an 800-number mixup. A company printed millions of annual reports with the wrong 800-number for the shareholder’s call. Reprinting wasn’t an option, so Ron Gruner and his team had a few days to figure out how to take that number over.

Because of privacy issues, the paging company wouldn’t give up their customer’s details. Ron shares their solution to this privacy issue:

Then Josiah Cushing, one of the college grads I had hired, during our staff meeting said, “Ron, why don’t you try hiring a private detective?”

The guy who owns the number agrees to transfer the number over as long as they pay for his pager subscription for a year. And a subscription for his wife. “We’ll make it two years.” Not much of a price to save an entire company.

And then there’s the “Ohhh yeah” moment of remembering that pagers were a thing.

If you have any interest in startups or technology, Founders at Work will have something you’ll like. In a few years, maybe it’d be cool to see a sequel with today’s companies. “Our site was getting hammered. We had to spin up more Heroku workers.” Maybe not.

Book Notes: Show Your Work

show-your-work

I don’t read particularly quickly, but I finished Austin Kleon’s Show Your Work in a single sitting. It’s great for identifying what work is worth sharing and getting inspired to share it more frequently.

Here are the book’s ten main points and how they apply to me, design, development, prototyping, and my plans for this site.

You don’t have to be a genius
This is very good for me.

Think process, not product
I’m glad I really enjoy prototyping. It’s part of the process and leads to a better end result. On the other hand, it’s important to remember it isn’t the end in itself.

The idea of focusing on the process falls in line with other things I’ve read about work and learning. It becomes a cycle. When you learn to enjoy the process, you’ll improve and as you improve you’ll enjoy the process more. This gets you past dips and leads to better end products.

I forget where I heard this, but someone pointed out that people overestimate what they can finish in a day and underestimate what they can get done in months or a year. This can make it hard to start something big because you don’t think you’ll be able to finish it. But if you show up every day it adds up.

Share something small every day
After a few years of having a Dribbble account, I finally posted one thing. But I’ll start sharing more there. For all the flak it gets about comments being “Good job!” well, is that so bad?

It’s probably not the best place if you’re looking for serious critiques to improve things. But a design community with positivity as its core is, well, a net positive.

Open up your cabinet of curiosities
I’ve been linking to things on this site but I’m thinking of changing the format for sharing links. The ongoing link blog is sort of dead. Long live the newsletter.

Tell good stories
Austin Kleon talks about how art sometimes isn’t immediately interesting until you learn the story behind it. But something seemingly mundane with a good story is interesting because the story is interesting.

In that sense, I can look at the design sprint posts as stories explaining how certain prototypes came to be. I love reading other design process posts. Here are a few that come to mind:

I can’t get enough of these. They’re good stories.

Teach what you know
I try sharing what I know about Framer, Origami, and Form. Even with varying skill levels with each tool.

I’ve listened to Ben Orenstein’s Giant Robots podcast for a few months now. Learning and teaching come up as topics regularly in episodes. He encourages blogging every day:

Write about what you’ve learned so far. Don’t make the excuse that you’re just a beginner. Imagine someone who is two months behind you and write for them.

Recent beginners can be better at helping a novice because they just went through the same issues. Experts can lose that perspective. A huge benefit of it is that it really solidifies your own knowledge. Through teaching, you organize your own knowledge and identify the gaps that can be improved.

I’ll continue writing and putting videos together as I learn.

Don’t turn into human spam
My greatest fear. I was an over-sharer through high school and college. Then pulled it back in the past few years. And now I’m slowly ramping it up. The best way to avoid turning into human spam is to create interesting things. If spammers sent out a bunch of stuff people loved and found value in, well, it wouldn’t be spam.

Learn to take a punch
I wrote a Material Design post last year and was pretty excited that people were reading it.

Then one person tweeted it was “boring as hell”. It’s fine, I was ready for that jab. But then some designers I really respect favorited the tweet. So it was like the jab was chained into an E.Honda special.

This reminds me of one of Pasquale D’Silva’s tweets: “A glitch in many designers is the lack of ability to detach emotion from criticism.” It’s been really helpful to remember that criticism is free feedback.

Sell out
I’d love to. I’m putting affiliate links in book note posts and that’s about it so far. I read a lot of books and won’t be writing notes for all of them. It’d be great if it could pay for a better microphone or something of that sort.

In the meantime, I’ll stay focused on creating useful content.

Stick around
The first thing I wrote about design that anyone really read was about a personal design sprint. I’ve written a long piece about once every month or two since then. I want to keep it up. But I also want to start writing shorter things. Which is why I started designsprints.com.

I’ll stick around.