I’ve always approached design in a systematic way. Thinking about things in basic pieces that together form other pieces.
I remember assembling those plastic car models when I was a kid, and always starting with the basic parts, that by themselves didn’t form anything, but once assembled with other parts, they’d form a vital component of the car.
I’d isolate the rim, tire and bolts, and focused on them individually to form the wheels. Then I’d join the wheels with the axles, and suspension to form the front-end. And finally, the front-end would be assembled to the chassis to complete the car.
I did this for every section of the model. I never tried to assemble the complete car all at once. By doing this, I could ensure that each part was precisely assembled and functional, which would make for a better car model at the end.
This has been my approach to product design. Instead of designing a screen or page, my method is a design system consisting of Elements, Components and Templates. Each a different stage in the process.
Brad Frost’s atomic design is very similar to my approach, but with additional stages. I definitely recommend reading it.
Here is how my system works.
Elements are the core parts of a design. They’re the buttons, input fields, checkboxes, radio buttons, drop-down, icons, colors, type styles, grids, and so on. These are some of the standard elements, but each design will dictate its own set.
I think of elements as the “seeds” of my design. They start off as a single thing, and then grow into something more useful when combined with other elements.
First, I design the elements individually. I really like to focus on how the element is formed, and the details associated with it. Then I look at how the elements work together and adjust from there.
A component is set of elements that are assembled into something functional. They’re self-contained and usually focus on doing a single task. Combine a header style, a paragraph style, a close icon, a color, and a button to form a modal. A search form, footer, and a filter selection are all examples of simple components.
Components can also be more complex, like a persistent shopping cart. These type of components still focus on a primary task, but they also allow you to do secondary tasks. For example, in a persistent shopping cart, its main job is to display cart items and total price, but it can also allow you to delete an item, or change its quantity.
Templates are where components come together to form the interface and experience. For example, a contact template on a website will be made up of a navigation, form, and footer components. Templates can represent a single section of a website, and an entire user path, like a registration flow.
I create two kinds of templates: UX templates and UI templates.
A UX template is a wireframe where the content structure and user experience are defined. Here I start piecing together the components, moving them around like puzzle pieces, slowly forming the experience and content structure.
The UI template is where I shape the layout and refine the visual styles, using the UX template for structure. As I mentioned above in the Elements section, I start with designing the individual elements. I then design the components and full templates, and refine any elements that need it. For example, a button might look perfect on its own, but it ends up being too big as part of a component or template.
Folders and Libraries
This system is also great for creating a folder structure, and building pattern libraries.
My top level folder is always the project, usually based on the platform, for example iOS, Android, Web. Within the project folder lives the system I’ve outlined above:
I assign the numbers to keep the folders in a specific order.
Within each main folder I break down the category. So for example, inside the Elements folder you’ll find folders for Buttons, Colors, Icons, Input, Typography, etc. In Components you’ll find folders for Navigation, Search, Footer, etc. Inside each of these folders you’ll find a design file for that element or component.
The Templates folder is a little different. Same idea, but within a template folder I will break it down into two folders: UI and UX. This keeps things more organized. Sometimes components will have wireframes associated with them, so the Components folder can be divided this way as well if needed.
Files are named using the following convention:
So, for example, the first version of a website homepage template done in Sketch would be named web-homepage-v1.sketch.
Not only is this your filing system, but it also acts as your pattern library. The entire system is clearly organized, with every file easily accessible.
If you build these files in a smart way, like using Symbols and Layer and Text Styles in Sketch, or Smart Objects in Photoshop, you save a ton of time when making a change because you just do it in one place. Symbols in Sketch are a bit limited in this case, since they don’t sync across files, but it’s still a good way of setting up your files.
This system also makes it really easy for people new or unfamiliar with the project to find and navigate the files. Great for when adding new members to the team, or sharing files with companies or clients.
Benefits of Systems
For me, designing this way just makes sense. A systematic method provides consistency for the user interface, user experience and functionality. It also offers great flexibility and efficiency, because by designing at the elements level, instead of focusing on a single screen, you’re creating a design that’s modular and scalable.
This method works for me, and it might work for you. I’ve opened up the comments section to get a discussion going. I would love to hear from you if you’ve implemented the system in your workflow, or have any questions or comments.
Special thanks to Stephen Meszaros for his input and always brilliant insights.
9 thoughts on “Systematic Design”
Isn’t this what is?
Our methods are very similar. I point this out in the beginning of the article.
There’s no other way to build a scalable application, physical product, etc. Pretty sure this is what everyone does.
Hmmm, I don’t know many folks who design digital products this way, that’s why I was sharing. If there are, that’s great. Still feel like it’s good to put this out there for folks.
Great writeup, thanks for sharing Antonio.
Though I agree with JesseK, this sounds like a fairly standard way of operating, for any endeavor.
What might be helpful here is outlining the alternative workflows you’ve encountered and why this one works better for you (which would also help others quickly identify if it will work for them or not).
Really well said. I completely agree – this is very much how I have approached things as well and something I seek to continually refine my process in. Especially in the context for large teams, there can be a tendency to do lots of one-offs – often it is not intentional, it is a symptom of the speed of the process and lack of experience or exposure of those doing the work. Having someone in place that can not only drive the design vision but the foster a mentality for dealing things in a more elemental way has proved to be transformative. This taxonomy is really useful as a way to teach others. Thanks for sharing,
Thanks Sean and Tanner.
This method gets away from the “one-off” way of designing. It let’s you look at the experience from a wider view, as oppose to just a single screen that’s part of a larger experience.
Thank you for this article Antonio. I would love to see more posts like this in regards to your own process and ideologies to design.
It definitely helped define a common, yet logical approach to workflow that I, as a younger designer, could benefit more from implementing. I’m still new to designing digitally with UI/UX prioritized, so this is a page I’ll be bookmarking.
Thanks Kelly. Glad you find it valuable. I will definitely be writing more about my process. Stay tuned!
Comments are closed.