Issue #7: Prototyping 101 (plus a superb owl)

Feb 18, 2023

Reading time: 5 Mins

In issue 5 we discussed how to execute on an idea, and step 2 was to build a prototype. Today we explore that concept in detail.

This is the advice I wish I had before I went to build my first app…

How not to do a tech start up

The first true tech start-up I attempted to build was Netwrk: a professional networking app that scanned peoples business cards using OCR and generated a QR code so contact info could be swapped quickly (this was a couple of years prior to LinkedIn integrating the QR code feature).

As two university students we did exactly what we thought tech start-ups should do: Build an “MVP”.

How did we do this?

We found third party developers who said they could build something for us.
We haggled them down to the bear minimum price without a scope of work.
We then worked stuff out on the way through like new features we needed but fell outside of scope.

The result of this process was a fraught relationship between me and my cofounder (eventually dissolved the company), a pissed off development team and a barely functional app that didn’t go anywhere.

What we should have done was designed the app first then built it with code.

Here’s how step by step:

Step 1: List out all the features you want

The app idea in your head is usually made up of a number of features that your end users will want.

Making a list of these will help solidify these functions.

You’ll then want to rank this list from most needed / wanted to least.

Let’s look an example.

Say we are building a simple to-do app. Here is a list of features I would like:

Log to-dos in a list form
Mark something as done or complete
Log in so I can save any information
See my list on multiple devices
Integrations to other software e.g. slack, so I can access to-dos from there

Using the MoSCoW scale, we can split the features out into must haves, nice to haves, could haves and won’t haves we get a priority list:

Must have
- Log to-dos in a list form (reasoning: you just need a place to write something down)
- Mark something as done or complete (reasoning: one step better than just writing is marking something as done)
Nice to have
- Log in so I can save any information (reasoning: logging in is nice but not essential - info could be stored locally)
Could have
- See my list on multiple devices (reasoning: this is dependent on logging in)
Won’t have
- Integrations to other software e.g. slack, so I can access to-dos from there (reasoning: this is a big piece of work requiring a lot of development so this can be reserved for a v2+)

Step 2: Mock-up each page on paper

The next step is to turn the priority feature list into mock-ups for each.

My best advice here is get a piece of paper draw out what each feature could look like in an app.

At this point you may want to add a bit of design and you can get inspiration from sites like Dribbble but also existing apps.

“Good artists borrow, great artists steal.” ~ Pablo Picasso (probably)

Paper prototyping is actually more of a widely done practice than most know. Here is an example of a new flight search engine:

Complete guide to paper prototyping - Justinmind — Via Justinmind

The great thing about doing the paper version is that it’ll really force you to nail down your core requirements for the build and bring the idea in your head to life.

Step 3: Work out the user flow

You know have an idea of what your app looks like on a page but what next?

Well this is the last step to a functioning prototype… and it’s very simple.

Take a photo of those drawings and add to Figma (complex), Invision (easier), PowerPoint (easiest).

If you’re using Figma or Invision you can now link the app pages together

This video goes through the steps in detail:

If you are like me and prefer PowerPoint you can use a large slide to draw arrows between the various screens.

Creating wireframes and low-fidelity prototypes in Figma for the Google UX course | by Rachel Lang | Bootcamp — Something like this (Credit: Bootcamp)

It won’t be interactive but it will do the job of explaining how the user will flow around the pages.

You’ll now be ready to show off the working product to get some early feedback.

Bonus step: Add some design flair

Thought this was quite a cool example of how you could take the paper prototype into something more polished with/without the help of a designer.

Conclusion

Design prototypes bring a concept to reality without hiring an expensive developer team to guess their way to a solution.

We will talk about how to brief a product to a dev team in a later issue.

Suffice to say the above steps will provide the basis for any discussions you have and help focus your time and effort in the next stage of the start-up journey.