Jake Knapp from Google Ventures describes their design sprints:

Since we want to move fast and they want to move fast, we’ve optimized a process that gets us predictably good results in five days or less. We call it a product design sprint, and it’s great for getting unstuck or accelerating projects that are already in motion.

The Google Ventures site has detailed posts describing each day. The sprints are designed for teams but I’ll be following the framework on a personal project.

Personal projects are easy to start because initial excitement for new ideas is high. Finishing is another issue, mostly because other new ideas come up and are more exciting. Sprints are structured with checkpoints and, more important to me, an end point. In the above article, Knapp discusses world! the advantages of constraints:

But I also didn’t have too much time. I couldn’t afford to overthink things or get caught up in urgent but less important issues, the way I often did on normal workdays.

There was something magical about a tight time constraint combined with individual work, prototyping, and quick user feedback.

For this sprint, I’ll be working on a photo blog interface idea. I traveled to Spain recently and shot hundreds of photos. I wanted to share them as page layouts with my favorite pictures and writing. That way I can wax poetic about ham-flavored Ruffles and show all the Haribo products in vending machines.

As mentioned, the sprint is broken into 5 days.

Day 1: Understand

Day 2: Diverge

Day 3: Decide

Day 4: Prototype

Day 5: Validate

The Google Ventures site has a detailed look the first day of the sprint:

The goal of the first day is to encourage everyone to share what they already know and develop a common understanding with the rest of the group.

Since I’m working alone, “the rest of the group” will be upwards of the entire world but more likely the seven or eight people reading this.

Why do I need this?

In my overview of the design sprint, I mention that I want to share photos and text.

Also, I wanted to share photos and text using Jekyll, a static-blog generator. Before and during my trip, I worked on a Jekyll site was happy with how things looked.

But creating each post was a chore. After exporting images, I would modify the placement in Markdown, copying and pasting images from this element to that element and changing classes accordingly. I say Markdown, but because of how the markup is structured it was basically just working in HTML. Which is like creating a website in the 1800s.

The interface I’m working on won’t solve a problem shared by a lot of people. So it’s not a good business opportunity at all. But it solves a problem I have, so I’ll gladly work through this to see what comes out of it.

Are there any exisiting solutions?

There are, of course, many solutions for this. Sharing an album on Facebook or Flickr is easier. Medium’s interface is excellent for writing and integrating photos. Tumblr has a decent solution for sharing multiple photos.

The interface I’m working on would lean more toward photos being the primary content so I’ll here’s a look at Tumblr’s multiple-photo interface.

The first animation shows rearranging and resizing. Images resize based on where the image is placed. A blue indicator line shows the new location and size and represents one edge of the image after placement.

The second animation shows caption text input. You open the text-input modal using an overlay button.

How will I know if the design is successful?

Knapp discusses success metrics and links to Jerry Rodden’s HEART framework. The HEART framework breaks metrics into happiness, engagement, adoption, retention, and task success.

For this, I’m just shooting for happiness. I created a bunch of posts in Markdown and know how tedious it could be. I’ll know if I get to something less tedious while producing similar results.

(Also, going through the sprint process will be a success in itself.)

Sketch the most important user story

As I mentioned, I export the photos I like and then place them. It’d be good to be able to place them, resize, move things around, add text boxes, move some more, etc.

1. Take pictures, 2. Edit in Lightroom, 3.) Export photos, 4.) Resize and arrange, 5.) Export markdown file.

Everything would be saved out, responsive, and optimized. Using magic. It’d be nice to be able to see how things would be laid out on mobile. But resizing the browser will suffice.

Thoughts on this sprint day

Parts of this sprint day only work with groups. Still, it’s really useful to look at existing products and think about how your solution will be different. With the user story sketched out, I’m ready for day two.

Day 2 is about creating as many ideas as possible. Jake Knapp describes day 2 with a great analogy:

Remember in the Legend of Zelda how the map would light up rooms you had visited as you explored the dungeon? That’s what you’re doing on Day 2: illuminating all of the possible paths.

Day 2 focuses on working individually to generate a lot of ideas to share with the rest of the group. I’m excited about this day because it looks like it’ll translate well to an individual project (and sharing on a blog).

The day is also focused on working on paper. Here are the steps: 1.) Choose part of the problem, 2.) Take notes, 3.) Mind map, 4.) Crazy eights, 5.) Storyboard, 6.) Silent critique, 7.) Three-minute critiques, and 8.) Super vote.

Steps 6-8 are group activities so I don’t know how that will pan out for my process. I’ll likely turn these into a single step called “give myself a gold star and pat myself on the back.” But first I need to get through cheap jerseys China steps 1-5.

Choose part of the problem

From the day 1 design diagram, you’re supposed to break the story into parts and then do this design cycle for each. This will be great for future projects. In my case, I think the story can be broken into the following pieces:

1. Upload photos
2. Create grid of photos
3. Modify size and placement of photos
4. Save/export

I might be able to get more granular (change photo source, drag photo to new location), but I’ll stick to those pieces for now. 2 & 3 are the only ones I’m concerned with for this exercise, because my goal is to share a prototype of this single screen at the point where photos have been selected and exported.

