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