Gaming
Entertainment
Music
Sports
Business
Technology
News
Design
Fitness
Science
Histoy
Travel
Animals
DIY
Fun
Style
Photography
Lifestyle
Food
2018-04-24T06:37:36.594Z
0
{"feed":"Design-Staff","feedTitle":"Design Staff","feedLink":"/feed/Design-Staff","catTitle":"Design","catLink":"/cat/design"}

Twenty years ago, when I started my design career, I made a lot of fake stuff. I can still clearly remember when I designed my own CD covers for albums by famous bands, created a fake e-commerce site with my friends, recreated famous logos in Corel Draw, redesigned a popular website just to see what I would do differently, and designed fake logos for fake products that didn’t exist yet. You might say, “What a waste of time on unpaid work!” You could say “Gosh, you didn’t understand the intricacies of designing for the real world!” But, all of this fake design work was critical to my career.

Fake design work let me get in thousands of reps. When I was about seventeen, I literally designed a hundred album covers in one year. I bought a stack of cheap jewel cases and repackaged my CD collection in my own designs. I didn’t make a penny, I didn’t get critique from anyone, but I sure as hell got a lot of practice digging into Photoshop 5, trying typography in ways I’d never done, using photography in ways I’d never considered, and trying to get decent results on a crappy color inkjet printer. The final ten album covers were leagues better than the first ten.

Fake design let me try work that I wasn’t qualified for. When my friends and I started a design agency in 1999, many of us were in our late teens and we had never built an...

When coaching startups to conduct interviews and usability testing, I see one opportunity that is missed again and again: building a strong rapport with research participants by reading and responding to their body language. For me, learning to do this was like finding a magic potion that instantly improved the caliber of my research, and it made the whole process a lot more enjoyable, too.

When we walk into the room ready to do our research, we’re usually focused on how to efficiently gather the information we need and get out. And we may be nervous ourselves, especially when we’re doing research off-site in unfamiliar territory like a participant’s home or office. In either case, rapport isn’t top of mind for us — but it should be.

We have to remember that no matter where they happen, research interviews are a little weird for everyone. We invite strangers to have one-sided conversations with us that can often feel quite personal. The participants just want to do a good job and make us happy, but they’re worried about doing something wrong, or worse, looking stupid. Collecting quality information from them hinges on our ability to put them at ease and quickly earn their trust. If we don’t, they’ll remain nervous, suspicious and hesitant to share their personal stories — and we’ll never get the information we’re after.

How do we solve this problem right away? While I’ve seen a lot of literature about things like micro expressions, mirroring breathing, and transactional...

A few tricks for distributed teams

One of the most common questions about the GV sprint process is “How do you run a remote sprint? What if the team can’t be together in one place?”

I’ve heard stories of people running successful remote sprints, but to be honest, I never totally believed it. Part of the sprint magic is being in the same room.

But this year, our team at GV was forced to run a few distributed sprints… and it actually worked. It’s not ideal and it’s not great, but it’s definitely possible.

I still don’t have a perfect answer for how to make remote sprints work. But if you decide to try it, I have enough ideas to (hopefully) keep you from going crazy. Here goes…

Tricks I’ve tried that worked:
  • Use Google Hangouts for video. I am totally biased toward Hangouts because I used to work on it long ago. But it really does work nicely for multi-person video chat.
  • Use Google Slides for Monday’s whiteboard (or a Google Drawing). I am biased against Google Slides because I don’t think it’s very good for making presentations. But it does make a decent whiteboard. The collaborative features allow people in all locations to edit Monday’s map, long-term goal, and sprint questions.
    Maybe more important, everyone is equally disadvantaged. When you have a whiteboard in one location, it’s great for the people there and lousy for everyone else. With Slides, everyone’s looking at the same mediocre thing.

We made this video for people running their first sprint—or trying to explain a sprint to somebody else. Check it out:

Two notes:

  1. Yes, that’s my best acting.
  2. Yes, the video is 98 seconds long. But the last 8 seconds are a sales pitch, so they don’t count.

Speaking of sales pitches, if you’d like to read more about sprints, you can buy our book here.


GV’s Sprint Process in 90 Seconds was originally published in GV Library on Medium, where people are continuing the conversation by highlighting and responding to this story.

As far as I know, I’m the only UX researcher at a venture-capital firm. (If there’s anyone else out there, please say hello!) This gives me a pretty unique perspective, and a big challenge: I’m constantly jumping into new domains and figuring out how to have an impact quickly.

