Levvel Blog - Video Series: Component-based Architecture and Design—Considerations, Technology, and Culture

Video Series: Component-based Architecture and Design—Considerations, Technology, and Culture

This video blog series is a comprehensive guide to component-based architecture and design and how a business can benefit from it. Over the next few weeks, we’ll cover various aspects such as the various business benefits, the definition of atomic design, how building a component-based experience affects design, the technical considerations, and the cultural implications.

Table of Contents

Episode 1: What are the Benefits of Using Component-based Design and Architecture?


Episode 1 Transcription

Devin Smith: What is the benefit of using component-based design and architecture? I think that that is the question that lies at the heart of why you should consider having a design system, which is a larger topic that we can, we’ll get into in other pieces of content. But I think that your component library is something that’s going to enable you to build experiences that don’t just depend on understanding how one screen flows together and how things work together across a bunch of screens.

You think in terms of systems. And so what it allows you to do is to create methods, create systems for how things fit together, and you create a system for your experience essentially. And so your functionality that comes from these components can be exported to anything that you need them to. They’re reusable. It creates efficiency because developers aren’t coding things over and over again.

Designers aren’t designing things over and over again. You can have this problem on a small team, but you can actually have this problem on a large team to an even a greater detriment because when your team is large enough that your designers don’t know what the other’s working on you can actually get situations where they try to touch the same things or they do things over and over again and there are little differences between them. So when your customer experiences your product, they actually notice those inconsistencies, or it’s something that doesn’t feel right, or in maintenance, you notice the inconsistencies and you realize it’s going to be a nightmare to clean it up.

Read our 2019 Guide: Build, Understand, and Benefit from Component Libraries for Advanced Organizational Efficiency

And so as you grow, this helps you to be able to have consistency in a way that doesn’t cost you a ton of money and a ton of heartache in trying to do that retroactively. It’s there from the beginning, just in the very way that you’re working and that scales, that will always scale. And so you have to, you have to be able to adopt things like component libraries to make sure that you can grow with the opportunities that are there for your business.

Stevie Palmateer: So what are the benefits of component-based design and architecture? So Devin touched a little bit on it from a design perspective. I think when we think about specifically architecture and architecture design, this is nothing new. This has existed even in with infrastructure and today you actually see it with how modern browsers work with web components themselves. So think custom HTML elements. The focus here is on interoperability. So how data transfers from one system-isolated component to another and also encapsulations so that they are self contained from a logic and a state perspective.

So as mentioned, interoperability and encapsulation enable scalability and scalability is also enabled by reuse of code. And essentially we can think of the reason that we want to do this is obviously with your businesses growing, you want your technology to grow with it in an easy way. And some ways to do this is essentially to think about how these things are built in isolation, and so that they can be reused across maybe the actual application you’re only working on across multiple views, but also as you extend and you start building multiple applications, you can start reusing these components that way as well.

Watch our 2019 Webinar: Improve Organizational Efficiency and User Experience with Component Libraries and Design Systems

Let’s say you also need to make a change to where all of this reuse already exists. You can make it at the single source of truth, at the parent level if you will, and have it trickle down to all areas that it is being reused. But essentially, why would you care about something like this? You can think of something such as like a rebranding effort where you need to make styling changes across multiple applications on to even maybe a control that’s become antiquated in the way that it’s utilized in the community. So another benefit of using component-based design and architecture is consistency. And Devin did a really good job covering this, about how it’s consistent for the user experience and that honestly is a really big point to make, but it’s also giving the developers experience consistency.

They know now there is a reliable component that works the way they need to somewhere that they can access it and it’s going to work and behave the way they expect it to. It also, they know, is going to be hopefully designed in a way where the application context and business logic is separated so there’s a lot of flexibility and they don’t have to worry about dealing with all this nested business logic to get what they need out of it.

Another benefit of design and architecture that’s actually a design pattern itself and arguably probably one of the biggest advantages is composability. A system that is highly composable is essentially one that has isolated self-contained components that can be selected and assembled in multiple various ways depending on whatever the business requirements are at that given time. These self-contained components, also as I mentioned before, with encapsulation, maintain their own state.

And again, that does help with responsiveness and also isolating binding data within them. Another benefit of composability is it is composition versus inheritance. So it does allow you to avoid those tedious and daunting inheritance hierarchies, so that you know that what you’re composing at that time is what you’re going to get. And there’s no inherited functions or “gotchas” that you’re going to have to deal with later.

Read our Checklist: Can My Business Benefit from a Design System?

