How To Craft Reusable Components for Seamless User Interface Development

Indu Chaube at UXDX Community: UI Efficiency & Balancing User Contexts for Platform Success. Video: https://youtu.be/mvlg5fomyFw

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

What this session covers

[00:00:00] Let me first introduce what I'm going to cover in this session today. First of all, I'm going to talk about awareness, understanding and the advantages of reusable components. The second phase of this session will be how we can identify reusable components, and what the approach for implementation would be. When I talk about awareness, understanding and advantage, I'm going to explore what a reusable component is, and at the same time what the mindset of the developer, and at the same time the UX team, should be to create a reusable component.

What is a reusable component

[00:00:40] Next, let's start with what a reusable component is. Reusable components are self-contained modules or units of software functionality that can be easily integrated into different parts of an application, or across multiple applications, promoting consistency, efficiency and maintainability in software development. That is the key feature of a reusable component. But apart from that, when I'm saying consistency, efficiency and maintainability, that is more about the development life cycle. What the user is getting out of it is a better user experience. If the component is reusable, it means that it is going to look the same across the application, with different flavors, colors and so on, but the behavior of the component will be the same. That leads us to create a better user experience for the users.

Reusability thinking is a mindset

[00:01:41] Reusability thinking is a mindset. If we are planning to create reusable components, we should be in that mindset, where we can find opportunities to identify a reusable component and then create it. Reusability thinking is a mindset or approach that encourages a developer to create products or systems or components that can be used multiple times across different contexts of the application. It is just a mindset: how you look at the application, how you identify which component can be reusable, and then create it and use it in different parts of the application.

[00:02:35] Here in the example I show RC. RC is going to be used on screen one, screen two, screen n, it doesn't matter where they are, but RC is created one time. One component can be used on many, many screens, or one can be used on the same screen multiple times. That is the opportunity where we can create a reusable component. It should be in mind whenever we approach creating a product or service: we should be in that mindset to identify what we can create as a reusable component, and use it in the application wherever it is needed.

View and behavior

[00:03:20] Reusable component attributes. There are two parts to a reusable component: first is the view, second is the behavior. The view is going to contain the layout, how it is going to look, what the style is, what the accessibility concerns are for the user. Different types of users are using those components, so how is it going to be available for different kinds of users? And at the same time localization: different parts of the globe are accessing those components. And how data can be injected into the component, and how it can be more viewable to the user from different perspectives, like readability, views, and look and feel.

[00:04:16] The second part is behavior: how that particular component is going to act when the user interacts with it. Interactivity is the more important thing, like the communication the user is making throughout the product journey while they are interacting with the application. State: how the state is getting changed for that component, and what kind of events that component exposes to the user, so that the user can interact and perform certain actions. And validation and errors: if there's something that is not as expected, how does the user see those validations and errors on the component?

[00:04:56] I'm going to give you an example for the card component. No matter which framework or which language you are going to write in, but this is an example in Angular, a very small piece of code, where you can see title, content and border color for the component. At the same time, we are seeing view and edit, two events the user can perform throughout the card interaction journey. The first three parts, title, content and border color, are mainly for the view, how that card is going to look. And the second part is where the user clicks on view and edit, or maybe mouses over this card: how that card is going to behave. This should be pretty much identified, and at the same time leveraged, with the shared component or reusable component.

Advantages: efficiency, consistency, user experience

[00:06:03] Advantages: why are we thinking to create reusable components? There are many advantages, but a few that I've pointed out are highlighted here. Efficiency: if we are creating a reusable component, we are going to get efficient development. The same component can be used in many, many places throughout the developer journey. If it is reusable, it is probably faster to integrate, faster to develop that particular screen or many screens, because we know a bare-metal component is available where we can just inject data and it does the job itself. At the same time, it is going to look and feel the same way, so the developer does not have to worry about how it is going to behave, or how it is going to look, because that is already defined in the reusable component.

[00:07:04] At the same time, consistency, which I was talking about earlier, leads to it looking the same but with different flavors, and that again can be passed as an input to the component. And at the end, when we develop an end-to-end product with reusable components, we are probably exposing a better user experience to the user, because we use a lot of reusable components that lead to the same kind of consistency, and the same component behavior the user is used to while using that application. So it is improving the user experience also. Efficiency, consistency and user experience: those are the key advantages we get from creating reusable components. On the developer side of it, efficiency; on the user side of it, consistency and user experience.

Plan for reusability up front

[00:08:09] Component development strategy. We know that when we have to go and develop a particular product or solution, we get the requirement first, then we plan around the requirement, and that planning involves a lot of things. First of all, how the screen is going to look, how the back end is going to work, how the services are, and so on. Planning has a lot of things to do, and at the stage of planning we should be defining what can be reusable.

