Design Sprint III: Prompts


Like plenty of other people, I have a backlog of project ideas. This list of ideas is long enough—because being a good idea isn’t a requirement—that I know I’ll never get around to building them all.

Design sprints are a great way to work through an idea enough to know if it’s a good idea or not. It’s either worth pursuing further or it’s not. Either way, having a prototype in hand is enough that I feel good knocking an item off the giant list of ideas.

Back up, what’s a design sprint?

I’ve previously written about two design sprints:
A Personal Design Sprint: Photo Blog Interface (
Personal Design Sprint II: Food Tracking (

I based those posts, and will base this one, on methods outlined in a series of Google Ventures articles about design sprints written by Jake Knapp:

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.

That series of posts focuses on running design sprints in groups. I run the design sprints alone for my personal projects. Some of the activities don’t translate well from group to individual, but this is how the phases break down for me.

(Each phase name links to the original Google Ventures post.)

  1. Understand: Existing solutions and a user story.
  2. Diverge: Sketch. Sketch. Sketch. Crazy 8s and 3-panel storyboards.
  3. Decide: More sketching. User flows and detailed storyboards.
  4. Prototype: Build.
  5. Validate: What worked? How can we improve?

In the past couple months, I learned to use Form and also tried creating a prototype every day with Framer. These projects were great for gaining proficiency with tools, but the time limitations meant I couldn’t explore ideas thoroughly.

Design sprints let me do that deeper exploration, so I’m planning to run some from my ideas list: starting with this one.


Prompts is an idea I’ve had for a daily writing app. It would provide just the right amount of structure for writing every day. And you would tailor the prompts so that you’re writing about things you’re interested in.

The goal, with more floaty words: Make it fun to write every day.

Why daily writing?

Writing is a valuable skill. Knowing how to organize your thoughts translates well to other disciplines—programming, for instance. Plenty of our communication takes place in writing. Mattan Griffel wrote much more in “How to Develop a Daily Writing Habit”:

I use my daily writing as a way to think out loud, troubleshooting problems, thoughts, and anxieties I have. It gives me something to look forward to in the morning and actually puts me in a really good mood.

I feel the same way about writing in the morning.

Why prompts?

Prompts are really helpful for avoiding writer’s block. Sometimes the biggest barrier to writing daily is thinking about what to write. Freeform writing can help get the faucet going, but it’s also nice to put those words toward something structured.

I’ve been reading about techniques for writing consistently and hitting daily word counts. There’s always an emphasis on planning out what you’ll write before writing. And it’s something we learn in middle school. Outline what you’ll write, then write.

Looking at outlines another way, they’re sets of prompts to work through. A daily series of automated prompts could help develop a daily writing habit.

(Medium even has a Writing Prompts collection.)

Spoiler alert
This post is pretty long so here’s the prototype I ended up with. I made this prototype with Framer, and an earlier iteration is made with Keynote.

(Click to view demo)

The rest of this post explains everything leading up to it. Let’s get to it.

1. Understand

Existing solutions and a user story


Jake Knapp (from Google Ventures) details 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.

In my case, “the rest of the group” is anyone who reads this. Here’s what I currently know.

What problem is it solving?

I’ve tried writing daily for the past few years. Like a lot of habits, I’ll get on pretty good streaks then stop and go again. When I look back on what I’ve written, I always wish I didn’t miss any days. Even if it were just a few sentences. The time invested isn’t much and the return is so high.

Getting rid of as much inertia as possible

I like my current workflow for daily writing (we’ll look at it soon), but sometimes I don’t want to fire that system up. Or think of what to write. I’m trying to get rid of as much inertia as possible.

Increasing variation in my writing
Prompts in my current system are the same each day. This is good because they’re straightforward (“What’d you do yesterday?”) so I can get the ball rolling. But it’d be nice to have structure with some of that variation.

Existing Solution: iA Writer + TextExpander

Here’s my current writing workflow: open iA Writer, use TextExpander to automatically write out daily prompts, save the file with a timestamp, then start writing.

iA Writer doesn’t have many features—that’s its main feature. You can’t select fonts. Or even change text size. And it’s great. I enjoy writing on Medium for similar reasons — I don’t get distracted thinking about CSS tweaks.

iA Writer does have some features. One I really like is Focus Mode, which keeps your cursor in the middle of the screen and highlights the current sentence by graying out other words.


TextExpander works behind the scenes. You type a shortcut string and it’ll change it to a longer string or a block of text, depending on what you set. (It can do more through scripting but I only use its basic functionality.) On mornings when I write, I type “;newltf” and it writes out my daily prompts.

TextExpander and iA Writer together


Existing Solution:

750 Words is a great web app focused on daily writing. You log in and it takes you right to today’s blank page. If you’re already logged in from earlier, you go to and just start typing.


Some other things I really like about 750 Words:

  • Emphasizes privacy
  • Encourages streaks
  • Shows word counts
  • Auto-saves
  • Disables editing on old writing

Without sharing and editing writing from previous days, you’re able to focus on today’s writing. I used 750 Words in past years for some stretches and really enjoyed it.

Sketch the most important user story

After looking at the existing solutions, I want to combine the automation from my current writing workflow and the focus on writing that 750 Words has.

Four user stories come to mind:

  1. I want to see a prompt and write.
  2. I want to create a set of relevant prompts. (Onboarding)
  3. I want to read old entries.
  4. I want to export entries.

Writing is the core idea so we’ll focus on the first user story. Having the prompts automatically appear is important.

Here’s the user flow for “I want to see a prompt and write”.


2. Diverge

Mind map, Crazy 8s, and a storyboard


In the Diverge phase, we’re thinking of as many approaches to a solution as possible. No idea is a bad idea right now. We use a few sketching exercises to help generate ideas.

Mind map

With the mind map, I mostly jotted down features this app might have:

  • If it’s a prompt you want repeated, you’ll be able to see what you’ve written for the prompt in the past, instead of a blank sheet. De-emphasized in some way like lowered opacity.
  • Different prompts depending on the time of day. “What do you want to accomplish today?” will show up in the morning and “What did you do today?” will show up at night.
  • Daily and dynamic prompts. You’ll get the same prompts every day. But some prompts are dynamic and themed in some way to provide variation in writing.

I wrote some notes saying “magic” and “pen & paper”. With magic, this app would know exactly what you want to write about. With pen and paper, you’d have a reference sheet with prompts or copies with daily prompts to fill out.

Crazy 8s

In the Crazy 8s exercise, you sketch 8 ideas and have 40 seconds for each sketch. Here’s what I came up with.



  1. Current prompt with old entries of the same prompt below set at lower opacity.
  2. Keyboard open. Current prompt at top and typewriter type scrolling below
  3. Today’s stats showing how many words you’ve written and how much time you’ve spent writing. Displays prompts you’ve written in.
  4. Card view showing prompts you’ve completed today and remaining. Labeled the choice paralysis version.
  1. Card view where you can swipe between prompts and fill things out.
  2. Different prompts for morning and night.
  3. List view. Some prompts are numbered. (“Three things you’re excited about.”)
  4. Card view again with today’s stats on screen.


In the Google Ventures article on the diverge step, Jake Knapp recommends a three-panel storyboard:

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

Here’s the storyboard for the writing task.


First you open the app. The prompt is at the top of the screen and the keyboard is open ready for input.

Then you start writing. As you move down screen, the prompt goes away. It could just scroll off screen or it could turn into a menu or display stats. Or both?

Then you finish writing. The keyboard slides down. The entry pops back and is a card showing the prompt. It slides to the next prompt and the keyboard slides up again, ready for input.

3. Decide

Assumptions, conflicts, and a detailed storyboard


In this phase, we narrow the our ideas down and pick one to prototype. We look at conflicts, state our assumptions, and then create a storyboard that acts as a spec for the prototype.


There aren’t a ton of conflicts that come to mind.

Hiding the prompt while writing vs. changing it into a menu or stats bar. We’ll just hide it while writing and give some more thought to how we’ll minimize the keyboard and show stats.

Word count vs. time writing vs. completed prompts. People who write daily often shoot for a word count or block off a certain amount of time.

We could also focus on completing prompts. But if I write one sentence for a prompt, do I mark that as complete? I don’t want to have to explicitly mark prompts as complete or not.

We’ll display total word count without explicitly setting a goal.


The user set their prompts already. Earlier, I mentioned setting prompts as one of the possible user stories. We’re going to assume they’ve selected prompts already. This isn’t their first time opening the app.

Users are okay with a mobile-only app. It’s easier to write long pieces on a desktop. But I’m definitely okay writing a paragraph or two on the phone. I do this for emails and in texts that get responses like “k”.

You’ll be able to write a paragraph here and there through the day. Actually, let’s turn that into an assumption.

Users will go into this app a few times a day. Since it’s a mobile app, it’ll be something you open when you have a little bit of downtime somewhere. The same way you open Twitter and start scrolling. But it’d be primarily for creating content instead of consuming content.

Users want privacy. We won’t be thinking about social options at all. Sharing will be roundabout—export or copy an entry and use another app to share. And we won’t be taking a look at that right now, either.

Detailed user story

Jake Knapp explains storyboarding the user story in Day 3:

Now we’re going to make a storyboard that shows exactly how the user will step through your prototype, click by click. This storyboard will become the spec for building the prototype.

Here’s the storyboard for this user story: I want to see a prompt and write.


You open the app and it shows your prompt. The keyboard is automatically active (like it would be when replying to a text) and you start typing. As you move down the screen, the prompt disappears. If you start scrolling up and down, your stats are shown.

There’s a button for when you’re finished with the prompt. The keyboard slides down, your writing pops into a card view, and it slides to the next prompt. The keyboard comes back up and you can start writing again.

We’re ready to prototype.

4. Prototype

Let’s build something


I’m trying a different prototyping workflow to see how well it works. I’ll start with Keynote to prototype the general flow, mostly sticking to elements included in the Keynotopia UI kit.

I think I’ll learn quickly from the Keynote prototype and then move to Sketch/Framer to create an interactive version. (I’m almost as interested in seeing how well this process works as I am in seeing how well the prototype works.)


I’ll try working fast here. Just like with sketching, I don’t want to get too caught up in details. The copy is from the New York Times—Louis CK Performs at Madison Square Garden.

Some odd artifacts around the prompt text. Not a part of it!

(Download the Keynote file)

I kept a few notes of things learned while making this prototype.

  • A paragraph doesn’t take up much screen space. You might not type enough for any scrolling to occur so the prompt is always visible. This is fine.
  • I made this in less than an hour. There were tweaks here and there that I won’t need to think through in code. I think it’s pretty valuable before moving to Framer.

Sketch + Framer


I used Sketch and Framer to create an interactive prototype. Looking at this GIF, it’s pretty much the same flow we have in the Keynote version.

After getting the minimal flow working with Framer, some things became apparent:

  • There should be a view where you can scroll through the prompts so it isn’t so linear.
  • It might be better to just swipe while editing to go from prompt to prompt. It’d be great to do this while still making it clear that you’re in a card hierarchy.

Sketch + Framer: Part 2

I made a second version to address the issues that came up. In this phase, you can go from the editing view to the card view and swipe from prompt to prompt.

After building this, some other things became apparent:

  • You shouldn’t be able to edit while in card mode. (I’ll need to set the HTML attribute contenteditable false when in the card view.)
  • It could be interesting to start at a random prompt to further keep it from feeling too linear.

Sketch + Framer: Part 3

So I made a third version to address those issues. And remembered that I’d be sharing a demo so I should clean a few other things up.

  • I added LocalStorage so you can save your writing.
  • Added the ability to tap the keyboard to move to the next section without going to the card swipe view. (To simulate pressing ‘return’.)
  • Added some prompts and mocked up what the dynamic prompts would look like.

(Click to try the prototype out)

After building this, even more things became apparent:

  • I need to stop.
  • It’s time to move on.

5. Validate

I didn’t run a formal user test, but I tried writing my usual prompts through the day. Also, each iteration acted as a mini validation step. Here are some things I learned:

  • Automatically activating the text areas was really important. It’s one of those, “of course it is” things. In the earlier version, you have to tap to start typing again. And it gets annoying fast.
  • Activating at the end of the text area is also important. Otherwise, if you’re continuing a previously edited prompt, you need to tap the text area anyway. This also gets annoying fast.
  • When in the card view, it’d be better to tap the text area to enter that prompt instead of needing to tap the colored prompt area. We’d need to differentiate between a tap and the start of a swipe.

Key questions and answers

Does the user flow make sense?
Yes, it’s fairly simple to navigate between prompts to fill in the one you’re currently interested in.

Would this help create a writing habit?
My goal was to make it fun to write every day. This isn’t quite there, but it’s in the right direction. I think there’s a lot of room to increase user delight without going crazy trying gamify things.

I’m satisfied with the core experience and we can enhance it without trying to paint completely over it. Each time you write, it’d be cool to show how many words you’ve added to the day’s total. Showing a chain of days and prompts completed would also be good. “Don’t break the chain” is always a good motivator.

I mentioned the idea of dynamic prompt sources that you’d subscribe to, follow, or whatever the best word would be. In the final prototype, I have a couple examples that I pulled from daily email prompts I currently subscribe to from One Month and The Write Practice.


Other sources could be the Medium writing prompts collection I mentioned earlier. Or news sites—you’d see the top headline and write your reaction to it. These dynamic prompts give the user a little more to look forward to each day. The dynamic prompts help generate anticipation.

Would I write more using this?

I think so. I can go in and write for a little bit without thinking about what to write about. And it demonstrates how writing in small chunks can quickly add up to something significant.

I’m a little OCD about keeping my writing consolidated. If I’m trying to write daily, I’d like to keep all that writing in one place. In my case, I keep Markdown files in a Dropbox directory. To really buy in and use this all the time, I’d want to have a good way to export the content or have a desktop web version.

Is the two-prototype process—one Keynote prototype and one Sketch/Framer prototype—better than sticking with one tool?
I liked this combination a lot. Keynote lets you build things very quickly to get a good sense of if the user flow makes sense. Skipping the Keynote step would be almost silly because it has such a great ratio of time invested to things learned.

Framer prototypes take longer to build, but you can really see if a gesture feels right or not. It’s less constrained so there’s also more room to get caught up with details that aren’t important yet. In this case, text-input and navigation between prompts were important.

Framer prototypes are better for sharing because they’re web-based. Sharing online is great for personal projects where I’m less likely to run in-person user tests.

You always want to use the right tool for the job. I have a better sense now of what I can do with Keynote and Framer and in what amount of time. This will help me pick the right tool or combination in the future.

Closing notes

Speaking of using the right tool for the job, the design sprint is a great process that can be applied to a lot of situations. In this case, we used it to kick off a new ideas and see if it’d be worth building out further.

I have a few other ideas that I’d love to run through design sprints. As always, I’ll be sure to share the process. Thanks for reading—I’d love to hear any feedback. Reach out on Twitter: @makeshowlearn


Google Ventures Library

My first personal design sprint


Design Sprint II: Food Tracking

Note: I originally posted this on Medium on August 3, 2014. It still looks better there.


About my first sprint

In my first personal design sprint, I explored an interface for creating photo layouts. It was based on a series of posts by Jake Knapp (@jakek), which you can find in the Google Ventures library.

Each sprint breaks down into five days:

  • Understand
  • Diverge
  • Decide
  • Prototype
  • Validate

The design sprint was great for establishing an end point and reaching it. Initial excitement for new side project ideas is always really high. Starting is easy. It’s even easier to abandon a side project for the next exciting idea that comes along.

Jake shared my post on Twitter (thanks a million), then Smashing Magazine shared a link on Twitter (and Facebook) as well.

I wrote something that people read—which is terrifying and awesome and humbling. People gave feedback like, “I would just buy a WordPress theme on day 1 and go hiking and fishing on days 2, 3, 4, and 5.” But it resonated with others so I’m running it back.

In this sprint, I’ll be exploring a much different idea—food tracking vs. photo layout. However, the process will be similar except for a few changes.

I’ll be prototyping a native mobile app

The first sprint focused on a desktop web interface. Food tracking takes place throughout the day, and I likely have my phone but I might not be by a computer. I also just think designing and prototyping a mobile app would be good learning experience.

I’ll be using Keynote

In the first sprint, I built a JavaScript prototype using Angular and Packery. I think it was the right choice because drag and drop was so important. And I was focused on designing a single screen.

Google Ventures leans heavily on Keynote for prototyping. For this sprint, I wanted to try Keynote out so I picked a project with a broader user flow.

1. Understand

Let’s take a look at how I currently track food and how existing solutions tackle the same problem.


Why do I need this?

There are, of course, plenty of existing solutions to food tracking (we’ll take a look at a couple later). So why another one? I’ve tried web and mobile apps in the past and will use them diligently while early motivation is high. But the hassle becomes a bit too much and I stop after a few days.

I want to look at how I can make the experience of food tracking as unobtrusive as possible. Mostly by designing it to my specific needs—though I think others share the same mindset when it comes to food tracking.

How do I currently track things?

Most people are familiar with the concept of counting calories. Counting macronutrients (macros)—protein, carbohydrates, and fat—is similar but less common. You just set your daily targets and try to hit those numbers by the end of the day.

I like thinking of macros instead of calories because it’s more helpful when it comes to picking what to eat next. If I’m low on protein and fat for the day, I know to reach for the sardines instead of a sweet potato. Fewer options leads to easier choices. Which hopefully leads to actually following a nutrition plan.

Earlier this week, I put a monocle on and calculated my macronutrient (macro) targets—protein, carbohydrates, and fat. Then I tracked my food and counted macros in my workout notebook for a few days.

Counting wasn’t too bad. I bought my usuals at Trader Joe’s: ground beef, chicken breast, deli meat, smoked salmon, frozen vegetables, and frozen berries. Everything was easy to portion so I rarely guessed on servings.

With a notebook, hand calculated algorithms stayed pretty basic:

OUT WITH FRIENDS: add 9798 calories

What problems am I trying to solve?

I want to add items throughout the day with as little resistance as possible. Speed over accuracy at this point—I want to add items and refine the details later.

I open and close Messages more than any other app. In most cases (replying to someone), Messages opens with the keyboard active ready for input. I want that experience for tracking food.

I want to glance and see how many macros I have remaining for the day. With my notebook and other apps I can see how many I’ve consumed. But then I have to mentally subtract from my target to figure out what I really want to know: how much I have remaining.

I want to set different nutrition targets for different days. The nutrition plan I’m on has different calorie and macronutrient targets for rest days and workout days. Most solutions let you specify one set of targets.

Success metrics

Google Ventures uses the HEART framework to break metrics into happiness, engagement, adoption, retention, and task success:

To figure out what those are, you need to start at a higher level: identify your goals so you can choose metrics that help you measure progress towards those D7000 goals.

Again, I’m shooting for happiness. Engagement and adoption are better metrics when focusing on designing new features for existing products.

Retention and task success are relevant here, though. I’ll be able to get a feel for if I’d use this multiple times per day. And I’ll be able to count how many taps a task takes compared to other apps.

I’m not thinking about business opportunity right now. My priority is designing something that would be useful for me and it all comes back to happiness.

Lightning demos of existing solutions

One exercise Google Ventures recommends is the lightning demo—a quick look at existing solutions. You can learn so much from this step because someone else has likely designed solutions to the same problems. After extensive research, I’ve found I’m not the first person who’s thought about using technology to improve nutrition.

Here are some existing solutions:

Along with my notebook, I’ve been using MyFitnessPal app for the past few days. Fitocracy Macros seems to be doing a lot of the things I want to be doing. Let’s take a closer look at MyFitnessPal and Fitocracy Macros.

Lightning demo: MyFitnessPal

I’ve seen MyFitnessPal recommended pretty often. It works well. Adding a single item can take a few taps because you refine details on the spot.


MyFitnessPal shines when adding multiple recent items. When tracking food, I end up eating a lot of the same things. I imagine others can relate. MyFitnessPal lets you do this by multi-selecting and adding all at once.

Takeaways: I’ll be thinking about how users will add multiple items. MyFitnessPal also has a quick-add option for calories. You can use this option when you don’t want to do a database search or are just entering estimates. A quick-add option for macros could be interesting.

Lightning demo: Macros (by Fitocracy)

I’ve seen Fitocracy recommended pretty often for tracking workouts. I saw that they have an app for tracking macros, called Macros. Dick Talens, one of the Fitocracy founders, writes about nutrition, intermittent fasting, and strength training. I’m guessing that at least partially led to the Macros app.

2014-08-02 08.28.26

The main screen is a venn diagram showing remaining amounts of calories and macros. It’s simple and delightful.

This screen focuses on remaining values instead of current totals. I really like this. That’s usually all I want to know when deciding what to eat next.

Onboarding is straightforward. It asks a few questions about your goals and lets you select a similar body type from pictures. That’s it—you’ve set your macro and calorie targets, with different values for rest and training days.



You enter macro values directly instead of entering food items. Because of this, I think the app is good for people who have experience tracking their food and have good ideas of what’s in their meals.

(Note: The Macros App Store description says an upcoming version will take inputs from a food database. Can’t wait.)

Takeaways: Again, I really like the focus on remaining values. The onboarding process has me thinking about how users will set targets in my app. For this sprint, I’ll assume users have set their targets already.

User stories

From looking at other products, there are already a ton of ideas brewing. Especially because this sprint is for a new product and not adding cheap nfl jerseys a new feature to an existing product. We can design anything, but the design sprint uses constraints to stay focused.

It’s important to pick one or two user stories to work on. Here are some stories that came to mind:

  • I ate and I want to add meal items—quickly. (And dirty. Speed trumps accuracy here.)
  • I want to refine details on what I’ve eaten.
  • I want to see how many macronutrients I have remaining.
  • I want to set goals—not necessary to get more complicated than setting macro totals. This won’t calculate things for you the way Fitocracy Macros does.

Sketching out the user stories. Boxes and arrows.

Story 1 is ready for the next step. Stories 2 and 3 go together so I’ll combine them for the next step. Prototyping two stories is enough so I’ll drop story 4.

2. Diverge

Put that laptop away, it’s time to sketch.


I went to a coffee shop to sketch. I left my MacBook at home and brought my notebook and printer paper. The printer paper could’ve been enough alone—the notebook was more for notes for this blog post.

After dropping and combine user stories in the Understand step, we’re left with two:

  1. I want to add meal items.
  2. I want to refine details on items and review macro totals.

For each story, I did one diverge cycle: mind map, crazy 8s, storyboard. Here are the results with a few notes.

Adding items: mind map

Speed was one of the main things I thought about while doing the mind map. Other quick apps I use are Simplenote and Messages. I drew a small initial thumbnail of what the opening screen would look like.


Adding items: crazy 8s

For adding items, I started with the thumbnail from the mind map and looked at alternate layouts. Maybe you can pick from a grid of recently added items. Maybe recent items are shown with search results.

I also started thinking about arranging calorie and macro values next to item names.


Adding items: storyboard

In the Google Ventures article on the diverge step, Jake Knapp recommends a three-panel storyboard:

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


First you open the app and see the view with macronutrient information and your list of items. The keyboard is active.

Then you start typing. The macro counts go away and the item list expands.

Then the new item appears on the list and you can begin typing again to add another item.

Refine item: mind map

In the mind map for refining items, I thought about how the item list would differentiate between complete wholesale jerseys and incomplete items, how I could avoid bringing the keyboard back up, and how I might implement recent items.


Refine item: crazy 8s

I started looking at adjusting individual macro values then realized that doesn’t make sense. The app calculates those values based on portion size. I also started exploring how you could change between different specific search results.


Refine item: storyboard


In the single item view, the user first sees the item with the default serving amount. Below that are search results for the item.

Then selectors appear to adjust serving values.

Then you’re finished refining the value and you can return to the overview screen.

3. Decide

Assumptions, conflicts, and a detailed storyboard that acts as a spec for building the prototype.



There will be a food database. Looking up items is a major part of the app. I’ll assume we’ll have one available for actual development. In the prototype, we can still get useful information with a linear demonstration showing how a search might go.

The user knows their macronutrient targets and they are set already. The app will not automatically calculate target values. I also won’t be exploring onboarding and target setting in this sprint.

Users are okay inputting items without refining them on the spot. In other apps, I can be hesitant about adding items because I’ll also have to refine the details on the spot. I think it’d be great to be able to just add them and refine later.


Showing search results while typing vs. Staying focused on just adding and refining later. I think it’s really important to just jump into the app, enter items, then exit. I’ll add items and refine them in a batch later. I want to get rid of any resistance to adding items. So I’ll keep search results out while typing.


Using the default picker vs. Using a different increment gesture. I used Bit Timer to count down when doing the Crazy 8s exercise. It has a neat way to set activity and rest periods.

I thought it’d be cool to do something similar instead of the default iOS picker.

In this case I’ll stick with the default iOS picker. There’s already plenty else to think about.

Detailed user story: adding items

Jake Knapp explains storyboarding the user story in Day 3:

Now we’re going to make a storyboard that shows exactly how the user will step through your prototype, click by click. This storyboard will become the spec for building the prototype.

We want as few questions as possible when building the prototype. It’s important for groups to allow a divide and conquer approach knowing the pieces will fit together at the end. Working alone, it helps minimize context switching. No need to go from Keynote to sketching and back and forth.

Here’s my storyboard for adding items:


Muji has a great notebook de for storyboarding things that’s somehow only two bucks.

You start with an overview of macro values and previously entered items. The keyboard is open and active (like replying in Messages). When you add the item, the macro values go away, the items move to the top, and your new item appears. You can add more items or tap outside of the keyboard to return to the overview.

Detailed user story: refining items

Here’s my storyboard for refining items:


You start at the same opening screen and tap an incomplete item. Everything else disappears and the item name moves to the top of the screen, this is now the single item view.

Search results for the item appear along with a picker to set serving amounts. You select a specific item from the results and set macro values then you repeat on the remaining items.

4. Prototype

My first dive into Keynote for prototyping.


Fake it Till You Make it

I recently watched a WWDC 2014 Session video called “Prototyping: Fake it Till You Make it”—it’s excellent, go watch it. They (Jeffrey Traer Bernstein, Linda Dong, Julian Missig, and Mark Hauenstein) demonstrate their prototyping process, which boils down to make, show, learn.prototype

(There’s the origin story for my Twitter handle: @makeshowlearn.)

I was really interested in how they jumpstart a prototype using an existing app with similar functionality. In the video they start with Music and mask away elements and kind of trace over it to create an app about toast.


Stripping away nutrition info, the gist of my app involves adding items to a list. Reminders does this well so I used it as the base for my prototype.

Luckily, the Keynotopia iOS7 kit includes elements from Reminders. I combined those with the iOS Album boxes to create a base for the prototype. I set up some keyboard shortcuts (I followed Sketch default bindings for guidance) and then got my hands dirty in Keynote.

Keynote prototype: adding items


Here’s the first user story: adding items to the list. It starts with the opening screen where you can see macro totals and a list of today’s food. A couple of items are added.

I added the green dots next to item names during the prototyping stage. They mark items with complete details. When refining, you’ll work your way through the incomplete items.

A prototype for the first user story is complete: we can see how items are added. The end shows tapping “asparagus” to go to an individual item refinement view. It’s помещения blank other than the item name. We’ll take care of that in the next prototype step.

Keynote prototype: refining items


Here’s the second user story: refining items. It starts with the overview screen with the list of today’s food.

You tap back an item to view details. In the details, you can select the from search results and change serving sizes.

You can then swipe to the next incomplete item wholesale jerseys to do the same modification until you’re done refining all incomplete items.

I enjoyed prototyping with Keynote. I was able to translate most things from my head to the screen—sometimes it just took a bit of thinking. With a few more reps and getting better at re-using styles and animations, I think I’ll really be able to fly from spec to prototype.

5. Validate

What works? What doesn’t?

It’s important to try prototypes out on the actual device they’ll be used on. I exported the stills from Keynote and checked them out on my phone.


With still images, you lose the transitions from screen to screen but you can still learn a lot. You can see if tap areas are big enough, if the text sizing is right, if the color scheme looks okay, how clear it is what you’re supposed to do next, and plenty more.


I partially lost my mind trying to get the exposure and focus correct on this.

Tools like Flinto and InVision let you create interactive prototypes from stills. I didn’t get a chance to try them here, but I’ll take a look at these for future projects.

Key questions and answers

Would I open this multiple times each day? I think so. Adding an item is as quick as replying to a text in Messages.

Does refining items in batches work? I think so, though I probably need a more interactive prototype to really answer the question.

In the original item refinement flow, you refine an item, go back to the item list, tap another item, refine, go back to the item list, etc. Creating this in Keynote was repetitive so I figured that would translate to a repetitive experience for users.

I added the swipe to the next incomplete item which I think would work well.

Can I glance and see what macros I have left? Yes, this is clear. The opening screen is ready for item input, but it also displays remaining macros.

However, this prototype doesn’t address how incomplete items should affect the remaining macro count. My gut is to just have items default to one serving and whatever the first search result is. I would address this issue in a future sprint.


I would use this. And I understand I’m very very very biased. But really, I think the user flow works really well for how I track food.

A Sprint lot of it would depend on how good the food database is and how well search works. Assuming those were good (which I know is a major leap and would be design exercises on their own), I’d use this app and I think others would too. I’m wholesale MLB jerseys happy with how it turned out.

Closing notes

I think design sprints are great for personal projects. Again, it was great to have the constraints to keep moving forward. I came up with ideas, brought the better ideas to life, and saw what worked and what didn’t. I learned a lot.

I think the process will only become more effective as I apply it to more ideas. I hope this was interesting, helpful, and hopefully both. Thanks for reading and if you have any feedback or just want to reach out, I’m on Twitter at @makeshowlearn.


Google Ventures Library

My first personal design sprint


Personal Design Sprint

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

Day 1: Understand

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: Diverge

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.


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: Decide

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.


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.)

Day 4: Prototype

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.


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.)

Day 5: Validate

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