Let’s think of an example of how composability works and in a way that you might be familiar with. So think of Wordpress. When you are generally maybe not doing any type of technology and you’re literally dragging and dropping components and building out a Wordpress page, you’re literally doing that, right? You’re taking these isolated components that someone designed, you’re creating a larger page out of them the way that you need to and you know that they are their own components.

So they might look identical to each other, but you can change one title on one and change another on another component, and that’s completely separate from each other. And in addition, as the page renders and things update, they’ll update in isolation as well. So let’s get out of the weeds of design patterns and benefits from that standpoint and let’s think about how we are benefited in terms of our SDLC process and our teams in general.

The first highlight of that is DevOps enablement. When we think of are we ready to be on a continuous delivery pipeline, the first and foremost thing is what’s happening at the development level. And what you want is confidence that if you do have continuous delivery, your code is going to be error and bug free. So if we are developing these components as atomic separate units, they’re perfect for unit testing and therefore you can increase your code coverage very easily. And you can do these unit testings in different variations.

Read our 2019 Guide: 10 Questions to Ask When Planning for Design System Maintainence

You can do it from a presentation standpoint. You can do it from a snapshot standpoint of the component itself. And you can do it from a logic standpoint. In addition to code coverage, you’re also expediting the way that your SDLC process works. You are having shorter sprint cycles and you’re enforcing communications that’s cross functional across your design and your developers.

So then there’s going to be less time that happens to go back and forth from that product review standpoint where the designer says, hey, yeah, that works, but it’s not exactly the way I wanted it to work. You’re eliminating that by having something that doesn’t need to be done over and over again and there’s already confidence that it’s designed correctly. But also, you know that you’re doing that design. The developers and the designers are working together initially through the process.

So the last benefit that I want to talk about, and again this is team-focused, is specialization. You, depending on your tech stack that you go with, and we’ll talk about that later, essentially though, you want to make sure that your team is well equipped to just do what they’re specialized and best at doing. So whether that’s your designers specifically designing, and then if they also have the capability to do CSS and HTML, great. Or if it’s your developers who are just good at Javascript or Java or c-sharp, whatever it is that they’re building their component business logic in, they are just doing that. So by isolating, through component-based design, you enable the ability to do that easily.

Episode 2: What is Atomic Design?


Episode 2 Transcription

Devin Smith: Atomic design is a framework for understanding and organizing the building blocks of your application. And so, it’s really a way to think about the different levels of components that you’re going to have. And Brad Frost does an amazing job. He created the framework and the concepts, I highly recommend checking out his stuff. You don’t have to call things what he calls them, but the concepts are the most important thing.

Read our 2019 Guide: Build, Understand, and Benefit from Component Libraries for Advanced Organizational Efficiency

So having a cascade of things and starting with the smallest element as it were, the things that can’t be broken down any further, and building up from there will allow you to have the versatility that you need to be able to have components that can function in different places, that can be broken down so that you can reuse all kinds of levels of items in your component library in various places. It just creates so much consistency, and people really pick up on that. And it’s a way that you can provide consistency, which is one of the measures of a good experience, just systematically and fundamentally in the way that you do your work.

And so from a design standpoint, it’s a way of thinking about how you actually design an experience. And it’s a way that actually benefits everybody involved. It benefits the designer, the developer, it benefits the business, and it benefits the customer.

Kat Perez: In Atomic Design, Brad Frost came up with this really easy and logical methodology using the natural world structure. There are five different stages of atomic design that all exist at the same time. That includes atoms molecules, organisms, templates, and pages. Atoms in the natural world are the building blocks of all matter. So atoms bond together to create molecules like carbon dioxide. So it’s one carbon atom bonded with two oxygen atoms to create the carbon dioxide molecules, CO2.

Watch our 2019 Webinar: Improve Organizational Efficiency and User Experience with Component Libraries and Design Systems

Then multiple molecules combine together to create more complex organisms like humans or animals. This natural hierarchy translates very easily to how you would structure your component library within your design system. Atoms are the building blocks and this translates in your component library to your HTML tags like buttons or form fields. So these are individual pieces that cannot be broken down. And then molecules are multiple atoms combined together to create the smallest fundamental unit.

Think of a search form that has a form field atom and a button atom combined together to create this molecule. It’s not complex, but it can be broken down into multiple atoms. And then organisms are multiple molecules combined together to create a more complex section of your interface—think of a header or a footer. A header could have a navigation molecule or a search molecule all combined together to create this more complex organism.

Read our Checklist: Can My Business Benefit from a Design System?

A component library typically focuses on the atoms, molecules, and organisms, but in atomic design, it also includes templates and pages, which helps you to really fill out the full design system and understand how those components work altogether in the end. Templates are multiple organisms combined together to create pages, and pages are a specific instance of that template—so think of a contact page or a home page. And typically pages include real contents, so you can get a more accurate depiction of what the user actually sees.

