Jumpstarting your app conception without sketching any UI
Tentacle maps, a quick & easy way to scope your app or product.
Content is king
Earlier this week, I really enjoyed reading Writing-first Design by Jonas Downey (same initials, same last name, no connection) 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 (design sprints for the win!), 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 guard the scope of a nascent idea small and 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 log-in users to an app, we would be looking at mocking up the UI as below:
Introduction
[Sign up] [Log in]
New?
-Name
-Email address
-Password
[Sign up]
OR
Welcome back!
-Email address
-Password
[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#1 — A 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#2 — Action 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 less choices makes it easier to decide, I like to colour 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 to map additional inputs & touch-points. Currently, I use it to visualise more complex inputs that may take more time for the user to go through.
From this schematic, you already have a pretty good idea of the scope of this feature : how much screens this will need and what type of input will need to be displayed.
Step#3 — Mapping the flow
This step is about adding the connection between the screens and inputs we mapped. Visualise 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.
Now we have a flow diagram that shows the number of screen required, the controls we will need and the different paths through the application.
Benefits
Fast!
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.
Counting
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.
Visual
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.
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 is 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.
This is my first post on Medium ! I’m excited and would love any feedback on tentacle maps. I’ve used this approach to map competitor user flows, counting taps to make our apps more to the point and efficient, scope out requirements for new features to existing apps or to scope new apps and start mapping their flows.
Is anyone else willing to putting this idea to practice?
