When is it time for a style guide?
In a month, I’ll have been a Software Engineer at CallRail for three years. When I first talked to Andy and Kevin (CallRail’s founders) they pitched the job with something like, “We need someone that cares about the UI in extreme detail to come in take over that part of our application.” The company was super small but had amazing growth numbers. So it sounded like a no-brainer next step for me.
Since then I’ve opened over 650 pull requests. The vast majority of those had html, css, and javascript. It started off pretty sane when I joined, the app was built on Bootstrap 2.3 with a few minor tweaks here and there. As new features came up, I cobbled together an interface and built it, adding new css files and overriding Bootstrap as needed. This got us by for a little bit, but my design skills are subpar and we wanted to take it to the next level.
So we hired an amazing designer, Bruno, who joined and gave us a fresh look. It was my job to build what he came up with. Being a competitive startup, it was always about how can we get this done in the most efficient manner. So back then, when the question came up of upgrading Bootstrap or removing it, it was a pretty quick decision. Do as little as possible to accomplish the most. We wanted the biggest bang for our buck, if you will. To be honest I’m glad we didn’t go down the path of removing Bootstrap that early, it’s a lot of work as I’ve come to find out. So I implemented Bruno’s design. I touched over 1000 files and it was one of the most nerve-racking moments of my career. With that being said, I’d like to think it went really well.
Bruno lived out in Spain and wanted to learn more about programming, so he moved on to pursue his new goals. Since then we’ve hired a few designers (who are also amazing), have an actual product team now, and have a team of developers cranking out features left and right. With that comes growing pains. More code and interfaces to review than we know what to do with. As an early employee and someone who lives and breathes by our interface, I take it personally when people say negative things or there aren’t positive vibes. I’ve always tried to keep my eye on every new interface that went out the door.
Making sure all the new features look cohesive and prevent us from looking like a junkyard is nearly a full-time job. On top of that, trying to police pull requests and speak up at product handoff meetings about things not following a standard is very hard… especially when there’s no written standard. As more and more people joined the team it became pretty much impossible for me to actually build things and do this. This was a clear sign it was time for some sort of change.
I spoke to several teammates and everyone had the same general feelings. We needed a source of truth for our UI — a style guide. Now that the team was pretty large it was going to be a little easier to pitch the idea and get the time allowed to do it. A plan was put together and approved, so we started on our venture and about two and a half months later we had it. I’ll be putting together another article about that plan and how we accomplished it. The key here is to not overthink it too early. We got by the three years I’ve been here without a style guide, wait until growing pains start kicking in and then solve the problem.
EDIT: The second article is out now, “Building a Style Guide”, go read it!