[00:08:42] I did notice throughout my career that people move on to development and then start figuring out what could be a reusable component. But at the planning stage we should be understanding, or identifying, what could be reusable, and start developing those first, and then those reusable components can get consumed by the UI development team. And when I'm saying reusable component, it doesn't mean a different developer is tasked with it. The same developer can develop the reusable component and then consume it in the product screens or features.

[00:09:27] One more thing I also want to identify here is the kind of design system that needs to be followed, for the reusable component and throughout the product journey. What a design system is, I'm going to explore a little bit later in this session, but it is a definition of the product: how that product is going to behave, look and alert the user while the user journeys through the product or service or software.

[00:10:02] When I say reusable component, it is not only for the GUI but for the back end side of it as well. If some user is accessing certain APIs or services, they should also behave the same way. Not one API returning "first name" and another API returning "fname," that kind of stuff. It should be very consistent, which means that someone consuming that particular component can be more predictable in terms of the data model also. Similarly for the component: how data is going to be consistent and injected into the component is pretty much well defined and well expected by the component, and that leads to faster or more efficient integration with the UI.

Finding reuse in an example screen

[00:10:57] I'll take an example, an ABC example, an edge case: one ABC application where we have 10 screens and hundreds of features in those screens. In this example, one screen here has a header, and a card for different stats, with images and buttons, and that needs different kinds of reusable components. First of all we see the header. The header could have a logo, could have certain menu items, some badges and some product name or service name, or whatever is there. The black highlighted box you can see is also a component. What kind of component, we can discuss later, but it is a component that is going to be reused throughout the application journey, and it consists of a lot of other reusable components, like buttons, like badges, and the logo component itself.

[00:12:08] At the same time, when we see the card, the card is also one separate design, apart from the button inside that card, and how the button is going to behave is also a different set of properties. So we see everywhere the opportunity here to create reusable components. Maybe element-based components, which are again reusable components. There's a card component, which is again reusable. At the same time, the whole package, the whole card that behaves the same and gets used in many places throughout the product journey, could again be a reusable component. So during this example we understand where we find the opportunity to create reusable components.

Design systems and types of component

[00:13:04] Here are the types of reusable components. Earlier I was talking about design systems, so let's figure out what a design system is. A design system is a kind of brand that a particular product or service represents to its customers. When a user interacts with a particular product, there should be a definition of how that product is going to look, how the user interacts with that product, and how the code is structured for the product that's getting delivered. Because quality, consistency and user experience, all three aspects, are required from the customer's side of it. If you say, "Yes, the UI is looking good from the front," but the back is messy, probably we are enabling a lot of bugs.

[00:14:02] So there should be certain guidelines that need to be followed to develop a particular interface, and that we call a design system. For UI, a UI design system; for APIs, an API design system; and for services, different design patterns and systems. Here we are exploring the UI design system, which consists of guidelines on how particular components or elements get developed: what the color could be, what the color variants could be, how borders are going to look, and so on. And accessibility: if there is accessibility, what kind of theme the user is going to get out of the box from the design system.

[00:14:52] And then, based on that design system, there are many kinds of components. First, there can be common components, which could be a library. If you know, and if you belong to the UI development industry, you probably understand that there are many design systems and many open source libraries, like Material Design, Bootstrap and so on, that are part of common components. So I'm pointing out the UI library that enables the bare minimum features for the application, and that can be shared across one product versus another product also. And that should be well managed and version controlled, so that when we adopt that particular version, we know what kind of features we are going to get, what kind of flavor we are going to get, and how that particular library's elements are going to behave and act throughout the product journey.

[00:15:57] There are some more types of reusable components, like shared components and feature-level components. If we are adopting a certain design pattern for the UI libraries or common components, these are based on top of that. Like I was talking about with the card: the card has a button, the card has some image, the card has some content inside, and in the card that button acts differently according to the application's needs. So that is a package that has a lot of different components, and it could be created as a shared component throughout the project journey. Because we know, when we are planning for creating the ABC project, how the UI is going to look and where reusability could lead us to create reusable components. So those packages we can create as shared components.

[00:17:04] At the same time, a feature component, like I was describing earlier: the header of the application is a kind of feature level. The whole header is defined, and the header has many elements in it, like buttons, badges, logos, menu items, and that is all data driven. That could be a feature component, because we know it is going to be used on almost all screens, and it's driven through the state of the UI. So that could be called a feature-level component.

Don't modify reusable components at the screen level

[00:17:43] One thing I'm going to tell you: here there are the common components, then we are creating shared components that use the common components, and probably when we are creating a feature component, we are using some part of the shared components or common components together. So it is getting layered one on top of another. What I have learned throughout my developer journey is: do not nest too much, and minimize the modification of reusable components at the screen level.