GV has invested in more than 300 startups, so I’ve had a lot of practice. Again and again, I start from scratch, understand the business and industry, then find a way to help each team answer their most important questions.

So when I had the opportunity to address a group of Google UX researchers, I decided to talk about what I’ve learned from this experience and how I approach research projects.

Here are the slides and audio from the talk.

Feel free to respond below if you have thoughts or questions!


Start at the End: How to Do Research That Has Real Impact was originally published in GV Library on Medium, where people are continuing the conversation by highlighting and responding to this story.

(This essay is based on my keynote talk at Techstars FounderCon on October 18, 2016. I’ll post the video once it’s up.)

The United States Census of 1880 came at a pivotal time in U.S. history. It was the last time the Census Office could identify anything resembling a U.S. frontier; for the first time, just half of the country worked in agriculture. The census itself had grown so large that the government was collecting more data than it could tabulate — it took a full eight years and thousands of people to produce the twenty-three volumes containing their analysis. At that rate, it was entirely likely that the 1900 Census would start before the 1890 Census results would be completed.

Enter Herman Hollerith. A teen graduate of the Columbia School of Mines, Hollerith’s first job out of college was in the Census Office in 1880. He’d seen first-hand the challenges they’d faced, experienced the frustration of knowing the information was contained in the voluminous records gathered by the census takers, unable to extract it. After just two years, he left to take a Mechanical Engineering professorship at MIT. He was 22.

Hollerith had been experimenting with punch cards as a storage medium; by 1888 he’d expanded on the idea by creating a corresponding machine to electrically tabulate the stored data. The idea of using punch cards to store information was not new — the Jacquard Loom, invented 80 years prior, used punch cards to store complex...

As a design partner at GV, I’ve worked with more than 100 startups in the past five years. Before that, I was a design lead on teams at YouTube and Google, and an early employee at FeedBurner, a startup in Chicago.

In other words: I’ve seen a lot of design teams in action over the past decade. The people on these teams are invariably talented, smart, and hard-working. But having great people doesn’t guarantee great teamwork.

I’ve come to recognize eight common dysfunctions of design teams. Fortunately, I’ve also seen solutions to these dysfunctions — proven, reliable, and simple techniques that teams can use to work better together. And finally, I’ve translated these ideas into a set of mantras that capture the best behaviors of successful design teams.

1. The “everybody knows” fallacy

When we start a project, we assume that everyone shares the same understanding of the problem and goal. The truth is that knowledge is not distributed evenly on a team — everybody knows different things. Even on teams that communicate well, there’s rarely an opportunity to unpack all this knowledge for the benefit of the group.

Solution: Assemble a cross-functional team, then interview your teammates and write down what you learn.

Mantra: “Get the right people in the room.”

2. Starting with solutions

Design teams are full of enthusiastic, creative problem-solvers. Our instinct is to kick off a project by thinking of solutions right away. It’s a lot of fun, and it feels like an efficient way to work. Unfortunately, it’s not the best use of everyone’s problem-solving energy. Without a good understanding...

The typical workday is busy, but it’s not always productive. We spend too much time on email, have too many meetings, then struggle finding willpower and energy to focus on what’s really important. This isn’t our fault. After all, as Cal Newport says, we’re just taking the path of least resistance.

Plenty of authors have proposed systems and philosophies for getting more done at work. My writing partner Jake Knapp created his own solution in 2009: the sprint. It’s a five-day process that helps teams focus on one big goal, taking them from ideas to prototypes to customer research in just a week. In a sprint, you get to fast-forward your project — to see what the end result might look like and how customers would react.

But the sprint is not another theoretical model or framework. It’s a proven recipe, and in our book Sprint, we provide detailed hour-by-hour instructions for following that recipe. At GV, we’ve tested the process with more than 100 companies. We help our startups use sprints to answer big questions, test new business ideas, and solve critical challenges. We’ve seen firsthand, again and again, how sprints help teams get more done and move faster.

Yes, sprints are fast, but it’s not what you think. The sprint is not an all-out, late-night, stack-of-pizza-boxes-on-the-conference-table affair. In fact, the sprint day only lasts from 10am to 5pm. You’ll have plenty of time to hang out with your family, meet up with friends, get a good night’s sleep — and yeah, stay caught...

What to do when your team is focused on unimportant details

Last week, I met with two companies that are building incredibly complex, ambitious medical products. One of the companies is trying to fundamentally improve cancer outcomes in a way that could save millions of lives. The other company is trying to eliminate an entire class of diseases — not improve treatment, not cure a specific disease, but to eliminate a whole set of diseases. Wow.

