Discourse has been charted
Recently I was in a discussion about our approach to component-based front-end web-design with a colleague; we were looking at some screens we were going to rebuild (actual screens as we were doing a port-over to React-Native from another version of an app built in Xamarin) and found ourselves confusing office co-workers with the jargon spewing forth from our over-caffeinated mouths.
There was an action button with an Orbitron font, wicked green text and outline, and a black background that was in use all over our app. We were talking about it, only we weren’t referring to it as a button, we were calling it an “atom.” In several places it was in use in conjunction with a few other features, typically along the lines of some sort of form-one-liner like an input-field of sorts and perhaps a label and/or placeholder and then a color scheme specific to our app itself and potentially unique to this specific combination of elements. Only we weren’t saying this specific combination of elements; we were saying “this molecule.” And obviously the confusion to unknowing passers-by arose from the fact that they were pretty sure our department didn’t have any chemistry-related undertakings of which they were unaware. We weren’t questioned about it though, probably out of fear that a question might result in an instant-regret-inducing, boring conversation from which extrication would be accompanied by anxiety and require consulting one’s own inner Ethan Hunt (and the accompanying theme song to mission impossible).
I get that. I too would have had my hesitations. But we weren’t talking about chemistry; we were using a clearly defined ontology as a means to an end- that end being design efficiency. We totally sounded like nerds because we were excited about it, but I think we had a right to be- it was working.
The previous fall I had gone to the Connect Tech conference in Atlanta where I’d seen a talk which provided me with a compass for getting to where I stand with this direction at present (forgive me for I cannot even recall now to whom I should direct gratitude for this). During said talk there was a brief moment of reference to the article on Atomic Design I posted a link to above. In that moment I stopped listening to the speaker. The gears of Eureka he had inspired were turning too loudly to pay attention for the next several minutes. I considered how solidifying the concepts I had been using... into a coherent approach, replete with pre-determined diction regarding the domain of discourse... would solve a problem I didn’t even realize I had! What I had failed to realize prior to that moment is that I had, in all my previous team discussions about components, failed to make clear and consistent distinctions about components related to their size! It struck me then that fostering effective component reusability across projects and teams would require being on the same page, starting with clear ontology. No longer would I be calling a component simply that, lest it be misunderstood for exactly what it was. Nay! From here on out the scope of each component would be clear, allowing separate developers, building their respective organisms/molecules/atoms to coordinate with one another and not pull double duty on decidedly reusable code.
So if one developer was building a molecule-size piece of UI, and another was going to be consuming some atoms in that molecule, or even the whole molecule itself, we could ensure that those pieces were configurable so that the devs could use them as soon as they were ready and in the meantime focus on other aspects of development. This is something we were already doing, and hopefully your team is too, however, with the conversation of consumability assessing the pieces of the UI all the way down to the atomic level, we were now doing so universally. The consistency and performance improvement from this seemingly minor shift in design-thinking is nothing to be scoffed at. If you’ve ever enjoyed the convenience of a UI component library then you already know how amazing it is to be able to quickly consume components. We use this approach in tandem with a UI library (native-base) since font, font-size, color, etc. are all unique to our app, even a simple button will have several props that need configuring.
Getting your team on board with a new approach isn’t always the easiest thing to do, but the structure laid out in atomic design just makes too much sense to ignore.
Elegant Software Solutions