14. Taking one step back and four steps forward
This week’s newsletter is late because I’ve spent the last week with my team standing in front of whiteboards planning the big v1.0 release of cosmos (the design system I work on)
I put the first commit in November(!) and it’s taken a lot of time and effort to get where we are. The whole team works remotely, so being in the same room for a few days is unique and perfect for discussing the long term vision of the project.
One of the big things I’m excited about is making all our components accessible, it’s something I know nothing about and would be a lot of fun to learn.
The fact that we all met in the Buenos Aires office is a nice bonus. This post is brought to you by cute cafes and good coffee.
I’m not a fan of big planning meetings because it feels like busy work - it’s a lot of work that doesn’t result in pixels on the screen or features in users’ hands. But, it’s necessary for any project that has a life longer than a few months.
It’s very easy to get lost in the code, the pull requests, dragging tasks from one column to another, etc. A big takeaway for me from all the whiteboarding and discussing was a reminder to look at the big picture.
Being able to visualise the whole project and keep it in your head at the same time is extremely beneficial! (It uses a lot of umm head RAM, so it’s difficult to keep it there for a long time 😅)
No big deal, just all the bazillion ways people will use our components! 😱
It gave me ideas on how we can improve the system all across. And I’m not just talking about visual patterns, I mean API consistency, token strategy, development environment and a bunch of other things.
That’s very abstract, so here’s a super specific React example:
Here’s are 3 components that look very different and seem independent at first. But, when you keep all of them in your head at the same time, you notice they all have a trigger/action for the user and display some content in an overlay above the content of the page.
A consistent API for this should look like:
// API structure:
<Trigger overlay={<ComponentToDisplayInOverlay}>
This is what the user will click on
</Trigger>
// Example:
var menu = <Dropdown.Menu>all the options...</Dropdown.Menu>
<Dropdown overlay={menu}>
<Link>With divider</Link>
</Dropdown>
But it’s really difficult to come up with this API when looking at just one of these at a time.
When you look at things from high above, there’s some motivation factors that come into play as well:
- Seeing the finish line pumps some extra enthusiasm in the team. I can see how all those months of work will coincide in 3 months. (The components are already are used on production, but there’s something special about removing that beta tag 😋)
- We were able to list down all the things we have almost no idea about. It’s scary but now we can plan the time it will take to research and do a good job at some of those topics (like accessibility), which makes them a lot less scary.
It also gives you a chance to question some of the old decisions we made. The decisions I’m most afraid of is building our component library entirely in React. Most of the products are either in React or migrating to it, so we’re good for now.
But, it’s only a matter of time when a team tells us they are adopting Vue or web-components ¯\_(ツ)_/¯. I would hate to tell them that we won’t support them. We had a chance to discuss our old decisions, explain them to the new members of the team and plan a strategy for the future when we might have to support another framework/technology.
I highly encourage you to take some time and look at your project/team from 10,000 feet above and question if you’re going in the right direction and more importantly, are you focusing on the right problems?
Hope that little peek inside my world was helpful in your journey
Sid