Storyboarding

Once you get the hang of the ecosystem around React Native, building apps will be the easy part. We need to consider storyboarding - the art of the right way to build apps.

Product, not just app#

As mentioned in the About the Course lesson, I recommend a product-based approach for building apps using React Native. Once you get the hang of the ecosystem around React Native, building apps will become the easy part. The tricky part is knowing how to set up a strong foundation that helps you build a scalable and maintainable app, and using it the right way. Also, if we look at the app as a product that our end users (real users) are going to 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:

  • Reusing our expertise in JavaScript / TypeScript

  • Black boxing out most of the platform-specific nuances

  • Trying to build once, and deploy on multiple platforms

  • Looking to iterate furiously and reduce time to production

  • Providing a consistent experience across platforms to our end users

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, and also keeps us in check that we are building the right thing, keeping the product in mind and not getting lost in the technicalities or challenges of a platform. Storyboarding the app will help us achieve just that.

Storyboarding#

This is not the typical storyboard that is created by design teams, though the idea is similar. Our storyboard will also be great way of looking at our app from a technical implementation point of view.

In the following steps, we will create a wireframe design of the app we are looking to build. The goals of this are multifold:

  • Lay out the navigation flow of the app. This will help us lay the foundations of the app (eg single-screen plus drawer, or tab-based navigation?).

  • Identify the structure of the app pages; does the app have a fixed header, or an animated one, or maybe a search bar that persists across the screens?

  • Identify elements - these are the most basic elements that are used to build any view. Consider the design and behavior of textboxes, buttons (primary, secondary), headers, etc.

  • Identify components. These are going to 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 individual components and then reuse them across the app.

  • Define a design system that helps us build typography for the app, standardising 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.

The process also helps us build consistency across the app. I would recommend building custom elements for even basic native ones like the Text element. What this does is make the app very maintainable. Say, for some reason the designer tomorrow decides to change the font of the app. 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?

Storyboard

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

We'll start here. We will be building the flow of an ecommerce app. Let's list the screens we'll be building the wireframe for:

  • Splash screen: Will have a carousel showcasing features and then takes the user to the app homepage.

  • Home page: Where the user lands by default (the Splash screen is shown only once). It will have carousels to show products, and some marketing banners.

  • Product Details screen: Contains a few images of the product along with product information and an Add to Cart button

  • Cart screen: A summary of the items in the cart.

I'll leave the Checkout and Thank You screens for you to complete yourself if you want, as we will have covered all of the objectives of this course in the four screens above.

As for the final product, we'll be building off the image below, for theme, but the elements will be more from an ecommerce app perspective.

ecommerce

Elements and widgets#

Next, we will try to break down the entire development process into elements and widgets and list all those that we will require to build these views.

  • Work through the wireframe of every screen

  • List the widgets that need to be built for rendering the screens. The components should be reusable and no other widget should be performing the same functionality.

  • Check if any of the widgets have a similar functionality, and try to combine them.

  • List all the elements you'll need to build, down to textboxes, titles and inputs.

This process will help streamline the entire development process. You may end up with a list like this for the ecommerce app:

  • Widgets: Banner Carousel, Product Carousel, Swiper, Category Icons widget, Header, etc.

  • Elements: ButtonPrimary, ButtonSecondary, CustomText, CustomTextBold, CustomCheckbox, CustomRadioButton, etc.

Looking at this list, we might decide that we could build a carousel component and then make it work like a banner carousel by passing banners as children, and as a category scroller by passing an array of category icons. If we do this exercise of defining every component for the entire app before we start to build it, it is going to help improve our design and allow us to plan a lot better.

The process can also help iron out design inconsistencies (or help bring consistency) 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 different types of primary buttons to define, that may be an indicator that there needs to be a review of the design from a user experience perspective.

Outcome#

By following the above process of storyboarding, we should have a thorough understanding of the flow of the app, the screens we need to build, the components that will be required to add to these views, the low-level element blocks that need to be written first, and a good sense of the design system. We will also have an idea of how the layout of views will look from a technical standpoint: do we need a common header, what routes will we need to declare, and so on.

To summarize, we now have a wireframed plan in place that should give us a lot of confidence. Going forward we will be tackling these widgets and elements individually to build the app.

Start a new discussion. All notification go to the author.