Icons Architecture
About Icons Architecture
Icons was a bottom-up initiative from Indeed to help improve the ecosystem of icons.
It existed because a bunch of us devs and designers from at least 5 different teams got in a room and said that the icons are terrible and we want change.
Some problems were lack of consistency, lot of teams manually create their own icons, and the existing library was frustrating to use.
This diagram is a detailed vision to outline how to improve our icons and fix the system.
Why invest in icons: How a system improves
One dilemma that most teams face is speed or quality. Do I deliver something quickly or build it the right way? For most teams, speed and quality is a tradeoff.
In typical web development projects, creating an SVG spritesheet is not even close to being in view of scope. It's common sense that it's not a priority. But in a system point of view, it's common sense to invest in something that creates quality and speed for all with a push of a button.
This system-level investment affords performant and quality icon solutions for all teams. They spend no resources, they don't need to be the experts, and everyone gets the best implementations.
When companies consistently do things like this and keep investing in system investments like icons, quality of the ecosystem improves and the business will operate on a different level of efficiency and excellence.
How the new ecosystem works
Contributors contribute icons to a central registry of icons.
Through the website or tools run by the icons team, icon users can export icons in many different formats suitable to their project needs.
The icons team is responsible for scaling the quality of icons across the company by defining and aggregating standards and best practices, providing tools and resources to everyone, and building two-way relationships between them to understand the team's needs and incorporate them into system-level improvements.
Benefits
Icons are no longer an after-thought but a clear focus.
By having one team serve the many, one-off implementations would be eliminated.
Teams would adopt performant and properly designed icons without spending much work for themselves.
Noteworthy Parts
Below are noteworthy parts to share my thinking and philosophy. These sections are intended for a technical audience. It is not for the faint of hearts, so come if you dare!
React Icon Component and Separation of Concerns
Before the icons initiative, the existing icons in React had icon svgs manually stored in the <Icon> component itself.
Why is this wrong?
- Having the icons stored in the
<Icon>is actually a root cause for why teams created one-offs. If you need an icon that's not in the component, you would either create your own one-off or follow the contribution process, which can slow down your project. - It's not performant. You won't use all the icons, but the app would load all svg's every time you render an Icon component.
- It's not scalable. If other teams contribute icons to the Icon component, that would inflate the icon component in your project even more, creating ties. This coupling creates unwanted ties.
Instead of making <Icon> contain all svg icons, <Icon> takes in a set of icons (like a json).
The set of icons could be a custom set (some of your own icons or some icons from the registry).
The set of icons can be dynamically generated and exported for project use and the dynamic generation is general purpose enough to support custom icons for project teams.
Dynamic generation can be done with generators like Gulp or Webpack.
With the new separation of concerns...
- Icons are more interoperable and customizable.
- The bad couplings from before are removed so things are more maintainable.
<Icon>is more performant than before.
Exportables and Inclusion
You may be thinking, why do we need all these different formats? That's overkill, cut them in half! CDN's? That's not a priority.
The reason this line of thinking can be a mistake is that it can be exclusive.
The way an architect thinks is how to include all use cases, anticipated and unanticipated. That's what the Exportables piece is trying to do. The diagram is about shotgunning all possible consumable formats to visualize anticipated and unanticipated needs and solutions scalably.
Now you may be thinking, unanticipated use cases? To cover the unanticipated needs creates business value.
- Sometimes there are nuanced use cases like the Japanese character-based pagination buttons in my pagination component.
- Sometimes making a capability that didn't exist enables teams that never considered the possibility, especially if they were in the "world of speed or quality".
- And you can't always make the argument that "there's no one who uses it, therefore there's no need for it" because sometimes that could be survivorship bias.
When you're only covering anticipated use cases, you often create patchworks and pigeonhole yourself into a mode of narrow solutions only, not holistic ones and that can lead to people feeling like your thing can't be used so they make their own solution.
While I'm not advocating to implement everything, I am saying that planning for unanticipated use cases is valuable to inclusive solutions.
Scaling Quality to All: A Model of Success for Organizations
In my work for Lookingglass, I tried to scale the domain knowledge of SLOs to all users by baking in the best practices and technical correctness in the user experience. Users can produce expert level results without being the expert.
In Box, Box was also about integrating expert level results in the user experience. I made it so a developer can produce perfect css layouts without touching css. What happened as a result was that one technical business analyst I worked with took and ran with <Box> and built his layouts according to my designers' designs in a single afternoon while I didn't need to do anything. A non-frontend developer built perfect layouts according to design because of the <Box> component.
What I am noticing in Lookingglass and Box is a model for success. I am turning domain expertise into integrated user experiences. And the value is that non-experts are able to produce expert-level results.
The icons team is the same. The two qualities of the team are...
- Domain Expertise
- Scalable and Inclusive User Experience
The key factor is integrating to the user experiences of ecosystems.
By integrating to the user experience, you are making domain expertise more human and less esoteric and you are investing in the happiness of an ecosystem.
Happiness? Is that really that important? Some may think, happiness and quality of life is not important, has no monetary value, and is not worth the investment, but I would argue that happiness and quality of life is the fundamental reason why we work. Focusing on happiness and quality of life is the difference between living in a world of hell and heaven. A heavenly world and ecosystem is definitely worth the investment! It is the point!
Ending Note
Icons was my attempt at improving a system.
It shows my abilities as an architect and my passion for systems and cultures.
My old boss once told me, I need to be able to influence like an architect. To this day, I am actively trying to get better at explaining, teaching, and bringing things down to a human level. I don't believe I'm there yet, but when I do, I will be ecstatic to be a positive influence.