Design Sprints: Issue 2

“I’ll publish every two weeks” — Me, three weeks ago

For this issue, I’ll share one link related to each stage in a design sprint.

Understand

Design Details is my favorite design podcast. Brian Lovin and Bryn Jackson talk to a lot of people whose work I admire. Design Details lets me listen in on casual conversations between designers. It’s great to hear other designers talk about their interests and approaches to different problems.

Last month’s Best Of episodes are a great place to start. Episode 92: Best of 2015 – Part 2 has an excerpt of Josh Puckett’s interview. He talks about building things:

I sort of just grew up where there wasn’t this divide for me where there’s designer, where you only did Photoshop. And engineer, where you know you’re only doing code. It was sort of like “I want to make this thing” and to do that you’d need both these things.

Dan Mall said something similar a couple episodes earlier:

We have formalized our discipline so much that no one knows how to be scrappy anymore. I remember… okay this is totally OG like “I built sites in tables”. But when I learned web design, there wasn’t such thing as a back-end developer or a front-end developer. You made the website.

 

That meant you designed it, you animated it, did Flash, you wrote the PHP, you wrote the Perl script. Like I remember writing CGI scripts. I didn’t know what I was doing. I was copying and pasting things from the internet. Making forms work. I didn’t know what I was doing. But I made all of it. Made the whole thing.

Now I have npm and gulp to not know what I’m doing. Dan talks more about how specialization is necessary but we’ve lost some scrappiness.

This reminded me of how I learned. I had a problem I needed to solve: A lot of Counter-Strike clans had awful websites. I wanted my Counter-Strike clan to have an awful website also.

I had made some HTML sites (insert Made with Notepad badge) but needed to know a little more for this. I learned to install a bulletin board and customize it. Editing PHP files was where I had to be careful. MySQL was where I could really break things. I now know that as back-end stuff. And still stay pretty far away from it.

In a design sprint, everyone puts different hats on you make something together. Bringing the scrappiness back, one week at a time.

Diverge

No surprise, I’m a fan of the Google Ventures design partners and am looking forward to their book, *Sprin*t. Jake Knapp wrote about designing the book cover with Jessica Hische:

To begin, we “sketched” on the computer: each person using clip art and their favorite illustration tool (that’s Sketch for Braden Kowitz and Daniel Burka, and Keynote for me). We ended up with 200+ rough sketches and variations.

It’s been cool to see the series of Co.Design articles evolve into a book. In that original overview, Jake mentions its origins:

If you think you’ve heard of this model before, well, you’re right. It’s based on the design thinking structure championed by IDEO and Stanford’s d.school. However, I’ve experimented and tweaked the process a bunch over the last few years. The version I’m going to share works especially well for startups.

Which reminds me of Julie Zhuo’s article about creative confidence. It’s a term sharing that shares roots in design thinking concepts from IDEO and Stanford’s d.School. Julie describes some ways to gain creative confidence:

Invest in your process. A rock-solid process — a series of repeatable actions — is the golden goose to building creative confidence.

The design sprint is an effective, repeatable process. There’s not always time for that, so I’m learning to use elements of design sprint stages in my process.

It’s helpful to think about what stage the current problem would fit into and how we’d work through that in a sprint. If the ideas aren’t coming, I’ll try some timed sketching. If prototyping is getting unwieldy, I’ll sketch out a quick storyboard to re-focus on the user story.

Decide

Jessica Abel wrote about idea debt. She got the term from from a guest on her podcast, Kazu Kibuishi:

Now I’m actually solving problems in the moment, and that’s so much more exciting than than trying to fill years of what I like to call my “idea debt.” That’s when you have this dream of this awesome thing for years. You think, “Oh, I’m going to do this epic adventure. It’s going to be so great.” The truth is, no matter what you do, it will never be as great as it is in your mind, and so you’re really setting yourself up for failure.

In Jessica’s post, she has a list of examples of idea debt:

You’ve read 15 free online guides to blogging, built three editorial calendars, have notes on a dozen posts, but you haven’t gone live with your blog.

A little too close to home. In everyone’s overwhelming list of ideas, there are a few that stand out but even those can’t all be pursued. I’ve written about 1-person design sprints and have found them great for getting to a stopping point. A sprint won’t get you to an MVP, but you’ll know what the next steps could be and how much effort that would require.

Prototype

A lot of people are familiar with Google Docs collaboration. Harold Kim wrote about his success using Google Drawings for collaboration:

I wanted to find something that would give us the feel of a central discussion hub, and also convey a large-scale view of a design and its components.

Another cool thing is that you can copy and paste straight from Drawings to Google Slides. Of course, as far as slideshows go, there’s also Keynote. In those 2013 design sprint articles, Jake Knapp went over how great Keynote is for prototyping:

• It’s fast.

• It’s easy to make things look pretty good…

• But it’s impossible to make things look perfect, so you don’t get too precious.

• Anybody can quickly learn to use it; not just designers.

• The slideshow format is a natural fit for story-based design.

A lot of that is true for Slides, though it doesn’t match Keynote for animation. I’ve been on a sprint that used Slides for prototyping. It was amazing to see everyone contribute and continually review the story as screens came to life.

Test

Dave Johnston designed Counter-Strike’s Dust and Dust 2. Iterating and testing has existed since the beginning of, well, creativity. And these writeups show how critical testing was for a 16-year-old mapmaker in 1999:

The problem was I’d been treating this brand-new gametype as if it was one I knew already – Capture the Flag – except in this CTF mode the flag (the bomb) started at the Terrorist spawn. But defusal wasn’t Capture the Flag. In fact, it was so utterly different that hardly a comparison could be drawn. Placing the bomb in the CT spawn hadn’t even crossed my mind. I made the change, and sent it back for playtests.

Playtesting is an important stage of any map’s development cycle. Without it, there’s little way of knowing exactly how a map will play when faced with real people; real players who haven’t the intricate knowledge of the map that you have. It’s playtests that inform you of flaws that need fixing before release – if the map is even fit to be released at all.

As a 14-year-old in 2000, I appreciated the results of this process. These maps were like second homes with giant crates to sit on and friends to defuse bombs with. Great place to visit for a quick afternoon study break then realize it’s 3am the next time you check the clock.

In the next edition…

That’s that for now. I’m slowly working toward a better system for writing this newsletter. (Spoiler: I’m starting to think that system will be called “actually sitting down and writing.”)