Build your own primitive UI
January 08, 2020
I have seen many teams, in the spirit of moving fast and getting the product to the market, outsource their UI. By outsourcing I’m referring to using a use third party design system, UI kits or frameworks. This third party systems were made to cater the needs of the creator and not of the teams, which leads to making compromises since they don’t fit the teams need. In this post I will argue against using third parties systems. Instead, teams and individuals should start building one a set of components, called Primitive UI, to build Frontends (web or native).
Quick note, if you are not interested in reading here is one I have been working on for my personal React projects using fela.js as a CSS in JS solution. It can be used freely as inspiration. However, if you still want to use your a third party then check out rebase js.
Otherwise lets continue by defining what a primitive UI is.
What is a primitive UI?
A primitive UI is a set of baseline components to build more complex or sophisticated UIs. A great example are HTML
p, div, input, button. We use them to build web pages and apps. Once the components get more complex e.g.
date pickers, calendars, dialogs then it starts to become a UI kit or framework. and not a set
of primitives. If done correctly a primitive UI can become a part of a Design System, which we define in the next section.
What about design systems?
A design system is a set of principles and deliverables that allows teams to design, develop and deliver a product. So, a primitive UI is one of the deliverables of the design system. The other deliverables are: style guides, documentation, guidelines, principles. In addition, we have identity/branding elements like colors, fonts and images. Finally, we have iconography and layout guidelines.
So, companies should strive to create their own design system to help teams lower the the time to develop consistent and great product experiences. I will get back to this topic later in the section titled “A deep dive” and how a misunderstanding on the responsibility of Frontend developers make their jobs harder.
Why do I need a primitive ui?
You may thinking why not just build a design system then? A design systems are expensive to build and are continuously evolving: they are living things. If your ambition is to build one you still need to start somewhere and a primitive UI is a great start.
Why reinvent the wheel?
Developing Frontends is not deterministic. Just because somebody else has build it doesn’t mean that their solution will solve your problems. I understand that currently we use a lot of libs and packages that other people build for building our programs, however most of the useful ones are categorized as tooling.
Check the history of any popular third party components: they start by solving a problem and do it well. So, when they gain popularity people start making feature requests. Then, the owner in the spirit of open source, craftsmanship and pride, she starts to add features to satisfy every need making the component more complicated to use, subject to more bugs and contributing to the a bigger bundle size.
At the end, like in Object Oriented Programming:
You wanted a banana but what you got was a gorilla holding the banana and maybe the whole jungle with it.
Writing your own solution, caters your needs and lets you have control of one of the building blocks of your product. So, yes it might save you time in the beginning but in the long haul it becomes more expensive.
Lets dig deeper on the benefits of building your own primitive UI.
A deep dive
From a Frontend developer, in this section I will describe the main motivation.
Building your own primitive UI helps you and your team of developers decrease the number of unknowns needed when implemented designs Also, it gives you control of the core of your product, instead of outsourcing to a third party (even if is “free” and open source).
The added plus is that a primitive UIs os a great start for a design system. It will give you feedback and enable design teams to test run their ideas and get feedback.
Building interactive Frontends is really hard. This is mainly due to the lack of control of the medium, the high level of interactivity and the revolving door of designs ( due to product changes or feature requests). Here is an example of common information needed to implement a design:
- the grid system
- color codes
- different states and corresponding designs (eg hover, click, back, loading)
- copy specification (font size, the font, font color, etc)
- spacing between elements (if not defined by the grid)
- expected behaviours to any action
- how to visualize errors
- the content
Generally, a Frontend Developers (or FE developer), gets a high fidelity mockup in some fancy tool (eg. figma, sketch) with the expectation that it provides enough information to implement the designs, which it does not. The developers needs information one way or another, or they will need to make educated guess (which will take more time).
Designers think that having a tools that mocks interactions and shows the different states of the application is enough to build it. Maybe we have a ticket or story stating the expected delivery, however we still need more information, to successful implement.
A primitive UI develop with the support of a designer helps by not needed to transmit the information on every design. Instead the set of components provide it. A third party system or component library like Material UI (Google) or Atlaskit (Atlassian) will carry with them the information that developers need when build UIs for them and not for us.
Cater your needs, build your own and if you don’t want to start from zero use mine that I have been working on for my personal React projects.
Occasionally, I write my opinions on software development. By Geries Handal. Github