How to prototype product value
By: Aric Cheston
Tags: UX Design, Prototyping Tools, Prototyping, Low Code, UX Research

How to prototype product value

When you think about it, it’s surprising that it took us so long to create tools for designing software. In only the last ten years have we seen an explosion of software for designing software. For so long we relied on tools, built and optimized for something else to do what we do. It should have been obvious from the names, “Photoshop”, “Illustrator”, “InDesign”, that perhaps there could be better options. But it wasn’t until the last seven or eight years that we’ve seen the arrival of software explicitly designed for designing software. And in that time there’s been a Cambrian explosion of tools, some focused on specific parts of the workflow, some attempting to herd it all into one interface.

While I’ve been alternately thrilled, confused, empowered, and disoriented all at once, the most compelling and, often frustrating domain within this new and expanding family of tools is prototyping.

Not so long ago getting a few screens strung together on a mobile device for user testing involved a couple of developers and generally some arcane method to make it resemble an actual app. And time, it took loads of time. It was enough effort that in production schedules, a prototype was its own line item, and generally an expensive one at that. But now, we have plenty of options that are incredibly simple to use that prototyping the interface is an integral part of the design workflow.

Recently, I was super excited to learn that Framer shipped a new feature that allows you to incorporate real, live data into prototypes.

Framer positions this feature as a tool for insuring that your designs can accommodate the breadth of assets that it has to in real world circumstance. While useful, I’m excited about it because it’s a step toward filling a gap in the capabilities of prototyping tools that’s frustrated me for a long time. While Invision, Figma, Framer and others are great for testing usability, there remains a gap in testing utility.

These tools allow us to put representations of a user experience in peoples hands that are very close to what the end product would be. This is great for feedback on how the product works, but doesn’t always tell you if the product, or feature, should exist at all. The problem is that testing UI doesn’t really test the utility of the solution, i.e. how well the product solves a user’s problem. To do that, someone has to actually use it to accomplish a task that is meaningful to them. In some products, the value unfolds over time through repeated use. This kind of feedback is really hard to capture even through the cleverest concept testing methods.

The problem comes down to that fact that what our current crop of tools produce is largely static. While these sounds unfair, all the tools that I rely on produce some pretty convincing simulations, complete with complex interactions and transitions, they lack dynamic data. There are a fair number of really useful methods to get real data into prototypes and screen designs but they are largely static.

The utility of software lies in the value of that data presented to the user and how it changes — it’s inherently dynamic. Imagine a weather app that didn’t update the forecast throughout the day, or as you changed locations. Useless, right? The value, the utility, of the weather app lies in the fact that the data displayed to the use changes based on changes in parameters. So, in our product prototypes, it’s hard to get a sense of the true usefulness of a product without this dynamism. To truly test utility, you need dynamic data. For dynamic data, you need to tap into real data services.

It’s unsurprising that Framer should be the among the first (Origami has a similar feature) to incorporate dynamic data to its prototypes. Not so long ago, Framer was already doing this. Because it was essentially a visual editor for javascript, it opened the possibility of incorporating data from any accessible data service. Users could very simply create small, but fully functional applications hosted on the web. I always felt that there was a really rich opportunity here to create a platform that allowed product teams to rapidly, and cheaply, stand up feature and product concepts to allow their users to live with them long enough to give feedback on their value. I was frustrated when Framer took a hard left turn into something that had to do with design systems built in React. Needless to say, I’m intrigued by where Framer is headed now.

In the meantime, we can look beyond the usual tools to prototype value. Recently, we’ve seen a proliferation of low code, or no-code services that make product building blocks available without needing a lot of development knowledge.

Armed with these tools, a general sense of how applications are created, and a smidge of basic coding ability, you can get a lot farther than you might think towards building a prototype that uses real data and services.

Big companies like Google, Amazon, and Microsoft to have invested a lot to build platforms that let you essentially snap together applications. At the same time smaller companies like Zapier make it possible to string together a wide variety of common services without having to interact directly with their APIs. All of this sets the stage for us to build some very rich experiences very quickly. For instance, to test out a concept for a stand alone newsletter reader, I was able to copy the newsletters that arrived in my impossibly cluttered inbox into a Google doc. This wasn’t the slick interface I imagined, but it allowed me to test the essential assumption: that I’d read my newsletters more regularly if I had a discrete destination for them. And using the prototype, even in this gnarly hacky form, revealed some other essential features that would need to be in place to solve the problems I was looking to address.

In the next article, I’ll walk through an example of a prototype that I built using Twilio (SMS messaging), Dialogflow (Natural Language Processing), and Firebase (database). The concept I wanted to test was a chatbot, which I called Magpie, that would save all the books, movies, podcasts, TV, and music that people recommended to me. It would then give me lists of all the things I’d saved when I wanted them. Essential to the concept was to do this over text messaging because the last thing I needed was another app.

The purpose of this is to offer a practical example of what I’m talking about here as well as some practical tips for assembling these kind of prototypes from low- and no-code services.