Harnessing React Power in Design Prototyping

Linton Ye

Last Updated: 2018-03-15

In today’s sea of design prototyping tools, React might be an unintuitive choice.

The process of creating a prototype is supposed to be fast and visual. After all, the purpose of creating prototypes is to spend as as little time as possible testing different design options before making a decision. Conventionally, coding (and therefore React) is considered slow and difficult as a prototyping tool.

Jack Hallahan is a product designer based in London, UK. He’s one of the designers who knows how to harness the power of code to streamline their design processes.

Intrigued by Jack's inspiring post, I emailed him and wanted to know more. Jack was nice to have a chat with me which I can't wait to share with you!

Here's what we've talked about:

• How did Jack learn React as a designer? What were his biggest struggles?
• When is a good time to use React for design prototyping?
• Why is React the right tool? How does it compare to visual prototyping tools?
• What React related tools does Jack use in his design process?
• Jack's suggestions to designers on how to learn React

Interested in hearing the story of a fellow designer? Keep reading 📖!

What's your background?

I have been a designer for quite a few years now, but I'm actually becoming a product manager at my current company, Geckoboard. (Congratulations Jack!) Geckoboard is a B2B web app and the frontend is mostly built in React. It is a business tool to allow customers to get their data from their business, for example their sales team performance data, and create a visual dashboard to put up on the TV in the office so that everyone can see the data all the time.

I started at Geckoboard in January 2016. Before that I was at a couple of other product companies in Australia. I have been doing full end-to-end design, both user experience design and user interface design, as well as thinking about product strategy, design strategy, all those kinds of things. Before that I was in web design coming through a web design agency. I was laying out website in Photoshop to show the clients and then handing them off to the developers to build.

How did you learn React? Did you have any prior programming experience?

I have been working in digital design for a while. I have obviously become pretty familiar with HTML and CSS. I've been building websites and basic things for a long time. Javascript is something that I had often flirted with but I had never quite jumped in the deep end. I've used a little bit of jquery, but for the most part it was a mystery. At Geckoboard we have an innovation day every two weeks and anyone in the product and engineering team can use that time to work on a personal project that's not usual project work. So, it's a great opportunity to level up and broaden my skill set.

I started off doing a couple of Javascript tutorials through Codeacademy to get my head around some of the basics. And the reason I looked at React was more curiosity than anything. The engineers were using it at Geckoboard. I had been learning about some of the core concepts, such as components and state. I went searching for a few tutorials and I'm working my way through a couple of little projects, following blog posts for the instructions. Eventually I started to figure out how it was working.

Once I had those very basic concepts done, I tried to use them to build real projects. That led me to learn more and become a bit more confident with it.

What were the biggest struggles when you were learning React and how did you overcome them?

The React ecosystem is notoriously complex – it can be hard for a beginner to create a safe place to experiment without battling the build tools constantly. I spent ages trying to find the right starter project but I didn’t really know what I was looking for. A colleague pointed me at create-react-app when it was gaining some traction, and from that point I’ve relied on it for all my React projects.

I think most folks will stumble over JSX from time to time, I still do if I’m switching between React and html for different projects. I haven’t found any tricks here – you just need to memorize the differences, but luckily there aren’t too many.

It took me a while to build the right mental model about how React works and fits together, and the fact I was almost a complete beginner with Javascript didn’t help. It was as though small bits were becoming clear but there were still too many gaps to see the big picture. I remember struggling for a long time to make a child component update its parent’s state.

Even now I would still consider myself a beginner – I would have to Google even basic things, but I’m better at knowing what to google to find the answers, and how the new knowledge will fit with the things I’m more familiar with.

When learning a new technology, an important milestone is knowing what to google and what questions to ask. From that point on, learning tends to become self-reinforcing -- everything you learn in the process will build up your new foundation to learn the next concept, the next API etc. However, to get to that point, you’d need to learn enough of the basics to get around. It’s a lot like learning a new (human) language, you’d need to know the alphabets and build up enough vocabulary. Then, you can start looking up words in a dictionary, reading and talking to people from which you’ll learn new words and new expressions.

The initial effort might seem tedious but it’s necessary. The good news is that you’ll know it when you get there, just like Jack did.

How do you use React in your workflow?

The struggle of finding the right prototyping tool

Something that we've struggled with for a while at Geckoboard is finding the right prototyping tool for the sort of work that we're doing. There's this explosion of new tools and you don't really know which one to try.

