Should I prototype?

Ryan Von Ess
May 18 · 6 min read

Prototyping data visualization and navigation

Everybody loves a good prototype! A tangible, clickable design that almost feels like the real thing — except it isn’t. It’s the best it gets without any code being written. But when do you build a prototype? Prototyping is a lengthy process and so you have to ask yourself: What will my prototype achieve that the designs won’t be illustrating anyway?

Image for post
Image for post

When to prototype

The first question to ask is: does a working example of what I’m developing exist? If so, then you’ve essentially got a prototype, or prototypes of the various features you’re trying to showcase. If that’s the case, whip up your designs, use your existing references to get your client go-ahead, and shoot it over the devs. Done and dusted.

But what happens when you’re working on something novel and unique? Or you’re trying to break the mold? If either of the above applies to you, it’s time to build a prototype.

At TouchFoundry, attempting the unattempted is a daily occurrence. Not long ago, a client needed us to update, reboot and mobilize (by which I mean, make mobile-ready) their existing desktop app. What did this desktop app do? Only aggregate and visualize mountains of medical data! But with the realisation that ‘dashboarding is dead’ the client wanted a next-generation solution, one which aimed to not only report data, but deliver actionable insights to the right people at the right time. A data analyst could sift through database queries and make sense of what they saw, but the same results weren’t translating to something meaningful to stakeholders. It was up to us to reinvent the way the app’s data was presented, and because we were stepping into unchartered territory, a prototype was the only logical way forward.

Prepping for prototyping

Image for post
Image for post

Your boxes are ticked and your heart is set on building your prototype — what’s next? Your top priority now is to make sure you don’t waste time hitting dead ends and messing around with unnecessary features. Make sure you’ve got a handle on your designs, workshop your UX from both a technical and end user perspective with your client, or simply put, make sure you’ve got your ducks in a row before you even look at putting together a prototype.

Rough rule of thumb, you need close to double the amount of time thinking through what interactions and flows you need to prototype as you do creating the prototype itself. And it goes without saying, include the designer responsible for creating the prototype in these discussions; they are, after all, providing the framework that you’ll be bringing to life with your prototype.

We had a lot to consider when thinking of new ways of presenting our client’s medical data, most notably, how to make it all come together on mobile. This was a mobile app first and a desktop app second, so a lot of thinking went into how to optimize the limited real estate that mobile screens provide in a way that ensured a delightful user experience.

Separately, we also had to figure out how the network of data would be traversed. When you’re searching for patterns in data, being able to jump from one data set to another in an intuitive manner becomes a core function, so a lot of consideration went into laying out how users would navigate through this landscape of information.

But UX was only one mountain to climb. We still had to take this mobile-first thinking to the data visualization itself: classic UI design of graphs, numbers and labels, working through visual hierarchy of information, sizing of graphs and legends, and the use of colour for information discernment. If you know anything about us, you know that we’re all about designing in multiple iterations, and we developed and tweaked our designs several times before going anywhere near an interactive prototype.

The point is that we researched these different aspects separately so that we could determine what needed to be tested through prototypes and what didn’t. Had we been designing and prototyping everything at the same time, there would have been endless backpedaling and unnecessary revisions that would have dragged out the process for no good reason. Our time is client’s time, and streamlined processes make happy clients.

What to Prototype

Image for post
Image for post

Prototypes can take a long time and usually bring about unforeseen design changes — but that’s kind of the point: to experience the dynamic form that the design will ultimately take in the interactive digital world. Had we not prototyped, we might have only spotted the changes that had to be made to the designs once a developer had spent time coding the final product. That’s the value you’re trying to get out of your prototype — it’s a time saver, not a time waster.

With that in mind, it’s important to note that a prototype doesn’t have to encompass your entire app. You need to identify what aspects and features really need that real-time, real-world testing and what can you simply reference from existing products.

Here at TouchFoundry, our designers swear by Figma for their prototypes because it allows you to really bring your project to life with interactive GIFs and smooth, multi-directional scrolling functionality that doesn’t require that time consuming frame by frame animation. When we want to get a little more complex, we jump to ProtoPie because it allows you to program variables, conditions, and formulas in hand with animation to demonstrate a more advanced prototype. From parallax effects to on-load scrolling effects, ProtoPie helps to visualise a prototype that more deeply resembles how it would look and work in code. But there are countless programs out there for you to choose from and the best way to figure out what works for your specific project is by diving in and fiddling around.

When we got down to building our data visualization prototype, we worked with the client to develop a spec for the Minimal Valuable Product (MVP) — we prefer using the term valuable than viable! For those that don’t know, that’s the most basic version of a product that still achieves its necessary goals, hold the bells and whistles. In this case we went meta and, using a prototype, developed an MVP of an MVP. Included in this prototype were the designs for the core visuals of the mobile appropriate components. Some of the complementary components (header and footer bars) weren’t completely refined but they weren’t really getting in the way of what we needed to test, so that was okay. What was important was that our prototype illustrated the core features that needed to be validated. In our case, we needed to ensure that the graphs were easy to comprehend on mobile, that interacting with the data was intuitive and that separate but related data was easily traversed without losing context of your original point of interest.

Because our client’s product team was constantly engaged with their end users and thus had a good rapport with them, they handled the validation process. But that didn’t mean our job was done — we were in constant contact with the client during this testing and also made a number of iterations to various interactions and flows. This multi-day, rapid prototyping collaboration with the client and their end users provided the evidence we needed to show them that the product met their end users needs, and was ready to go into development.

The benefits of prototyping

What you’re getting out of your prototype is firstly, a product validated by end users and clients that hasn’t had hours of dev-time thrown at it, and secondly, a documented guide to building your design that your developers can refer to which will speed up their side of the project.

In our case, those early workshops with the client conceptualising the mobile experience and then contextualising the concept into a prototype paid huge dividends. Considering the complexity of the project, we were pretty chuffed that the validation process wasn’t drawn out and didn’t require wholesale changes to the prototype. It’s all thanks to getting everything figured out before jumping into development.

I’ll leave you with a thought — Jeff Bezos said, ‘It is always day one’. Not until your product has broad market acceptance (and even then) your current product is always the base prototype from which your future product will grow. Happy prototyping!

TouchFoundry

Digital innovation through research, design, automation and development

Ryan Von Ess

Written by

Ryan is a UX lead and product owner at TouchFoundry who is passionate about academic research, user-centric designs and human-product interaction.

TouchFoundry

Home of TouchFoundry on Medium

Ryan Von Ess

Written by

Ryan is a UX lead and product owner at TouchFoundry who is passionate about academic research, user-centric designs and human-product interaction.

TouchFoundry

Home of TouchFoundry on Medium

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store