Storyboarding - The right way to build apps

React Native is a platform for developing apps that can be deployed to multiple platforms, including Android and iOS, providing a native experience. In other words, 

. This tenet holds true across most aspects of app development. Take, for example, usability testing. In native development, teams would need to test business logic separately on each platform. With React Native, it only needs to be tested once. The code we write using React Native is good to go on both platforms and, in most cases, covers more than 90% of the entire code base.

The React Native platform offers a plethora of options. However, knowing which to use and when comes from understanding how those pieces fit together. For example, do you even need a database, or is AsyncStorage sufficient for your use case?

Once you get the hang of the ecosystem around React Native, building apps will become the easy part. The tricky parts are knowing how to set up a strong foundation that helps you build a 

 and using React Native the right way. If we look at the app as a product that our end users will use, we will be able to build a great 

, not just an app. Should that not be the principal aim of using a cross-platform tool?

Let's try and break it down. Using React Native we are:

Looking at the points above, it's clear that focusing on building our app as a product makes the most sense. Having a clear view of 

 we are looking to build will help us get there. It will also keep us in check that we are building the right thing, focusing on the end product  and not getting lost in the technicalities or challenges of a platform.

A storyboard is a visual representation of a film sequence and breaks down the action into individual panels.

I recommend a Storyboarding approach to build any front-end application, not just apps. This is not the typical storyboard that is created by the design teams, though the idea is similar. These storyboards can be a great way of looking at our app from a technical implementation point of view, too. This step will help us:

To start, we will need to go through the wireframe design of the app. The wireframe is sufficient as we will not be focusing on colors and themes here. Next, we will go through every screen and break it down into reusable 

For example, let's look at a general user onboarding flow:

A simple and standard flow, right. Storyboarding can achieve quite a lot from the perspective of the app's development and structure. Let us see how.

Visualize your app from a technical, design, and product standpoint

As you will see, we have already defined eight or nine different elements and widgets here. Also, if  elements like the search box, company logo, and the cart icon, need to appear on all screens, they can be put inside a 

The process also helps us build consistency across the app. I would recommend building custom elements for even basic native elements like the 

 element. What this does is make the app very maintainable. Say, for some reason, the designer decides to change the app's font tomorrow. If we have a custom element, changing that is practically a one-line change in the application's design system. That might sound like an edge case, but I am sure we have all experienced it. What about changing the default font size of the app or using a different font for bold texts or supporting dark mode?

The Atomic Design pattern talks about breaking any view into templates, organisms, molecules, and atoms. If you have not heard about it, Atomic Design comes highly recommended, and you can read about it 

. Taking a cue from the methodology, we will break down the entire development process into 

 and list out all those that we will require to build the views.

How do you do this? The steps are as follows:

This process will help streamline the entire development process. You'll  end up with a list of widgets and elements that you need to build. This list will work like a set of Lego blocks that will build the app for you.

You may end up with a list like this for the e-commerce app:

Looking at this list, we might decide to build a 

 by passing banners as children, and as a 

 by passing an array of category icons. If we do this exercise of defining every component for the entire app before we start building, it will improve our technical design and allow us to plan better.

The process can also help iron out design inconsistencies as we will be defining all the elements, down to the most basic ones. If, for example, we were to end up with more than four of five primary buttons to define, that could indicate that we need to review the design from a user experience perspective.

Following this model will make the development approach very modular and set us up for the development phase.

By now, we should also have a thorough understanding of: 

We also have an idea of how the layout of views will look from a technical standpoint: do we need a common header, how will transitions happen if there is animation, and so on.

To summarize, we now have a wireframed plan in place that will give us a lot of confidence as we proceed with development. 

To learn  more about building apps with React Native, check out our new course 

The newline Guide to React Native for JavaScript Developer