We've been able to adopt a few of those and found them really useful. Marvel, for example, is a super quick way to get some screens and stitch them together and create a bit of flow. We can make it quite high fidelity and test that with users. That's great for something that's quite a linear user journey where you're going from one page to the next one screen to the next. There're also some great tools for detailed interaction design like Framer.

"Linear user journey" is the keyword here. Next, we are gonna see the "non-linear user journey" that Jack needed to prototype and why he thinks React is the right tool.

Prototyping non-linear user journey

Many user experiences are more-or-less a linear user journey. An example is an 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.

However, what Jack needed to prototype was not a linear user journey.

Geckoboard is a business tool. People use it to design data visualizations and to design dashboards, with a lot of options that a user might have to go through in order to get the data that they need and configure it in the right way to be viewed. It also has to handle data. Data come in different shapes and sizes. If we design a new data visualization, it has to be robust enough to handle different types of data, different schemas, different numbers from one digit to six digits.

Configuring a data-visualization is an example of a non-linear path. There are many options, all of which can be chosen in different combinations, and all combinations will result in a different visualization. Seeing the preview of the chart change is a visual confirmation that the user's decisions are having the intended effect.

There wasn't really a tool that allowed us to prototype a complete user journey. I have also tried prototyping this with Axure RP in the past, which allows for some conditional logic, however it soon got out-of-hand.

Example prototypes

The first prototype was used to test the interaction design with users, as well as validating the options available to users – could they create a theme that suited their brand? It's high fidelity because it introduced some new interaction patterns we needed to be confident about, and also because the outcome is very visual, so a lower fidelity would not have been able to validate as thoroughly.

The table widget prototype is high fidelity only in the table visualization. The form on the left is more-or-less unstyled. In fact the table is very similar to the markup and styling used to create the same thing in our production code. The prototype was create to figure out those things in detail – alignment, padding, hover states, font sizes, truncation etc.

Why is React the right tool?

Managing multiple paths and handling data are the natural power of code.

For me, the advantages of React is that it fills a gap that we had in our prototyping toolkit. That gap was interfaces that allow you to configure something in a non-linear way, interfaces that handle data. Because React is javascript, if you want to make changes to the way that data is displayed, like doing some rounding or if you want to sort it, you can do that. You can't do that in simple visual tools.

(With visual tools) If you want to create a prototype to test the experience of doing something such as sorting the table, and you have to create a couple of screens that look like the user flow and hope that the user's going to click on the right button. If they don't, you'd have to say, oops, sorry, we didn't design that bit, let's just get back to the right path. In comparison, React allows me to create more robust prototypes to handle data with a complete user journey where the user could explore different options, rather than just an on-rail experience where the user has to click the right button every time.

One of those things is the idea of a component having state. The app knows the current state that it's in and you can do something to the interface to update the state. And then that state can be passed down to children. You can update a component over here by clicking something over there very easily. And then you can go back and undo it and it doesn't affect the things down the line.

High-fidelity prototypes by default

Fidelity is something you get by default when prototyping with code. Of course your button may not be styled until you add CSS, but even an unstyled button element looks and works like a button in the browser. It looks real and works as expected because it is real. You get things like cursor: pointer, hover and active states, the ability to highlight and copy text, real form elements like fields you can type in and radio buttons you can toggle, all without having to draw them or style them in any way.

I put aside any other tools and invested my time into building something in React and it really paid off. Because in the end we had something that was close to a finished experience, had all the logic to handle someone changing the color or uploading a logo and was able to be in any state in any time and not be broken. So I could test it with users without worrying about going to some sort of broken state and trying to recover from that.

When you create prototypes, do you create wireframes before coding in React?

Yes, I create lower-fidelity static sketches before moving to React. Typically I would sketch on paper and also make some quick images in Sketch, possibly even using a tool like Marvel to string them together. I can explore more ideas and make changes faster in these tools – they are better for "divergent" design, and React is best for "convergent" design– no longer exploring but rather deciding, validating and iterating.

How does the developer handoff happen after the prototypes you create are approved by the client/management?

We don't have a concept of handoff here, our workflow is agile with design and dev closely coupled. Our engineers are used to dealing with design concepts in many different formats, sometimes static mockups, detailed prototypes or just sketches. It really depends on the work. We break down the design in planning to uncover anything that needs further exploration, and we often "pair" together to implement a design.

However, no, none of my code is used in our production app. When building a prototype I don't need to worry about maintainability, reusability or scalability. The code is bad, basically, but it does the job I need it to do. Our frontend app is complex with Redux, tests, component APIs, etc. It's not worth trying to use my code for that job.

