Prototyping Best Practices using React for Front-End Developers
Tags: react, prototyping101, productdesign, ui
Published: 2019-04-01 20:24:20

---
title: Prototyping Best Practices using React for Front-End Developers
published: true
description: A simple guide of how to efficiently prototype a front-end application using React.
tags: #ReactJS #Prototyping101 #ProductDesign #UI 
---

<p><span style="font-weight: 400;">It is not uncommon for a client to have only a fuzzy idea about an app they're wanting to create. They might be only experimenting with an incomplete business model and many times lacking technical background. As a <a href="/blog/7-traits-of-a-great-cto" target="_blank" rel="noopener">CTO</a>, being able to handle this situation can be a game-changer between a frustrated client and a successful product.&nbsp;</span></p>
<p><span style="font-weight: 400;">A software, during its conception, is a simple abstraction. You </span><i><span style="font-weight: 400;">imagine </span></i><span style="font-weight: 400;">what you would like to achieve, but you can&rsquo;t do it </span><i><span style="font-weight: 400;">until </span></i><span style="font-weight: 400;">it comes to existence (at least partially). That&rsquo;s why front-end developer work is really important - it bridges the gap between what your clients </span><i><span style="font-weight: 400;">imagine </span></i><span style="font-weight: 400;">to what they </span><i><span style="font-weight: 400;">see</span></i><span style="font-weight: 400;">.</span></p>
<p><span style="font-weight: 400;">By quickly presenting clients something </span><i><span style="font-weight: 400;">visual </span></i><span style="font-weight: 400;">you can gather much more relevant feedback, avoid early pitfalls and significantly increase the likelihood of success. Besides, chances are your clients won&rsquo;t care about magnificent back-end work, since they can&rsquo;t see it directly! For non-technical people, the reality is that the UI will cause much more impact.</span></p>
<p><span style="font-weight: 400;">This article aims to provide you with a simple guide of how to efficiently prototype a front-end application using <a href="https://reactjs.org/" target="_blank" rel="noopener">React</a>. The information you will find here has been compiled during several years of consulting work and contains feedback from many clients.</span></p>
<p><em><span style="font-weight: 400;">ButterCMS is an API-based CMS for React apps. <strong><a href="/react-cms/" target="_blank" rel="noopener">Add ButterCMS to your React app in minutes</a> </strong>using our Node.js API client.</span></em></p>
<h1><span style="font-weight: 400;">The right tools for the job</span></h1>
<p><span style="font-weight: 400;">When seeking efficiency, it is mandatory to use the right tooling. This is not a debate of <a href="http://buttercms.com/blog/comparing-angular-vs-vue" target="_blank" rel="noopener" title="which javascript framework is better in 2019">which technology or framework in 2019 is better</a>&nbsp;for your project, but rather what tools can increase your velocity <i>given </i>your stack&rsquo;s choice (in our case, React).</span></p>
<p><img src="https://cdn.buttercms.com/Q5b89ySSCQzP6kIaRjgy" alt="Web Tools" style="display: block; margin-left: auto; margin-right: auto;" /></p>
<h2><span style="font-weight: 400;">Starters</span></h2>
<p><span style="font-weight: 400;">You don&rsquo;t want to waste time optimizing your webpack or installing Babel plugins during this phase, so a good starter is recommended. There are many, but I&rsquo;ll emphasize the following:</span></p>
<ul>
<li style="font-weight: 400;"><a href="https://facebook.github.io/create-react-app/" target="_blank" rel="noopener"><span style="font-weight: 400;">create-react-app</span></a><span style="font-weight: 400;">: with a single command line, fire up a React application. It has drop-in functionalities but also the ability to change advanced settings. It is maintained by the React team, so you can expect a continuous development and improvement. It is less opinionated, meaning that you still have to tweak it a bit (e.g. add routing).</span></li>
<li style="font-weight: 400;"><a href="https://www.gatsbyjs.org/" target="_blank" rel="noopener"><span style="font-weight: 400;">GatsbyJS</span></a><span style="font-weight: 400;">: create blazing fast apps with outstanding features like pre-fetching, code splitting, and offline support out-of-the-box. Comes with its own routing solution by and uses GraphQL as an interface for fetching data. (<em>While we're here, you should also check out <a href="/blog/how-to-use-gatsby-with-a-headless-cms" target="_blank" rel="noopener">how to use Gatsby with ButterCMS</a></em>)</span></li>
<li style="font-weight: 400;"><a href="https://nextjs.org/" target="_blank" rel="noopener"><span style="font-weight: 400;">NextJS</span></a><span style="font-weight: 400;">: similar to Gatsby, but focused on server-side rendering, which means enhanced SEO capabilities (although you might not be much interested in that in a prototype) and universal rendering (JavaScript everywhere).</span></li>
</ul>
<p><iframe width="640" height="480" src="https://drive.google.com/file/d/19ap0L5IW-ShQgVKRBQk8V1GwHoiwwfH3/preview"></iframe></p>
<p><span style="font-weight: 400;">The truth is that you will be fine with any of them. Personally, I like to use Gatsby when the project is front-end heavy (meaning a lot of static pages and few connections with the server). If I need more freedom to use the libraries I want, CRA would be my choice. Finally, if I&rsquo;m more concerned about the back-end and willing to use JavaScript in there, NextJS is very suitable.&nbsp;</span></p>
<h2><span style="font-weight: 400;">Deployment</span></h2>
<p><span style="font-weight: 400;">One of the greatest advantages of doing front-end work is that deploying and sharing has become trivial. There are many free solutions that allow you to deploy your prototype in literally a couple minutes. </span></p>
<p><span style="font-weight: 400;">You can achieve that with </span><a href="https://www.netlify.com/"><span style="font-weight: 400;">Netlify</span></a><span style="font-weight: 400;">, </span><a href="https://zeit.co/now"><span style="font-weight: 400;">Now</span></a><span style="font-weight: 400;"> and </span><a href="https://surge.sh/"><span style="font-weight: 400;">Surge</span></a><span style="font-weight: 400;"> (among others). All of them will cover your back and provide HTTPS support, custom domains, and continuous development. Particularly, I&rsquo;m very fond of Netlify and find their deployment process insanely trivial. Simple connect your GitHub or BitBucket account, push your code and wait a few seconds until your app is available on the internet.</span></p>
<p><span style="font-weight: 400;">The power of firing up a static website with a custom domain and share it with your clients is priceless. It is a good strategy to bring them close to the development, ask them for help to test multiple devices and as a consequence have them gathering feedback and finding bugs much earlier.</span></p>
<h1><span style="font-weight: 400;">The very beginning</span></h1>
<p><span style="font-weight: 400;">Now that you have decided your starter and are able to deploy and share a &ldquo;Hello World&rdquo; with your client in 5 minutes, it is time to start designing your UI for your React app.</span></p>
<p><a href="/react-cms/" target="_blank" rel="noopener"><span style="font-weight: 400;"><img src="https://cdn.buttercms.com/OWlsENnTCmVw7FIDbe9m" alt="Front end developer UI design" style="display: block; margin-left: auto; margin-right: auto;" /></span></a></p>
<p><span style="font-weight: 400;">As a non-designer, my first instinct is to draft a rough version of the interface. This process helps me to turn something abstract into concrete. </span></p>
<p><span style="font-weight: 400;">Suppose your client wants to develop a resum&eacute; application, where users can fill personal information, work experience, relevant skills, and educational background. Stop for a few minutes and try to picture this application in your head. How is every section displayed? Do you anticipate users will need to upload a photo? Have you ever seen software that does something <i>similar</i> to that? If that&rsquo;s the case, what&rsquo;s good about it?</span></p>
<p><span style="font-weight: 400;">Here&rsquo;s what I came up with:</span></p>
<figure class="image align-center"><img src="https://cdn.buttercms.com/9Y71dFxFQ2OICBg7HFjN" alt="undefined" />
<figcaption><span style="font-weight: 400;">A simple and rough draft can help you as a starting point</span></figcaption>
</figure>
<p></p>
<p><span style="font-weight: 400;">As you can see, I&rsquo;m no Pablo Picasso. But that&rsquo;s OK -- I&rsquo;m not interested in the final design yet, just a base layout. Once I have that, I can start positioning HTML elements, add some <a href="/blog/how-to-take-your-css-to-the-next-level" target="_blank" rel="noopener" title="Overview of modern CSS">CSS</a>, &nbsp;and get some feedback. </span></p>
<h3><span style="font-weight: 400;">Look for inspiration</span></h3>
<p><span style="font-weight: 400;">Having a starting point is good but you don&rsquo;t want to showcase an app that looks like it was built in 1996. In order to give a little glamour to your sketch, you can start looking for inspiration.</span></p>
<p><span style="font-weight: 400;"><img src="https://cdn.buttercms.com/JRqNxgTYQ7yPefHG5Cf1" alt="front end developer UI" style="display: block; margin-left: auto; margin-right: auto;" /></span></p>
<p><span style="font-weight: 400;">As I already mentioned, a good way to start is to find out apps with similar features. In our example, </span><a href="https://www.linkedin.com" target="_blank" rel="noopener" title="LinkedIn"><span style="font-weight: 400;">LinkedIn</span></a><span style="font-weight: 400;"> is certainly a match. <strong>Important: </strong></span><strong><i>you don&rsquo;t want to make a copy</i></strong><span style="font-weight: 400;"><strong>.</strong> But if your users can easily relate to the interface, it&rsquo;s a win. Notice the styling trends. Details can really make a difference here: padding, font sizes, text and background colors, shadows, etc. </span></p>
<p><span style="font-weight: 400;">It&rsquo;s also a good idea to search for particular UI designs. A good website for this is <a href="http://collectui.com" target="_blank" rel="noopener" title="Collect UI">Collect UI</a>. While I don&rsquo;t expect to come up with fancy animations, I do get a lot of good inspirations from their gallery.</span></p>
<figure class="image" style="text-align: center;"><a href="http://collectui.com/" target="_blank" rel="noopener" title="CollectUI"><img src="https://cdn.buttercms.com/2mxgWSiNSvGWRRfjKDbA" alt="undefined" width="1039" height="650" style="display: block; margin-left: auto; margin-right: auto;" /></a>
<figcaption>CollectUI</figcaption>
</figure>
<p><span style="font-weight: 400;"></span></p>
<p><span style="font-weight: 400;">Finally, there are libs that provide a collection of common React components such as buttons, form components, headers, etc. One of my favorites is </span><a href="https://react.semantic-ui.com/" target="_blank" rel="noopener" title="Semantic UI"><span style="font-weight: 400;">Semantic UI React</span></a><span style="font-weight: 400;">, which is extensible and customizable. Picking a good collection can save you a lot of time.</span></p>
<h2><span style="font-weight: 400;">Start with HTML and CSS</span></h2>
<p><span style="font-weight: 400;">It&rsquo;s time to convert the sketch and your inspirations into code. You are moving one step further in the concreteness of your app. What's the best way of doing it?</span></p>
<p><span style="font-weight: 400;">The simpler way is to start with HTML and CSS only, even though you are using a React starter. Start laying DOM elements around, try different styles. Change the positioning, colors, borders. Aggregate related pieces of UI but don&rsquo;t try to over-engineer yet: no need to start decomposing your UI into multiple React elements or caring about reusability. Surely, this will need to be done. But at this moment, free your mind from framework specifics and care about how your React app should </span><i><span style="font-weight: 400;">look</span></i><span style="font-weight: 400;">.</span></p>
<p><span style="font-weight: 400;">During this phase, I avoid adding much interaction or special effects. If you envision a magnificent hover effect on the button or would like to dynamically add skills to your </span><span style="font-weight: 400;">r&eacute;sum&eacute;</span><span style="font-weight: 400;">, leave this aside for the moment. </span></p>
<p><span style="font-weight: 400;">Beware of 3rd party libraries that can add complexity - no need to install the awesome </span><a href="https://github.com/react-dropzone/react-dropzone" target="_blank" rel="noopener"><span style="font-weight: 400;">react-dropzone</span></a><span style="font-weight: 400;"> package yet even though it would be cool to let users add new avatars at this point. First, chances are you still have a lot of loose ends - what if the avatar should be added in a &ldquo;My Account&rdquo; page? Or if the client requires the ability to crop the photo? What about different images extensions? Ultimately, now isn&rsquo;t the right timing. Second, prioritize: if you run out of time, would you rather have the full layout done with a placeholder avatar or a half-baked page which allows drag and drop?</span></p>
<h2><span style="font-weight: 400;">Don&rsquo;t be careless</span></h2>
<p><span style="font-weight: 400;">Most of my tips so far were pragmatic. You should focus on having a layout done and being able to share it with your client. Likely, your deadline is short (as with every deadline). You are tempted to create the first design it came to your mind, host it in Netlify and send the URL via email.</span></p>
<p><strong>Don&rsquo;t do it.</strong></p>
<p><span style="font-weight: 400;">Although I sound contradictory, there&rsquo;s a good reason for that: </span><i><span style="font-weight: 400;">you don&rsquo;t want your job to be recognized as lazy or reckless</span></i><span style="font-weight: 400;">. It is very important to make a good first impression or you can frustrate your client. That doesn&rsquo;t mean you need to redo your design ten times before asking for feedback - but bear in mind that you will be judged by the quality of your UI, even though you swear that &ldquo;this is just a first draft and of course will be improved&rdquo;.</span></p>
<p><span style="font-weight: 400;">When your design looks professional enough, and when you compare it to your inspirations it doesn&rsquo;t look like it was done in a rush by an undergrad student, you are good to go.</span></p>
<h1><span style="font-weight: 400;">Add interactivity</span></h1>
<p><span style="font-weight: 400;">At this point, you should have a better understanding of what your React app needs to do. It&rsquo;s time to transform this web page into a web app. Let the fun begin!</span></p>
<h2><span style="font-weight: 400;">Low-hanging fruits</span></h2>
<p><span style="font-weight: 400;">Start small. What features do your clients want that you can do in the shortest amount of time? Those are the ideal initial candidates. </span></p>
<p><span style="font-weight: 400;">In our sketch, there is a plus button on the right side of each section. Suppose one requirement is to dynamically add items into them. Well, React makes this kind of behavior pretty easy and it is hard to imagine the app without this feature. If your clients ever change their minds and want to add new items, say, through a modal window, you didn&rsquo;t waste too much time.</span></p>
<h2><span style="font-weight: 400;">Don&rsquo;t show off</span></h2>
<p><span style="font-weight: 400;">JavaScript is arguably the most complex part of the development and that&rsquo;s why you want to keep it under control. While you might have already envisioned fancy interactions for the software you are building, resist the temptation to &ldquo;show off&rdquo;. </span></p>
<p><span style="font-weight: 400;">First, you are in the realm where the complex logic lives. If you make a misjudgment and a feature proves to be harder to implement than anticipated, you can get frustrated too soon and compromise the deadline.</span></p>
<p><span style="font-weight: 400;">Second, you don&rsquo;t want to set a trap to yourself. Suppose that for each item in the sections you want to be able to delete them. How are you going to do it?</span></p>
<p><span style="font-weight: 400;">Surely, there are many ways. You can have a minus button that shows up on hover right after each item and removes it when clicked. You can also have a checkbox on the left side and a button to delete all marked items. What about being able to drag every item and drop them into a trash can?</span></p>
<p><span style="font-weight: 400;"><img src="https://cdn.buttercms.com/mm3qecBRZfh5XXArtRQN" alt="undefined" style="display: block; margin-left: auto; margin-right: auto;" /></span></p>
<p><span style="font-weight: 400;">&nbsp;</span><span style="font-weight: 400;">None of the three options are necessarily </span><i><span style="font-weight: 400;">better </span></i><span style="font-weight: 400;">than the other. But you can easily identify the simpler one. The one that leaves less room for interpretation is preferred. In this example, where should the &ldquo;Delete&rdquo; button be? Are the checkboxes always visible? Is necessary to have a &ldquo;Select All&rdquo; option? For the drag and drop solution, what about mobile devices? Are you expected to support all OS? Where the trash can should be? Do you need a 3rd party library?</span></p>
<p><span style="font-weight: 400;"><strong>Make sure <i>you </i>are not the one who is adding complexity to the project.</strong></span></p>
<h2><span style="font-weight: 400;">Focus on the happy path</span></h2>
<p><span style="font-weight: 400;">A real-world web application shouldn&rsquo;t allow users to do whatever they want. For instance, if you are adding a new item to the Skills section, you certainly shouldn&rsquo;t be able to add a 2,000-word essay.</span></p>
<p><span style="font-weight: 400;">Still, this kind of work can be cumbersome and less valuable. If your clients want to test the application and validate their views, adding a really long string as a skill item might not be a concern yet. They may not even realize that you are performing a validation!</span></p>
<p><span style="font-weight: 400;">It&rsquo;s important that you define with your client the </span><i><span style="font-weight: 400;">happy path</span></i><span style="font-weight: 400;">, that is, the most common scenario that users fall into without nothing unexpected happening. In our example, it can be the user going to their profile, populating every section with valid information and saving. This is a useful and testable scenario.</span></p>
<p><span style="font-weight: 400;">Leave the edge cases for later. Recall the </span><a href="https://en.wikipedia.org/wiki/Pareto_principle" target="_blank" rel="noopener"><span style="font-weight: 400;">Pareto Principle</span></a><span style="font-weight: 400;">, or the 80/20 rule: 80% of the scenarios are done with 20% of the work.</span></p>
<h1><span style="font-weight: 400;">Decouple the UI from the back-end</span></h1>
<p><span style="font-weight: 400;">There is no doubt that back-end development is crucial for the success of your application. However, if your goal is to quickly prototype an interface, you can live without it.</span></p>
<p><span style="font-weight: 400;">The main reason is that most of the optimizations and improvements that the back-end brings are not very relevant at this stage. As mentioned before, it is likely that your clients don&rsquo;t care much about you using the right ORM or automatically scaling in AWS. Again, that doesn&rsquo;t mean they have no value - only that there are other things to focus right now.</span></p>
<h2><span style="font-weight: 400;">Separate the UI from the API</span></h2>
<p><span style="font-weight: 400;">React is not very opinionated and therefore every developer is allowed to have their own preferences about how to split logic, create UI elements, manage side-effects, etc. Many patterns emerged from the community as a response to standardize procedures but in the end, this is your responsibility.</span></p>
<p><span style="font-weight: 400;">In the old days, people would talk about &ldquo;Smart&rdquo; and &ldquo;Dumb&rdquo; components. That evolved to the more politically correct terms &ldquo;Stateful&rdquo; and &ldquo;Pure&rdquo; or &ldquo;Container&rdquo; and &ldquo;Presentational&rdquo;. Ultimately, they all share the same goal: separate complex logic and stateful representations from what is UI only.</span></p>
<p><span style="font-weight: 400;">Why is that a thing? Well, &ldquo;Presentational&rdquo; components are much easier to implement. They are simple React components with little or no knowledge of the business logic, let alone API particularities. If you are building a dynamic list of skills, you certainly can start by developing the list and the items without minding too much if you are fetching this information from a REST API or a GraphQL server. </span></p>
<h2><span style="font-weight: 400;">Hooks are your friends</span></h2>
<p><a href="https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0" target="_blank" rel="noopener"><span style="font-weight: 400;">There is a famous post from Dan Abramov</span></a><span style="font-weight: 400;"> explaining his views about the topic above. However, the original post is from 2015 and </span><a href="https://reactjs.org/blog/2019/02/06/react-v16.8.0.html" target="_blank" rel="noopener"><span style="font-weight: 400;">just recently React launched official support for hooks.</span></a></p>
<p><span style="font-weight: 400;">As mentioned in the article, hooks are another way of looking at the separation of concerns. Instead of reusing </span><i><span style="font-weight: 400;">components</span></i><span style="font-weight: 400;">, you can now reuse </span><i><span style="font-weight: 400;">logic</span></i><span style="font-weight: 400;">. This new paradigm speeds up development </span><i><span style="font-weight: 400;">a lot</span></i><span style="font-weight: 400;">. For example, suppose that your client requires some keyboard shortcuts such as pressing Ctrl + N to create a new item. You already have the UI for the items and likely an </span><span style="font-weight: 400;">addItem</span><span style="font-weight: 400;"> function. In this case, all you need to do is </span><i><span style="font-weight: 400;">hook </span></i><span style="font-weight: 400;">the required logic into the UI. </span><a href="https://usehooks.com/useKeyPress/" target="_blank" rel="noopener"><span style="font-weight: 400;">useKeyPress</span></a><span style="font-weight: 400;"> will then make your life a breeze.</span></p>
<h2><span style="font-weight: 400;">Prepare the terrain for real data</span></h2>
<p><span style="font-weight: 400;">If you successfully separate what is only UI from what is complex logic or API calls, the development process will become way smoother. That being the case, you can prepare your components for fetching data even if you don&rsquo;t have an endpoint yet!</span></p>
<p><span style="font-weight: 400;"><strong>&nbsp;</strong></span><span style="font-weight: 400;">Assume you want to create an &ldquo;Edit Profile&rdquo; page for our sample application. This would involve fetching data from the API and filling the correspondent fields. In terms of front-end development, you don&rsquo;t need to wait for the back-end and database to be set to start working on it. Create a mock object which will mimic the response from the API (what makes designing the API extremely important) and feed it into your &ldquo;Pure&rdquo; or &ldquo;Presentational&rdquo; component.</span></p>
<p><span style="font-weight: 400;"><strong>&nbsp;</strong></span><span style="font-weight: 400;">If you need to persist data, e.g. be able to edit the profile, click on save and see the changes when you refresh the screen, experiment the local storage. Although not recommended in production, it will work just fine for prototypes. If you are into hooks, there is a </span><a href="https://usehooks.com/useLocalStorage/"><span style="font-weight: 400;">useLocalStorage</span></a><span style="font-weight: 400;"> hook that trivializes this process.</span></p>
<p><span style="font-weight: 400;"><strong>&nbsp;</strong></span><span style="font-weight: 400;">When the time comes, succeeding at this phase will make switching to real data an effortless process. </span></p>
<h1><span style="font-weight: 400;">Final thoughts</span></h1>
<p><span style="font-weight: 400;">All tips included in this article are a personal compilation of years of front-end development. This is not intended to be a final manual of some sorts, but to provide guidance on how to efficiently handle clients requests and keep project quality. </span></p>
<p><span style="font-weight: 400;">The main takeaways can be summarized in the following points:</span></p>
<ul>
<li><strong><i>Communicate early</i></strong><span style="font-weight: 400;"><strong>.</strong> The sooner you get feedback, the less time you will spend redoing work. This is somewhat expected when you are on the prototyping phase, so doing this efficiently will positively impact your velocity.</span></li>
</ul>
<ul>
<li><i><strong>Avoid edge-cases</strong>. </i>Remember that you can cover 80% of the scenarios with 20% of the work. Do your clients a favor and have more meaningful features done in less time.</li>
</ul>
<ul>
<li style="font-weight: 400;"><em><strong>Don&rsquo;t over-engineer</strong></em><span style="font-weight: 400;"><em><strong>.</strong></em> Prototypes are fragile, likely to be modified and sometimes frustrating to develop. You don&rsquo;t want to spend too much time abstracting just to find out that everything will change.</span></li>
</ul>
<ul>
<li style="font-weight: 400;"><em><strong>Design the API</strong></em><span style="font-weight: 400;"><em><strong>.</strong></em> Clients will judge the interface first so you should put more effort into making it right. However, make sure you have a clear design of the API so, when it&rsquo;s time, you can plug front-end and back-end seamlessly. </span></li>
</ul>
<p></p>
<p><span><em><a href="/react-cms/" target="_blank" rel="noopener" title="Use ButterCMS with React">Use ButterCMS with React</a> to enable dynamic content in your apps for blogs, pages, and more</em>.</span></p>
<p><span><img src="https://cdn.buttercms.com/pWRdzEWAR2q0bIHONWw3" alt="undefined" /></span></p>
<h3><strong><a href="/react-cms/" class="button green">Try ButterCMS in your React app</a></strong></h3>