Mind map

Here’s a ten fifteen minute mind-map:

Mind mapping should get the ideas going and I think a good sign is that a lot of questions came up:

• Do we want to create the grid first with placeholders? (Kind of like the iPhone Pic Stitch app.)
• Do we want to start with all the photos on the canvas?
• Do we want to work with a row by row flow in mind?
• What would the Angular directives look like for this?

Solutions to these questions can be explored through methods such as design activities.

Crazy 8s

In the Crazy 8s activity, you sketch an idea in 40 seconds then sketch another in 40 seconds until 8 ideas are sketched. A lot of the end results aren’t useful but it helps break through plateaus in creativity.

Crazy 8s leads to a lot of ideas, not all of them good. But a little while after finishing there’s usually something useful that comes to mind. For whatever reason, iterating rapidly kicks off the right back burners for creativity.

So here are the results of the first cycle:

1. Default view where the images are just shown with 2 in each row.
2. Each image has an overlay with thumbnails of the bucket of images to click through and switch.
3. Modal for image bucket providing bigger thumbnails than #2.
4. Bottom menu with image bucket. Similar to Lightroom.
5. Toolbox that shows up when hovering over image. Not sure what the tools would be.
6. Drag to resize and move photo around.
7. Row based layout creator where you can drag rows of photos up and down.
8. Pre-determined sizes, similar ot apps like Pic Stitch.

Nothing mindblowing, but it helped me see that some solutions would be better depending on the workflow I’m looking for. If I know what order that photos will go in (if I’m trying to show what we did progressing from day to night), then switching images in place isn’t useful. The image bucket isn’t necessary.

On the other hand, sometimes I’ll export a ton of photos knowing I won’t use all of them. Some shots that vary slightly and I’ll switch between a few to see what I For like. But I don’t want the other ones to be floating around in the layout. This is where the image bucket would be helpful.

Here, we’re getting into conflicts, and day 3 (decide) deals with this.

An intermission: 5 Whys

I even did a 5 Why’s and came to this: why make this? To make posting easier, so I’ll post more, to have more to share, because And it’s good encouragement to keep creating, because I think it’s important to practice creativity.

Storyboarding

Before storyboarding, I sketched out a user story. From that I got to the gist of this whole thing. Looking at it as a black box, I want to put photos in and get a nice layout out (as a markdown file).

I ask everybody to draw UI in the three frames of their storyboard showing a progression: first this, then that, then that.

Here are my three frames:

1. Start with all images at natural size on the page.
2. Arrange images and resize.
3. Layout all done and ready to export.

The storyboard seems a little high level—it’d be good to drill down and do a cycle for resizing and a cycle for arranging. But hey, perfect is the enemy of good (and done) and we I feel like I have enough to move to day 3, so let’s do that.

Useful Links

Gamestorming: 6-8-5

Quora: Why does Adaptive Path say that sketching a design should take 5 minutes and 6 iterations? – answer by Todd Zaki Warfel

Vimeo: The Design Studio Method – Todd Zaki Warfel

Day 3 of the design sprint is about deciding what to build:

It’s awesome to have a lot of ideas. It’s a great feeling. But I’ve got bad news: you can’t build and test everything. And even if you could, it wouldn’t be very useful, because you’d have too much information to sift through. So you’ve got tough decisions to make: which solutions will you pursue and which will you put on ice?

Search for conflicts

is Day 2 helped generate more ideas, but they aren’t all in harmony. There’d be more conflicts in a group setting, but some came up on my own.

• Resizing can be done with buttons with sizing presets, or by dragging a corner, or with two buttons to cycle through each size, or by automatically setting the size based on placement.
• Photos can all be on the workspace at the start or they can be held in a photo bucket allowing you to place them on the workspace one by one.
• Layouts can be made by resizing and moving photos as individual elements or layouts can be row-based where you would work one row at a time and then move the rows up and down.

Assumptions

I’m the target user so I’m trying to think of assumptions that I can test with the prototype:

• I’ll be trying different numbers of images on each row
• I’ll be resizing images often
• I’ll know the basic order of images before starting

Whiteboard the user story

We want to show how the user will step through the prototype.

The idea is to draw a comic book that tells a story starting when the user opens the prototype and ending when they complete all necessary tasks.

Anyway, here’s the storyboard. A little confusing because the second frame is a zoom in of a single image showing the overlay of size options.

(Knapp links to Scott McCloud’s Understanding Comics: The Invisible Art. I ordered it right away and blasted through it when it arrived. Amazon’s user story for me would be “User sees an item he kind of wants, buys it because it takes just as many clicks to purchase than it does to close the tab.” Mission accomplished.

Oh and it’s a great book that I’ll write about separately in terms of how it applies to storytelling and design.)

Note: I brought my MacBook in for repairs right around here and as of writing this I still don’t have it back. But bad customer service stories are like poker stories. Let me guess, you were ahead and then you lost because of a card. So yes, you guessed right, I brought it in for support and support is taking longer than I thought womp womp.