I’m a pretty experienced designer, so when I talked to these companies’ leaders I expected to discuss the complexities of their product design challenges. Instead, the first company wanted to talk about what shade of carpet they should choose for their new office and the other company wanted me to work with them to improve their PowerPoint master template.

Wait, what?

These companies aren’t ignorant about the power of design. My team at GV has worked with them before and previously we worked on big, strategic projects. So, why were they focusing on such surface-level design challenges this time around?

Back in 1957, a guy named C. Northcote Parkinson observed that people often give disproportionate focus to trivial projects at work. As an example, Parkinson described a team that is creating a nuclear power plant. During the planning stages, a big debate breaks out about the design of the shed where employees will park their bicycles. Instead of arguing about the details of power mechanisms, cooling systems, or waste fuel storage, it seems...

I’ve advised recruiting operations at close to 300 startups, ranging from a five-person team at Scalyr to a several-hundred-person team at Gusto. Most startups share a common theme: Technical recruiting is often a top business priority — and every startup wants to improve its recruiting operations.

In an increasingly competitive environment for technical talent, and with the average time to hire for software engineers now over 35 days at best, startups need to consider faster, more efficient strategies to recruit the best talent. Whether you’re building an in-house recruiting team from scratch or looking to maximize the efficiency of your existing recruiting team, read on for five strategies that will take your recruiting operations to the next level.

Focus on the “tech” in tech recruiter

Hire a tech recruiter who understands your technology. You would be surprised to learn how many startups hire tech recruiters that only have a cursory understanding of technology. A technical recruiter should be able to explain at a high level what a distributed system is, or the difference between a native mobile app and a web mobile app.

Having a good general grasp of technology is a core differentiator between an average tech recruiter and a great tech recruiter. Tech recruiters with a solid grasp of technology are more effective in understanding the complexity and relevance of the problem sets that technical candidates have encountered and solved. More importantly, they are in a much better position to determine whether or not those experiences and skills translate well and fill...

Recently, Jared Spool caught my attention with an article about how Netflix’s performance engineers are actually designers. It’s a provocative idea, but it makes sense. His argument is that everyone in your organization (including performance engineers) designs the product, not just the people with “design” in their job titles.

From some of the reactions, you might think Jared had kidnapped a baby for ritual sacrifice. What exactly did Jared write?

The members of this team are performance engineers. They are architecting, engineering, and maintaining the performance of a very complex system. It occupies all their time and then some. In systems engineering, there are few jobs more technical than these.
And yet, at the very moment that a Netflix viewer’s video stream stops and that spinning animation appears, indicating the player is now awaiting more data, these engineers make a dramatic change. They become user experience designers.

I made that last sentence bold — because it’s really important. Some designers are uncomfortable with the idea that an engineer or a salesperson or a CFO could be a designer.

Whether you like it or not, whether you approve it or not, people outside of your design team are making significant design choices that affect your customers in important ways. They are designing your product. They are designers.

This shouldn’t be provocative — it’s just a statement of fact. I work with dozens of startups every year, and I see it happen at every one. A...

GV’s Simple Recipe For Getting Started On Your Brand

With super deluxe thanks to Laura Melahn, Daniel Burka, and John Zeratsky

Warning: This is a post about branding, but I’m no brand expert. For most of my career, any mention of the word brand made me uncomfortable. I figured it was a fine line between “brand exercise” and “total waste of time.”

I was forced to confront my branding heebie-jeebies five years ago, when I joined Google Ventures. Previously, I’d always worked at big companies (Google, Microsoft, Oakley) with established brands. But at GV, I found myself working with startups who were thinking about their brands for the first time. They were designing logos, creating visual identities, and naming their companies — in other words, making a lot of big decisions.

Brand exercises make big decisions easier

Luckily for our startups, two of my colleagues at GV, Laura Melahn and Daniel Burka, actually are experts on branding. (They’re modest and will tell you they’re not experts, but don’t listen. Among other things, Laura helped name Calico and Daniel helped design the Firefox logo. They really get this stuff.)

Over the past few years, I’ve watched Laura and Daniel help startups through these stressful decisions about naming, identity, logos, and so on. They start with brand exercises. Much to my surprise, the exercises are not a goofy waste of time.

The point of these exercises, it turns out, is to make the abstract idea of “our brand” into something concrete. After doing the exercises,...