Jumpstarting your app conception without sketching UI

Content is king

In the Innovation Group, our job is to come up with new ideas or find out how to solve problems and develop ideas and solutions continuously. How does design deal with such a high turnover of ideas and construct MVP apps?

Earlier this week, I read Writing-first Design by Jonas Downey about using writing to start designing. I find using plain text to start giving shape to an app or concept a very time efficient solution. It works especially if the concept is crudely defined or changing as there is no room for anything else than the content.

Working with very disposable & raw ideas, I’ve came to use this approach along with what I call tentacle maps to flush out app ideas. I found this technique useful to build a common understanding of the app idea and guard the scope of a nascent idea small so we can make product decisions without actually sketching any UI.

The tentacle map (a twist on wireframe flows) is simply about visualizing the screens you think the app must have for the concept to work and connecting these together based on the features. It can be used to scope out a full product like an app or work on additional features and flows.

So as a basic example: if we need a way to sign-up or login users to an app, we would be looking at mocking up the UI as below:

[Sign up] [Log in]
-Email address
[Sign up]


Welcome back!
-Email address
[Log in]

So now we have the initial content to build up this flow.

I know about the content, now what?

Continuing with our need to sign up or log in users, we can see from our copy that users would be looking at a first screen to choose whether they already have an account or if they need to create one. Then they will move to either a screen that allows users to enter their login information or a screen to enter their information to sign up.

So we now know we would need at least 3 different screens.

Step#1A box per screen

We represent each screen with an empty container and label them with the title of the screen we determined from our writing exploration.

Step#2Action points

The next step is adding the interaction points: taps or clicks that will allow the user to accomplish his goal.

I create a circle for each tap necessary for the user to go through the screens. If the user needs to do a couple of associated inputs, like entering his name, email and a password, I visually chain them together.

As an added bonus since I believe fewer choices makes it easier to decide, I like to color code the different inputs.

Blue is the simplest choice possible, the logical prominent next step like our [Sign up] under the registration form.

Green is a multiple choice that implies the user making a decision like the user telling the app whether he wants to sign up or whether he wants to log in.

Purple allows mapping additional inputs & touch-points. Currently, I use it to visualize more complex inputs that may take more time for the user to go through.

Step#3Mapping the flow

This step is about adding the connection between the screens and inputs we mapped. Visualize all the possible user paths as arrows.

In our example, we have two different inputs for the user to continue: [Sign up] or [Log in] but the user will only select one of those options so that is one dot to plot on the introduction screen. This tap on an option will either to New? or Welcome back! so we can draw a green (multiple choice) arrow from the introduction tap to the two next screens.

On the New? screen, continuing forward by tapping on [Sign up] will lead the user to the app’s main page. Similarly, continuing on the Welcome back! screen, continuing forward with [Log in] will lead the user to the app’s main page. So we plot a blue dot on each of these screens. Then draw a blue arrow from those screens leading the user into the same screen of the app.



This approach allows building a visual representation of the scope of the app that provides an overview of all the screens necessary, allows to create low fidelity prototypes and plan the work ahead if we choose to commit to the app idea.

In the Innovation Group, we can tell at this point if the idea is worth iterating on and assigning more resources to.


So without investing too much time nor delving in the UI patterns, we can have a high level overview of our app idea to discuss with stakeholders and development.


Each required tap in your service is represented by a dot so you can count how many taps or clicks a user has to go through to accomplish his task.


Now this is why I thought tentacle map was an appropriate name: as your app become more complicated, it may start looking like a knot of tentacles; if so because the approach is very visual, it looks like screens are rapidly multiplying to invade your project.3489211430_d491508d6a_z

This approach allows you to adjust the scope in a lean way without having to create UI to prove there is some major feature creep crawling its way in.

Content talks

This approach is all about the concept and scope so there is no bias due to the layout or the “exact copy”.

Anyone can do it

There are no sketching skills required! Drawing out UI sometimes demotivates product owners & team members from explaining. Using only text and a high-level map we can exchange ideas altogether.


Disclaimer: All opinions are those of the author and not those of AVG or Innovation Labs.


Jessica Downey

Hey Don,

I actually try to do a global flow for settings that will encompass all settings. Hope this helps.


Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.