Storyboarding a React Native App's Components and Flow

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.

Project Source Code

Get the project source code below, and follow along with the lesson material.

Download Project Source Code

To set up the project on your local machine, please follow the directions provided in the README.md file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.

  • |

Lesson Transcript

  • [00:00 - 00:12] As I mentioned in the Boudde course lesson earlier, I recommend a product-based development approach for building apps using React Native. Once you get a hang of the ecosystem around React Native, building apps will become the easy part.

  • [00:13 - 00:28] The tricky part is knowing how to set up a strong foundation that helps you build a maintainable and scalable app the right way. Now if you look at the app you want to build as a product that our end users are going to use, we will be able to build a great experience.

  • [00:29 - 00:37] And not just an app. I mean, is that not the aim of using a cross-platform tool like React Native for app development?

  • [00:38 - 00:48] Okay, let's look at this objectively. Using React Native, we are reusing our expertise in JavaScript or TypeScript, right?

  • [00:49 - 01:01] We are blackboxing out most of the platform-specific nuances and trying to build ones and deploy on multiple platforms. We are looking to iterate furiously and reduce the time to production.

  • [01:02 - 01:18] And with all of this, provide a consistent experience across platforms to our end users. So if you look at all the above points, we have offloaded quite a few nuances of building apps to the platform and are trying to play on our strengths.

  • [01:19 - 01:31] So wouldn't focusing on building our app as a product make the most sense? And having a clear view of what we are looking to build will not just help us get there, but also help us not get lost in technicalities and challenges of our platform.

  • [01:32 - 01:42] Storyboarding the app will help us achieve just that. By definition, a storyboard is a visual representation of a film sequence and breaks down the action into individual panels.

  • [01:43 - 01:50] It sketches out how a video will unfold shot by shot. This is not the typical storyboarding that is created by the design teams.

  • [01:51 - 02:02] Though, the idea is similar to that, as it is a very good way of looking at our app from a technical imputation point of view. Here we will create a wireframe design of the app we are looking to build.

  • [02:03 - 02:12] The goal of this step is multifold. First, it will help play out the navigation flow of the app.

  • [02:13 - 02:18] This will help us lay the foundation of the app. Do we want a single screen stack app with the side menu?

  • [02:19 - 02:26] Or do we need to have a tab navigation? Next, it will help identify the structure of the views.

  • [02:27 - 02:33] The app design may have a common header. So, can we build a fixed header that can be shared across screens?

  • [02:34 - 02:38] Then we will look to build a design system. And we will use the atomic design pattern to do that.

  • [02:39 - 02:48] Now, there is a whole module dedicated to this process, so we will cover that in details there. But in short, a design system will help us build a prototype for the app.

  • [02:49 - 03:08] Like standardizing the most basic elements, defining the primary and secondary colors, defining paddings, margins, headers, titles, basically every part of the app. Next as a part of the design system, we will also identify elements and components.

  • [03:09 - 03:22] Elements are the most basic building blocks that are used to build any view, like text boxes, buttons, and along with design will also define their behavior. Components are the building blocks.

  • [03:23 - 03:30] Think of them as Lego blocks. For example, a view may have a carousel, product displays, reviews and rating cards.

  • [03:31 - 03:44] The idea is to break the UI down into individual reusable components. Process also helps us build consistency across the app and in turn reduce cognitive load on our users of the app.

  • [03:45 - 03:56] I would recommend building custom elements for even most basic native ones like text element or image. What this does is it makes the app very maintainable.

  • [03:57 - 04:09] Say for example, the design tomorrow changes to support a new font for the app. Now if we have a custom element for text, doing that is practically a one-line change in the application's design system.

  • [04:10 - 04:26] Another example can be about changing the brand colors or the theme of the application that includes default fonts or maybe supporting the dark mode. Storyboarding and a design system will help us achieve all of this.

  • [04:27 - 04:32] Let's look at the screens right in front of us. For example, what do we have here?

  • [04:33 - 04:53] We have an initial tour, a few screens that are trying to show what the app is going to do for them for our users and then it lands on a home page. Now from a technical standpoint, let's see how we can break this entire flow down into elements and components.

  • [04:54 - 05:05] So first, there's the screen. We have a carousel here that supports displaying multiple images and the user can navigate forward and backwards through it.

  • [05:06 - 05:08] So this kind of gives us a tour. So this is a carousel.

  • [05:09 - 05:26] Then we have our very basic elements, buttons that help to use it to navigate and finally land on the home page using this home button that can be a primary button made of the brand color of the app. When we land on the home page, let's see what we have.

  • [05:27 - 05:41] We have a search bar at the top, a set of category icons. Then there's a carousel again, but this time a product carousel and then probably a banner carousel and with the tab navigation at the bottom.

  • [05:42 - 05:51] So as we can see, we have a product carousel over here. So probably this can be reused from what we build for the initial tour.

  • [05:52 - 06:08] The difference being out here, our carousel was supporting a set of images and out here it's supporting a set of product cards. So these can be different type of components for a carousel that we build for this application.

  • [06:09 - 06:16] And we can reuse what we build here out here. Similarly, it can be done for the banner carousel.

  • [06:17 - 06:22] This time again, a set of images. The difference being this probably is a free flowing one.

  • [06:23 - 06:41] And again, even for the category icons, if they extend beyond the viewpoint, then this one again can be a carousel, but this time we'll pass category icons as children. At the top we have the search bar.

  • [06:42 - 06:57] So it consists of the most basic text element that supports displaying an icon and it'll depend upon the implementation of the search bar. Is it going to be a drop down list over here or it's going to be a separate screen?

  • [06:58 - 07:21] So if we look at the whole things holistically from a storyboarding point of view, just these three screens from the user opening the app to landing on the homepage, we have broken this down into a swiper, a set of secondary buttons that can be defined with typography. There's a primary button that takes us to the homepage.

  • [07:22 - 07:38] Then on the homepage we have category icons, a product carousel, again a primary button, but displaying a different text and a different action. Still a primary button, a banner carousel and a header.

  • [07:39 - 07:49] How much of this are we able to reuse just between these three screens? A lot right and how much can we standardize using a design system?

  • [07:50 - 08:17] As we move forward in the journey of storyboarding to the further screens, the number of new elements and styles and typography that we defined is going to reduce and it should reduce. Otherwise we need to check are we building a consistent app or are we building an app where each screen has its own identity and doesn't fall in line with an overall brand image or brand colors or a brand picture.