<h1 data-node-type="titlePlaceholder" class="titlePlaceholder">Storyboarding - The right way to build apps</h1>React Native is a platform for developing apps that can be deployed to multiple platforms, including Android and iOS, providing a native experience. In other words, write once, deploy multiple times. This tenet holds true across most aspects of app development. Take, for example, usability testing. In native development, teams would need to test business logic separately on each platform. With React Native, it only needs to be tested once. The code we write using React Native is good to go on both platforms and, in most cases, covers more than 90% of the entire code base.The React Native platform offers a plethora of options. However, knowing which to use and when comes from understanding how those pieces fit together. For example, do you even need a database, or is AsyncStorage sufficient for your use case?Once you get the hang of the ecosystem around React Native, building apps will become the easy part. The tricky parts are knowing how to set up a strong foundation that helps you build a scalable and maintainable app and using React Native the right way. If we look at the app as a product that our end users will use, we will be able to build a great experience, not just an app. Should that not be the principal aim of using a cross-platform tool?Let's try and break it down. Using React Native we are:<ul><li>Reusing our expertise in JavaScript and TypeScript</li><li>Black-boxing out most of the platform-specific nuances</li><li>Trying to build once and deploy on multiple platforms</li><li>Looking to iterate furiously and reduce time to production</li><li>Providing a consistent user experience across platforms </li></ul>Looking at the points above, it's clear that focusing on building our app as a product makes the most sense. Having a clear view of what we are looking to build will help us get there. It will also keep us in check that we are building the right thing, focusing on the end product and not getting lost in the technicalities or challenges of a platform.Storyboarding the app will help us achieve just that.<h2 class="heading-anchor-text" id="storyboarding">Storyboarding<a href="#storyboarding" rel="noopener noreferrer nofollow">#</a><a class="d-inline heading-anchor" title="Direct link to heading" href="#storyboarding">#</a></h2><blockquote data-block-type="information" class="information annotated">A storyboard is a visual representation of a film sequence and breaks down the action into individual panels.</blockquote>I recommend a Storyboarding approach to build any front-end application, not just apps. This is not the typical storyboard that is created by the design teams, though the idea is similar. These storyboards can be a great way of looking at our app from a technical implementation point of view, too. This step will help us:<ul><li>Achieve consistency</li><li>Decouple design and development</li><li>Provide a high-level view of components and elements that we need to build</li></ul>To start, we will need to go through the wireframe design of the app. The wireframe is sufficient as we will not be focusing on colors and themes here. Next, we will go through every screen and break it down into reusable widgets and elements. The goals of this are multi-fold:<ul><li>Lay out the navigation flow of the app. This will help us lay the foundations of the app (e.g., single-screen plus drawer or tab-based navigation?).</li><li>Identify the structure of the app pages. Does the app have a fixed header, an animated one, or maybe a search bar that persists across the screens?</li><li>Identify elements, or Atoms, from Atomic Design methodology. These are the most basic elements used to build any view. Consider the design and behaviour of textboxes, buttons (primary, secondary), headers, etc.</li><li>Identify widgets. These will be the building blocks of any view; a view may have a carousel, product displays, reviews and ratings cards, and so on. The idea is to break them down into standalone self-sufficient components and then reuse them across the app.</li><li>Define a design system that helps us build typography for the app, standardizing most basic elements, primary and secondary colors, paddings, margins, headers, titles, and more. We will also define some global layouts that will be reused across screens.</li></ul>For example, let's look at a general user onboarding flow:<ul><li>The app launches with some marketing slides, introducing app capabilities</li><li>The user slides to the final card</li><li>Clicks Home to lands on the homepage</li></ul>A simple and standard flow, right. Storyboarding can achieve quite a lot from the perspective of the app's development and structure. Let us see how.<figure class="photo figure-position-null"><img src="https://s3.amazonaws.com/assets.fullstack.io/n/20210926170551558_storyboard.png" attachmentid="c3115a57-c4a1-4fa9-a028-572274fbf204" contenteditable="false" data-width="1800" data-height="1079"><div></div></figure>Visualize your app from a technical, design, and product standpoint<ul><li>First Screen: We have a swiper; let's call it <code>ImageCarousel</code> widget. We also have two <code>ButtonSecondary</code>s (named for the type of UX design they will carry).</li><li>Second Screen: The home button will probably of type <code>ButtonPrimary</code>.</li><li>Third Screen: We have quite a few components here. Category icons, a carousel (showing a product card), another carousel (showing banners, so <code>ImageCarousel</code>), and then we have the search input box, a heading, and a sub-heading.</li></ul>As you will see, we have already defined eight or nine different elements and widgets here. Also, if elements like the search box, company logo, and the cart icon, need to appear on all screens, they can be put inside a <code>Header</code> widget.The process also helps us build consistency across the app. I would recommend building custom elements for even basic native elements like the <code>Text</code> element. What this does is make the app very maintainable. Say, for some reason, the designer decides to change the app's font tomorrow. If we have a custom element, changing that is practically a one-line change in the application's design system. That might sound like an edge case, but I am sure we have all experienced it. What about changing the default font size of the app or using a different font for bold texts or supporting dark mode?<h2 class="heading-anchor-text" id="elements-and-widgets">Elements and widgets<a href="#elements-and-widgets" rel="noopener noreferrer nofollow">#</a><a class="d-inline heading-anchor" title="Direct link to heading" href="#elements-and-widgets">#</a></h2>The Atomic Design pattern talks about breaking any view into templates, organisms, molecules, and atoms. If you have not heard about it, Atomic Design comes highly recommended, and you can read about it <a href="https://atomicdesign.bradfrost.com/chapter-2/" rel="noopener noreferrer nofollow">here</a>. Taking a cue from the methodology, we will break down the entire development process into <code>elements</code> and <code>widgets</code> and list out all those that we will require to build the views.How do you do this? The steps are as follows:<ul><li>Walk through the entire wireframe of every screen of the app.</li><li>List the widgets that need to be built for rendering the screens. The components should be reusable, and no widget should perform the same functionality as another widget.</li><li>Check if any of the widgets have a similar functionality, view, or feel. If yes, combine them.</li><li>List all the elements you'll need to build, down to textboxes, titles, and inputs.</li></ul>This process will help streamline the entire development process. You'll end up with a list of widgets and elements that you need to build. This list will work like a set of Lego blocks that will build the app for you.You may end up with a list like this for the e-commerce app:<ul><li>Widgets: Image Carousel (Banner Carousel), Product Carousel, Category Icons, Header, Footer, and so on.</li><li>Elements: ButtonPrimary, ButtonSecondary, CustomText, CustomTextBold, CustomCheckbox, CustomRadioButton, etc.</li></ul>Looking at this list, we might decide to build a <code>carousel</code> widget that works like a <code>banner carousel</code> by passing banners as children, and as a <code>category scroller</code> by passing an array of category icons. If we do this exercise of defining every component for the entire app before we start building, it will improve our technical design and allow us to plan better.The process can also help iron out design inconsistencies as we will be defining all the elements, down to the most basic ones. If, for example, we were to end up with more than four of five primary buttons to define, that could indicate that we need to review the design from a user experience perspective.<h2 class="heading-anchor-text" id="outcome">Outcome<a href="#outcome" rel="noopener noreferrer nofollow">#</a><a class="d-inline heading-anchor" title="Direct link to heading" href="#outcome">#</a></h2><figure class="photo figure-position-null"><img src="https://s3.amazonaws.com/assets.fullstack.io/n/20210926170614093_reusable-components.png" attachmentid="4e1196d8-487a-46ff-ae50-09dc3a174baf" contenteditable="false" data-width="1056" data-height="536"><div></div></figure>Source: GoogleFollowing this model will make the development approach very modular and set us up for the development phase.By now, we should also have a thorough understanding of: <ul><li>The flow of the app</li><li>The screens we need to build</li><li>The components these views require</li><li>The low-level element blocks that need to be written first</li><li>How to create a design system</li></ul>We also have an idea of how the layout of views will look from a technical standpoint: do we need a common header, how will transitions happen if there is animation, and so on.To summarize, we now have a wireframed plan in place that will give us a lot of confidence as we proceed with development.&nbsp; <hr>To learn more about building apps with React Native, check out our new course <a href="https://www.newline.co/courses/the-newline-guide-to-react-native-for-javascript-developers" rel="noopener noreferrer nofollow">The newline Guide to React Native for JavaScript Developer</a>.<figure class="photo figure-position-inline"><a href="https://www.newline.co/courses/the-newline-guide-to-react-native-for-javascript-developers" contenteditable="true"><img src="https://s3.amazonaws.com/assets.fullstack.io/n/20210928172455053_CoverImage_RNforJSDevelopers.png" attachmentid="162c5b54-a729-41b1-8caf-2c39ecf04e6a" contenteditable="false" data-width="1920" data-height="1080"></a><div></div></figure>

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Storyboarding - The right way to build apps

Responses (0)

Masterclasses

Tutorials

Fullstack React with TypeScript