Day 4 is for prototyping. This is the part of the process I was most looking forward to.

Jake Knapp recommends using Keynote. I went ahead and bought it on the App Store but didn’t dive in yet. Dragging elements around is so important to this prototype and I don’t think Keynote would be the most effective tool for that.

I also have wanted to try out Packery for a while. I also want to work with AngularJS again. This is a good opportunity to try new tools out.

That said, the goal of prototyping is to be able to have something to test with users. The goal isn’t to write pristine production-ready code. I do want to improve though so I’ll strive to write good code while getting things done. Skewed slightly toward just getting things done.

Prototype walkthrough

In the starting screen, you see the photos 4-across in a vertical arrangement. You can see the general order of all the photos.

Hovering over each photo reveals size options.

As photos are resized, the layout rearranges accordingly.

A quick battle royale

Going back to day 3 of the Google Ventures posts, Knapp talks about “best shot” vs. “battle royale”:

You can prototype several different approaches and test them against each other (the “battle royale”) or you can go with a single prototype (the “best shot”).

In this case, I explored an earlier idea of creating posts with rows in mind without drag and drop:

I felt that it wasn’t working and I abandoned it early—a luxury I have because I’m working alone on something where I’m the target user. Starting with all the images felt better to me. Still, it was useful to try out and I’ll have something to refer for a future project where switching images and classes in place would be effective.

Thoughts

Building in code allowed functionality that Keynote can’t provide, specifically drag and drop. (I think, at least, because recently I’ve seen it do things I also didn’t think were possible.) Though I see why not getting into the details is so important. Sometimes it’s more fun to put polish on but the polish won’t help answer questions.

Choosing to build with tools I want to try out means extra time is needed for learning parts of the tools themself. I’ve never used AngularJS and Packery together. Working alone, the time constraint was more flexible and, as mentioned, trying new tools in itself is important to me. With a group, it’s probably more important to use tools everyone’s already familiar with or can get up to speed with quickly.

I’ll try Keynote on the next sprint. This means creating something involving more screens. (In this project I skipped screens for things like adding photos and exporting to Markdown.)

cheap jerseys Google Ventures—Product Design Sprint Day 5: Validate:

Today, we test our prototype and learn which ideas worked, which didn’t, and what to do next.

The goal for the final day is to show your prototype to users outside of your company. In my case, the user was me. This is a cop-out and the next time I try a design sprint I’ll make something for others to try out.

Hello However, I still learned plenty by using the prototype to try and create posts. Here are a few key questions and answers.

Does drag and drop work for laying photos out?

Yes. Dragging photos around is much better than manually changing classes in Markdown posts and viewing it in the browser.

Is it better to start with all the photos on screen or add them one by one?

Thinking non-digital, I’d lay out a lot of photos at once and move them around. This translates to the interface I’m building. There doesn’t seem to be any advantage to working on ephoto at a time.

Is resizing with predetermined sizes a good idea?

Not so sure. And I think there’s better ways. The disadvantage is having to write the CSS classes to switch between. Packery provides a lot of flexibility so allowing any size with a corner drag might be worth trying out. On the other hand, the predetermined sizes allow me to stick to cheap jerseys a general grid system without thinking. Resizing would be something to focus on if I did another sprint for the same project.

When building posts by hand in Markdown and HTML, I think of things row by row, would this sort of flow work in the interface?

Working one row at a time didn’t work as well as starting with all the images on screen. The alternate prototype wholesale nfl jerseys in day 4 gave me pretty hard confirmation. Switching photos in place would be more useful if I didn’t already have a sense sequence. But I generally know the photo order because each post represents the order that photos were taken in real time.

Closing thoughts

Here’s a day by day review of each day.

Day 1: Understand – This translated well from a group activity to an individual. In a sense I just do what I would do with the group: research the problem and share my knowledge. I lose the group insight. On the other hand, sharing through a blog post means I have to spend time thinking and organizing thoughts for the world to see.

Day 2: Diverge – I loved this. Generating ideas is fun and effective even without a team. For the next sprint, I’ll consider doing more activities for generating ideas or doing the same activities for more stories.

Day 3: Decide – I really like the idea of storyboarding everything so that you know exactly what to build for the prototype. I’ll try something involving more screens the next time I try a design sprint.

Day 4: Prototype – I like building things and it’s great to get to the prototype step and have a really good idea of what’s going to be built. With nearly everything thought through, I was able to focus on learning trying out new tools.

Day 5: Validate – I was making something for myself and tested on myself. Not exactly in the spirit of the original design sprint, but I learned lots of useful information.

I plan to do more personal sprints in the coming months. Altogether, including the blog posts, it’s great for practicing design, programming, and writing. The constraints set an end point and I can ship and move on.

This first go was a little rough since some things translated better from group to individual. I’ll iterate on this personal sprint process. I’ll try different timing to focus on certain steps or try out different tools. For instance, maybe I can try a phase after prototyping to drill into animations and more aesthetic aspects.

And I’ll spend more time writing a shorter letter.

I’d be glad to hear any feedback on Twitter: @makeshowlearn