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 (franciscortez.com)
Personal Design Sprint II: Food Tracking (medium.com)

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

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: 750words.com

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 750words.com 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.

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.

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.

Conflicts

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.

Assumptions

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

Keynote

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

Resources

Google Ventures Library

• The product design sprint: a five day recipe for startups
• The product design sprint: setting the stage
• Day 1: Understand
• Day 2: Diverge
• Day 3: Decide
• Day 4: Prototype
• Day 5: Validate

My first personal design sprint

• Personal Design Sprint
• Personal Design Sprint II

Others

• thoughtbot—The Product Design Sprint
• thoughtbot—Design Sprint Case Study: Merck Development Portal
• WWDC 2014 talk on prototyping (a portion focuses on Keynote prototyping): Prototyping: Fake It Till You Make It
• Keynotopia

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.

This is so cool: @makeshowlearn did a 1-person design sprint and documented each step in detail: http://t.co/O7pzTw4OCB

— Jake Knapp (@jakek) July 6, 2014

What if you started a design sprint for your own personal projects? A nice system for creative endeavors: http://t.co/N72utFsIsN

— Smashing Magazine (@smashingmag) July 9, 2014

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:

• MyFitnessPal
• Macros (by Fitocracy)
• FatSecret
• LoseIt!

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.

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.

Assumptions

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.

Conflicts

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.

Happiness

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.

Resources

Google Ventures Library

• The product design sprint: a five day recipe for startups
• The product design sprint: setting the stage
• Day 1: Understand
• Day 2: Diverge
• Day 3: Decide
• Day 4: Prototype
• Day 5: Validate

My first personal design sprint

• Personal Design Sprint

Others

• WWDC 2014 talk on prototyping (a portion focuses on Keynote prototyping): Prototyping: Fake It Till You Make It
• Keynotopia