As a web designer, prototyping in one way or another is inevitable. As soon as you set pen(cil) to paper and draw your first sketch, you’re in essence creating a prototype. It’s your way of rapidly testing ideas.

Obviously there is more formal prototyping that can take form in a range of ways. There’s a lot of blog posts out there to help you understand what level of prototyping you need. This one does a great job explaining visual, functional and content fidelity.

Our Prototyping Journey

Like most, our journey started with pages and pages of sketching on paper. We hashed out idea after idea, threw it all away and started again.

Eventually we got to a point that we were happy with our humble sketches but we needed to see a holistic view of the structure.

So we jumped into (Sketch) to start visualising the flow as wireframes. These were great, it seemed like the flow was perfect and we were on our way to success.

To really understand user flow you need to experience it. So we threw our static wireframes into (InVision) and connected them up with hotspots.

Immediately we realised it just wasn’t working. The original long and elaborate structure was simply too much. Originally designed to simplify creation of a complex problem, it had become complex itself.

Leave Ego Behind

As a designer it’s easy to get attached to your ideas and designs. If you’re reluctant to throw away a design because of emotional attachment or amount of time you spent, you’ll end up with a half-ass design.

So we threw away our wireframes and took another approach. Repeating the process and getting to a state where the wireframe prototype was working well.

Next step is the full resolution designs and high fidelity prototypes. We used Invision again to make this prototype but as soon as it came time to tweak the design, we ran into a problem with the process.

Problem with Mockup Prototypes

The issue with creating high fidelity prototypes using InVision is that it relies on exported mockups, which makes iteration time consuming. This is because for a seemingly small change, you have to: *make the change on every mock up screen *re-export *apply exports to your prototype *pray the hotspots all still match up

It became clear that in order for us to really nail the flow for this feature we had to go deeper with more fine level control.

Where To Go From Here

It depends how far you want to go in perfecting the user flow and experience.

If it’s a small feature, maybe you can get away with scheduling it for implementation and then tweak it with the devs.

However if you’re designing a large feature or maybe an entire product, then that’s an insanely stupid risk you shouldn’t be taking.

HTML Throwaway Prototype

In order to really nail down the user experience a HTML throwaway prototype is an awesome tool. It means literally hacking together the interface in html/css/js without any real functionality such as saving state to a server.

I really want to emphasise that you should create the prototype with all intentions of throwing it away. This will allow you to machine through the coding process by writing the most disgusting css/html/js that you can imagine. The dirtier the better! The only thing to focus on is speed and output. If it’s quick and behaves like the expected product, then that’s all that matters.

Test, Modify, Rinse and Repeat

Once you’ve hacked together your prototype, get as many people to use it as possible. Get feedback, make changes and then do it all again.

This allows you to validate/expose issues in the design that cause confusion to the user. As soon as these come up, fix them and do it again.

Doing this, you’ll be able to weasel out all UI issues in the experience in an extremely short amount of time.

Be A God

When running people through your prototype you want to be able to watch how every single user interacts with your UI. The best way to do this is by using (Inspectlet) to record your testers. Inspectlet records the user interacting with your prototype and allows you to watch it back as many times as you want.