Can you comment on the speed of creating prototypes in React compared to visual prototyping tools?

React has a fairly steep learning curve but it can be surprisingly quick once you get the hang of it. However it's simply overkill for a lot of prototypes and I wouldn't recommend it for things that other tools can do well. I find it enjoyable to spend an afternoon coding and considering the fidelity and "robustness" of the prototypes like those above, I think it's pretty fast!

What React related tools are you using in your design process?

create-react-app

The number one tool that helped me get off the ground with React was Facebook's create-react-app. The startup boilerplate app that is just ready to go, pre-configured, and has lots of great features built in. Before that, it was difficult to find a good template project on Github to start with. I didn't know what was good, what I needed and what I didn't need. Things like Webpack was a complete mystery to me, and still is. So create-react-app was so easy. It had a lot of great things built in and it's just got better at the time.

The other thing that comes along with create-react-app is a quick way to share to GitHub pages.

Since it's all hosted for free, I can very easily get a url, send it to my colleagues and they can access it or send it to users who might be on the other side of the world.

Apart from that, I've installed things like Lint and a prettier in my code editor which just helps to keep things neat and easy to look for errors. And the React chrome extension tool

Tachyons for styling

It is this different approach to CSS than what most people use to. It's been called functional CSS or atomic CSS. Basically it's a library of classes that have a very specific purpose like apply one single style.

It creates this design-as-you-go mindset. You're more or less writing inline styles – saying “I want the font to be big, and the corners to be rounded. I want it to have a shadow and the background to be green.” You don't have to go and give it a semantic name and then go and write a bunch of styles that match up to that element.

If you're confident with how CSS works, it just cuts down the amount of juggling that you have to do to get something styled.

React Storybook

At Geckoboard we use React Storybook as a component library. It’s a shared resource between design and development. We’re continuing to improve it, but I can already see how Storybook can be a great bridge for designers and front-enders working on a React app. At the moment, when we’ve designed a component we want to reuse, it will be added to Storybook by an engineer. We can then refer to Storybook when designing new interfaces. We can check what components we have that are ready to use, which ones might need changing, and discover if we need to design and build something new.

In the future, it would be great to have Storybook as a source-of-truth for both designers and the front-end team. We could use React-Sketchapp to have a version of each component that can be used by designers in Sketch. I haven’t had a chance to properly try React-Sketchapp. The Airbnb design team are doing some amazing work, but at Geckoboard we’re not yet at the scale where this becomes crucial.

Any suggestions to fellow designers on learning React or learning to code in general?

You can read as many tutorials as you want. You can do a class or watch a video, but unless you actually try to build something on your own and you're not really gonna get the pieces together in your mind. So it started clicking for me when I started building things that were beyond the tutorials.

Take what you've done in a tutorial or a class, add something to it. Or think of something that might have some similarities to what you've just been learning. If the example was a product profile on an e-commerce website, then you can maybe try and create a user profile on a social network and do that in React and think about the sort of things that would need to go into that interface. Just start from scratch and build it yourself. And that's where you realize what you know and what you don't know.

As you get better, as you learn more, you'll also learn how to solve the problems that you're going to encounter more easily. So when you first start out you’ll see console errors and you have no idea what they mean or how to fix them, it's very scary and you need someone to hold your hand. But at some point, you stop being scared by an error and you think, “OK, I don't know what this is now, but I know what to google to figure out how to fix it”. Or, “I roughly know where it is in the app that it's happening, so I'll go and try to debug it”. You learn how to fix your errors and if you want to do something new, you learn the path that you might take to get there. I struggled, to begin with. But by building real things, I got to that point where I was more able to be self-reliant in solving my own problems and learning the next thing.

Final Note

I'm really impressed and inspired by Jack's drive to explore and use whatever tools to solve design problems at hand. With this mindset, he was not afraid to enter new territories and pick up new tools along the way.

Personally I think every designer should have this attitude towards new technologies. No matter if it's React, blockchain, or voice-based interfaces, we should be open to experiment with them and be ready to embrace them in our design process.

What do you think? Let me know in the comments!

I'd like to thank Jack for his time chatting with me, and providing high quality answers to my endless follow-up questions (so that I could just copy and paste 😉)! All the best moving on to the product manager role at Geckoboard, Jack!

I hope you find this article useful!

One of my 2021 goals is to write more posts that are useful, interactive and entertaining. Want to receive early previews of future posts? Sign up below. No spam, unsubscribe anytime.

Subscribe