So atoms, molecules, organisms, templates, and pages are the five stages of atomic design. This is just a really great methodology to help you structure your component library that actually works.

Episode 3: How Building with Components Changes the Design Process

Episode 3 Transcription:

Devin Smith: But I think that when you have a component library to make sure that it stays something that’s clean and something that’s as simple as it can possibly be, those governance processes are things that you want to put in.

So building an experience with components changes the way that you design. You want to think in terms of systems and tasks over thinking in terms of screens. And so your thinking is better suited with this when dealing with complex dynamic functionality. Something that’s very personalized, like a banking experience or you know, for instance a social media app or a music app. When you think about some of these things, you have to be able to have something that is very fluid that can reshape itself to fit what your user needs, and this is just an amazing way to be able to accomplish that.

Watch our 2019 Webinar: Improve Organizational Efficiency and User Experience with Component Libraries and Design Systems

It’s very difficult to do that when you’re not using something that is systematic and component-based. So it gives you an amazing level of flexibility in how you surface functionality to your users. And it allows you to leverage a lot of things that are out there now that will allow you to put together an experience that won’t necessarily look the same between two users but it’s absolutely what they need and it works based on your system and you didn’t have to necessarily piece every single instance together yourself.

Kat Perez: A design system is a single source of truth that includes all the elements necessary to develop a product. Included in that would be a style guide that is the way that the product should look and feel. So think about the typography scales or color use. And then in addition to that, you have your component library, which we’ve been talking about. In addition to that, there is documentation on the standards and principles in which all of these things should be used. And all of that together is a design system.

Read our Checklist: Can My Business Benefit from a Design System?

Devin Smith: Another thing about it that’s going to change how you do things is governance. Governance without a component library can be pretty tough. I think that governance with a component library is not easy but it’s definitely easier. And so you want to be able to have structures in place to automate as much of that as possible, but you want to make sure that communication is there.

Your governance processes can’t be a replacement for communication. And so that’s the first line of governance is making sure that your team is talking, making sure that there is cross functional discussion happening. Some of the biggest governance flubs that I’ve ever seen have happened when there wasn’t enough cross-functional discussion about what we were making.

And so you want to make sure that designers are talking to developers, that they’re talking to product managers, and that everybody is making sure that the business understands what they’re doing. And so communication’s your first line. Your second line, in my opinion: automation. You want to make sure that you have things in place so that people can have work surface to them automatically so that you’re not having to go and have a one-on-one conversation every time something happens.

Read our 2019 Guide: Build, Understand, and Benefit from Component Libraries for Advanced Organizational Efficiency

One of the biggest things I think automation is needed for is to make sure that with large teams that people are getting notified that somebody is touching a given component. And so you can make sure that two different teams are trying to edit the same component at the same time for a given release.

But knowing that designers are in there working on concepts or working on things for a given component or given experience. The last line I think is meetings. Have regular review meetings and make sure that if something is making it to a review meeting that is not the first time that it’s been seen. I highly recommend having a final review that makes sure that things are working well, that it works well within your design system.

And again, you should have had many conversations leading up to that, but as a final, last kind of gut check of you know, is this working? Does this work with the rest of the component library that we have? Does this work for the experience? And obviously you’re going to have processes like that in place building a product anyway. But I think that when you have a component library to make sure that it stays something that’s clean and something that’s as simple as it can possibly be, those governance processes are things that you want to put in.

Episode 4

Episode 4 will be posted shortly. Check back soon!

See more from our Capabilities team:

Devin Smith

Devin Smith

VP of Strategy

Devin helps guide strategic direction at Levvel. He brings 20 years of experience in design, advertising, and development across a range of industries, including financial services, e-commerce, retail, and automotive. He uses design thinking to provide a holistic, customer-centered, and cross-functional approach to solving real business problems.

Stevie Palmateer

Stevie Palmateer

Senior Director, Engineering

Stevie has experience developing, designing and delivering .NET applications for Fortune 500 companies. Her real passion lies in bridging the gap between product design and technology strategy. When not working on a technology project she is actively mentoring and guiding young females to succeed in STEM.

Kat Perez

Kat Perez

Senior Director of Product Design

Kat M. Perez is the Senior Director of Product Design at Levvel. She firmly believes in and advocates for the importance of human-centered design. Kat is a multidisciplinary product designer with eight years of experience in designing user experiences for multi-platform web applications. She has a strong background in User Experience Design, Interaction Design, Visual Design, and Front-end Development, with a proven ability to lead and mentor design teams.

Related Posts