As I mentioned in the Boudde course lesson earlier, I recommend a product-based development approach for building apps using React Native. Once you get a 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 maintainable and scalable app the right way. Now if you look at the app you want to build as a product that our end users are going to use, we will be able to build a great experience. And not just an app. I mean, is that not the aim of using a cross-platform tool like React Native for app development? Okay, let's look at this objectively. Using React Native, we are reusing our expertise in JavaScript or TypeScript, right? We are blackboxing out most of the platform-specific nuances and trying to build ones and deploy on multiple platforms. We are looking to iterate furiously and reduce the time to production. And with all of this, provide a consistent experience across platforms to our end users. So if you look at all the above points, we have offloaded quite a few nuances of building apps to the platform and are trying to play on our strengths. So wouldn't focusing on building our app as a product make the most sense? And having a clear view of what we are looking to build will not just help us get there, but also help us not get lost in technicalities and challenges of our platform. Storyboarding the app will help us achieve just that. By definition, a storyboard is a visual representation of a film sequence and breaks down the action into individual panels. It sketches out how a video will unfold shot by shot. This is not the typical storyboarding that is created by the design teams. Though, the idea is similar to that, as it is a very good way of looking at our app from a technical imputation point of view. Here we will create a wireframe design of the app we are looking to build. The goal of this step is multifold. First, it will help play out the navigation flow of the app. This will help us lay the foundation of the app. Do we want a single screen stack app with the side menu? Or do we need to have a tab navigation? Next, it will help identify the structure of the views. The app design may have a common header. So, can we build a fixed header that can be shared across screens? Then we will look to build a design system. And we will use the atomic design pattern to do that. Now, there is a whole module dedicated to this process, so we will cover that in details there. But in short, a design system will help us build a prototype for the app. Like standardizing the most basic elements, defining the primary and secondary colors, defining paddings, margins, headers, titles, basically every part of the app. Next as a part of the design system, we will also identify elements and components. Elements are the most basic building blocks that are used to build any view, like text boxes, buttons, and along with design will also define their behavior. Components are the building blocks. Think of them as Lego blocks. For example, a view may have a carousel, product displays, reviews and rating cards. The idea is to break the UI down into individual reusable components. Process also helps us build consistency across the app and in turn reduce cognitive load on our users of the app. I would recommend building custom elements for even most basic native ones like text element or image. What this does is it makes the app very maintainable. Say for example, the design tomorrow changes to support a new font for the app. Now if we have a custom element for text, doing that is practically a one-line change in the application's design system. Another example can be about changing the brand colors or the theme of the application that includes default fonts or maybe supporting the dark mode. Storyboarding and a design system will help us achieve all of this. Let's look at the screens right in front of us. For example, what do we have here? We have an initial tour, a few screens that are trying to show what the app is going to do for them for our users and then it lands on a home page. Now from a technical standpoint, let's see how we can break this entire flow down into elements and components. So first, there's the screen. We have a carousel here that supports displaying multiple images and the user can navigate forward and backwards through it. So this kind of gives us a tour. So this is a carousel. Then we have our very basic elements, buttons that help to use it to navigate and finally land on the home page using this home button that can be a primary button made of the brand color of the app. When we land on the home page, let's see what we have. We have a search bar at the top, a set of category icons. Then there's a carousel again, but this time a product carousel and then probably a banner carousel and with the tab navigation at the bottom. So as we can see, we have a product carousel over here. So probably this can be reused from what we build for the initial tour. The difference being out here, our carousel was supporting a set of images and out here it's supporting a set of product cards. So these can be different type of components for a carousel that we build for this application. And we can reuse what we build here out here. Similarly, it can be done for the banner carousel. This time again, a set of images. The difference being this probably is a free flowing one. And again, even for the category icons, if they extend beyond the viewpoint, then this one again can be a carousel, but this time we'll pass category icons as children. At the top we have the search bar. So it consists of the most basic text element that supports displaying an icon and it'll depend upon the implementation of the search bar. Is it going to be a drop down list over here or it's going to be a separate screen? So if we look at the whole things holistically from a storyboarding point of view, just these three screens from the user opening the app to landing on the homepage, we have broken this down into a swiper, a set of secondary buttons that can be defined with typography. There's a primary button that takes us to the homepage. Then on the homepage we have category icons, a product carousel, again a primary button, but displaying a different text and a different action. Still a primary button, a banner carousel and a header. How much of this are we able to reuse just between these three screens? A lot right and how much can we standardize using a design system? As we move forward in the journey of storyboarding to the further screens, the number of new elements and styles and typography that we defined is going to reduce and it should reduce. Otherwise we need to check are we building a consistent app or are we building an app where each screen has its own identity and doesn't fall in line with an overall brand image or brand colors or a brand picture. [BLANK_AUDIO]