In today’s sea of design prototyping tools, React can be an unexpected choice.
The process of creating a prototype is supposed to be fast and visual. Ultimately, the purpose of prototyping is to spend as little time as possible testing different design options before making a decision. Traditionally, coding (and therefore React) has been regarded as slow and difficult as a prototyping tool.
Jack Hallahan is a Product Designer based in London, UK. He is one of those designers who knows how to harness the power of code to streamline their design processes.
Impressed by Jack’s inspiring post, I emailed him and wanted to know more. Jack was nice enough to chat with me, which I can’t wait to share with you all!
How do you use React in your workflow? What is the story behind using React as a prototyping tool?
Jack: Something that we’ve struggled with at our company for a while is finding the right prototyping tools for the kind of work that we’re doing.
Many user experiences are more or less a linear user journey. An example is the onboarding flow, checkout or account registration. There may be small decisions along the way, but they can be handled by prototyping for a “happy path” and then considering edge cases. We can use tools like Marvell to make it fairly high fidelity and test it with users.
However, what I needed for prototyping was not a linear user journey.
Prototyping a non-linear user journey
Our product is a business tool that allows customers to get their own data from their business, for example their sales team’s performance data. It then creates a visual dashboard to be installed on the TV in the office so that everyone can see the data at all times.
People use it to design data visualizations and to design dashboards. There are many options a user may have to go through in order to get and view the data he needs and configure it correctly. It also has to handle data. Data come in different shapes and sizes. If we design a new data visualization, it needs to be robust enough to handle different types of data, different schemas, different numbers from one digit to six digits.
Configuring data-visualization is an example of a non-linear path. There are many options, all of which can be selected in different combinations. Each combination will result in a different visualization. Viewing a preview of chart changes is a visual confirmation that user decisions are having the expected effect. Because the result is so visual, a low fidelity is not fully valid.
There really was no tool that would allow us to prototype the entire user journey. I’ve also tried prototyping this with Xor RP in the past, which allows for some conditional logic, although this soon got out of hand.
I put other tools aside and took my time building something in React, and it really paid off.
To me, the advantage of React is that it fills the gap in our prototyping toolkit. That difference was interfaces that allow you to configure something in a non-linear way, and interfaces that handle data.
Can you give us some examples of non-linear user journals?
The first prototypes were used to test interaction design with users as well as validate the options available to users: can they create a theme that fits their brand?
Configuring the theme was not a linear journey. It needs to be quite visual. This is high fidelity because it introduced some new interaction patterns that we need to be convinced of. Because the result is so visual, a low fidelity is not fully valid.
Another example is this table widget prototype. It is high fidelity only in table visualization. The form on the left is more or less un-styled. In fact the table is very similar to the markup and styling used in our production code to produce the same thing. Prototype was built to understand those things in detail – alignment, padding, hover state, font size, truncation, etc.