[00:18:24] I mean, do not chain a lot, and at the same time do not modify these components at the screen level. Let's suppose you have a button, or a shared component has many buttons, and you want to modify the button color or border or something like that. If needed, do not do the modification at the screen level. Modify it at the shared component level. Try to add additional business logic there, so that the component behaves the way you want, versus overriding it. Because if you're overriding on one screen, the second screen is not going to look the same, and that leads to inconsistency throughout the application.

[00:19:12] So it's better, when we are using shared components, that if you want to make some changes to a shared component, you do not change it at the screen level; make the change in the shared component itself. At the same time, let's suppose you want to make a change to the button, and it is coming from the UI library common component: make sure you are making that change in the common component itself, not in the shared component. Otherwise there could be inconsistency everywhere, and it leads to an inconsistent user experience.

Code consistency, documentation and versioning

[00:19:53] Consistency: while creating reusable components, we should be thinking about code consistency also. If we are creating buttons, and many flavors of buttons, they should go into the button folder, not somewhere else. Make sure there is a consistent folder structure, or domain, for the particular component. Similarly, if we are creating components related to the header, they should go into the header folder structure, not somewhere else. Why is it really important? Because when another developer is developing along with you, they should understand where to go and what to find. Otherwise a different developer starts creating another duplicate reusable component, knowingly or unknowingly. So make sure it is consistent, and that can be documented also. Make sure the naming convention is also consistent throughout the application journey.

[00:21:06] That leads to faster reusable component integration, because where there's consistency, it can be well documented and well elaborated to other users. The developer can just assume how it can be called, or something like that. Otherwise there's a lot of learning curve, and then efficiency gets threatened there. Coding style is also one of the key things that leads to consistency. When a developer is making a reusable component, it should be well documented, well commented, and with the business logic well defined in the coding style. I mean, do not do over-engineering in the coding style. If something can be segregated, develop a different util function or class and try to call it from the code, making more clean code and documented code, and that leads to faster development and faster integration.

[00:22:25] And documentation. I was saying, when creating the folder structure, naming convention and coding style, at the same time, when a particular component gets created, make sure it has well-defined documentation on top of it. If it has well-defined documentation, it is easy to learn faster and easy to integrate, because then the developer does not need to go inside to understand it before they start integration.

[00:22:58] Version control also. I said that every reusable component should be based on versioning. Let's suppose version one is coming from the component, and version two is coming from the component. It can be well defined, so that product one uses version one, product two uses version two, and so on. It can be well defined in versions, so that the flavor does not change throughout the products.

[00:23:33] And here there is a small quote: reuse to innovate, not to reinvent. Make sure you are innovating, not reinventing. That is what I was saying earlier: do not try to override. Try to use it as it is, or if you want to make a change, change it at the root level, not at the top level. That is my take on this one. And with this I'm going to end. I wanted to cover a lot of coding with this, but I know this session is really short, so I figured it would be more about understanding what reusable means and how we strategize to develop a reusable component. Here I'm finishing my session. Thank you so much for being with me, and I'm ready to take questions, if there are any from the users' side. Thank you.

Q&A

[00:24:30] Host: Thank you, Indu, that was fantastic. Yes, there are questions. We have three minutes, so I'll jump straight in. The first thing I'll ask is: what are some of the common challenges you see in terms of collaboration between the teams, let's say designers or developers, with regard to components or design systems, particularly when it comes to reusable components?

[00:25:02] Indu: The common challenge is that, look, on the engineering side of it, developers develop the product, and on the user experience side of it, experience engineers define the experience. But I was talking earlier about the planning, where the product gets defined and where we define how that product is going to look. So it is more on the user experience team to identify what the product is going to look like, and how, in the first stage, not making changes over time. Because that is going to kill a lot of the developers' time, and at the same time the common component developer team's time. Because if we replan again and again and again, probably the whole development stack is going to change according to that. So that should be pretty much very consistent and well defined on the planning side of it, versus the development side of it.

[00:26:00] Host: Amazing. And could you also give an example of design patterns that are particularly effective for reusable components in complex UIs?

[00:26:11] Indu: Design patterns. I didn't get the question fully, but there are many design patterns that are readily available in the market right now. But companies also, if there is a big company that wants to define their own design pattern, how their buttons are going to look, how they want them to behave, that can be defined. It is more of an artistic work that UX engineering does, versus engineering. It is more of an artwork, and that design pattern can be defined product to product and service to service. You know, Google defined their own, Material Design, and Bootstrap also has their own design pattern. Similarly, a developer building a new product or service can define their own design pattern. But make sure it is accessible. Make sure that, since this particular product or service is going to be used by different kinds of users, some with disabilities, some without, blindness and so on, it is consistent from that perspective, and that the design pattern supports them.