The Evolution of a Living Design System

An insiders look at how UX at Teem is bridging the gap between our design and engineering tribes through a living design system and prototyping tool we call Hive.

#Startup

When I decided to join Teem two and a half years ago (then EventBoard), we were thirteen employees total: several backend and native engineers, one frontend engineer (me), a designer, a few sales and support folks, and the founders. At that point in time there were no “teams”, only a hippie drum circle of scrappy startup folk doing whatever it took to be successful.

Fast forward 2+ years and Teem has been fortunate enough to experience incredible growth. Our product development department is large and growing. We’ve organized the different disciplines required to launch a new product or feature into what we call chapters. For two years I have been leading our front-end engineering chapter. We also have a backend chapter, one for native apps, systems/ops, QA, data architecture, and data science.

Noticeably missing from that list over the last year has been a UX and design chapter.

For a myriad of reasons, our design team never grew like the rest of our teams. As our business expanded and the product and engineering needs ballooned, it became increasingly difficult for our scrappy designers (myself included) to reconcile the desire for a lofty-goaled and detail-focused design culture with the real life demands to ship features and iterate at a lightning pace. It seemed like every new feature required rethinking huge parts of our visual language, and attempts to get ahead of the process resulted in designs that were so far ahead of our engineering cycle they became stale or unusable. As a result, the design and UX team was eventually absorbed into different departments, and all that was left were a few engineers who also did the design.

Don’t ever let this happen.

Needless to say, we’ve learned some difficult but valuable lessons not having a team of dedicated UX and product designers, a few of them being:

1. Engineers, as well as designers, can and should be stewards of a good UX, and a great UX requires equal involvement from both.
2. Engineers want their work to be well designed and intuitive to end users just as much as designers do.
3. In an absence of a strong design culture, engineers will become some of the loudest proponents for establishing one.
4. Silos should be reserved for storing grain, not for organizing your product teams.
5. Engineers and designers may speak different languages, but they have vastly more in common than not, and both disciplines are most effective when working side-by-side using their different languages to solve the same problems in the same time period.
6. Validate the ideas designers and engineers come up with early and often. If you don’t then you’re going to end up wasting a lot of time getting a solid product to market.

So how are we fixing this? A living design system.

Enter The Hive Mind

Lacking a design team, most of those basic responsibilities naturally fell onto the frontend engineering team. My team. Early on we had established a library of common UI components and styles that we were using across most of our web based applications. We weren’t trying to be designers, just good frontend engineers. We definitely didn’t view our library as a design system initially, but as requests trickled in from other chapters to use our styles or rebuild a UI components functionality into a different platform, it became obvious that the frontend team’s shared library was the closest thing we had to a design system.

We had built the base styles and many of the components in our library to be agnostic of the frontend stack that was consuming it (because we have several), but what we really needed was a library that was entirely platform agnostic.

Our shared library had a new purpose, to become a living design system that any engineer or designer working on any platform could contribute to, use to share new components and tools internally, and use to quickly build new interfaces without needing to rethink our entire visual language.

This isn’t a new idea by any stretch. Twitter’s Bootstrap has been around for years, but is specific to web applications only. Apples Human Interface Guidelines have been around even longer, but are specific to native apps. We felt like Google’s Material Design did the best job at creating very rich design guidelines and component UI’s that work for native and web apps alike, so we started to rebuild our shared library to be more in line with Material.

We named our new design system Hive as a nod to our Ender roots, and in spring of 2016 we launched an internal site called Hive Guides to visualize and document our design system. With what we had already built, supplemented by the brilliant minds at Google Design we felt like we finally had a solid foundation on which to build our product.

If there was a UI element we didn’t have in our system, it was easy to point engineers to the Material docs for guidance on how to build it. Even better, there is already a wide selection of open sourced Material themed plugins and frameworks built for the different stacks we are using.

Once our engineers had implemented a stable working version of a Material element we would document it in the Hive Guides, which quickly started to resemble something between the Bootstrap and Material Design docs. Under the hood we used a combination of Atomic Design principles, OOCSS, and BEM for organizing and building each component, so being modular in nature it’s easy to provide usable examples of the components documenting themselves and a widget to simply copy a snippet from Hive Guides into any project. If everything is plumbed properly it should just work.

We were really happy with how the Hive and Material Design union was progressing. It felt like a match made in heaven… until it wasn’t.

Identity Crisis

After a few months of relying on Material more and more, it became painfully obvious that our remaining designers, and our product as a whole, were beginning to suffer from an identity crisis. Our web and native UI’s looked too cookie cutter and boring. The iOS team struggled to balance Apple’s Human Interface Guidelines with Material Design. Only the Android team was happy. We also noticed the usability and discoverability of features suffering because of certain aspects of Material that just didn’t work well within our product. Some of this was our fault for implementing it incorrectly, but not all of it. I’ll put it this way, when parts of your UI are described by high profile clients as “That big orange pumpkin”, you know you have a serious problem.

Not coincidentally, around this same time customer complaints about the usability and experiences on our platform started to tick up as well. A design system built on Material wasn’t the answer, we needed our own identity, and one other vital but missing ingredient. User Experience.

UX101

Prototyping and testing our product from a UX standpoint is something we had only talked about in theory, we didn’t have a process in place for actually doing it. We started by designating time in our engineering sprints to account for product design, UX research, and UX testing. Designers were required to attend sprint planning with engineers and design stories were added to our kanban boards next to the engineering tasks. This helped us close a huge gap in our development cycle by being able to sequence handoffs from the product scoping and design phase to within a week or two of engineering.

Prototyping eventually became the biggest bottleneck to improving our process further. InVision and other prototyping tools work really well for designers to quickly test and iterate on designs and wireframes they’ve built from scratch. But what we really needed was a prototyping tool our designers could use with the components we already had in Hive.

We built on a rudimentary prototyping lab into Hive Guides, and after only a small amount of copying and pasting we were able to build fully clickable and responsive prototypes of new features and experiences and hand them over to our product managers for user testing, all with very minimal effort. Prototyping at Teem using our living style guide was now something that potentially any entry level designer or engineer could do. Even better, the prototypes we were building for our web apps were already 70% usable by our engineers. The handoff between design and engineering was easier than anything any of us had ever expected.

We were well on our way to figuring out how to solve our UX problems. But what about our identity problem?

Meet Teem

In October we officially rebranded from EventBoard to Teem. In the months and weeks leading up to the rebrand our newly integrated engineers and designers had lofty goals to use the rebrand as an opportunity to really flex the capabilities of Hive as a full fledged cross platform design system.

The first thing we did to prepare for the rebrand was update the base styles and components in Hive with our new Teem branded look and feel. Almost overnight we had replaced many of the aspects of Material Design that weren’t working with our own Teem branded elements. We used the documentation and prototypes we had already built within Hive Guides to catch the obvious problems. For some of the more wide reaching changes that would be introduced with the rebrand we created new prototypes and updated the documentation with additional UX guidelines for developers to reference as they updated their respective products.

There was still a huge amount of work and effort that went into updating our entire product, and some parts are still ongoing. But if our goal was to prove Hive as a core piece of our product development process going forward, it passed with flying colors.

What’s next?

Hive is a “Living Design System” so we don’t plan on ever calling it complete, and there’s still a huge amount of work ahead of us to really bring it out of its cocoon. It will grow and evolve as our brand and products evolve, but at least now we know the foundation is strong.

The prototyping tools we built are still rudimentary and in some instances we still find ourselves supplementing them with InVision prototypes when we probably don’t need to be. So we’re beginning to scope how we can convert Hive Guides into it’s own web-app using React or Ember to make the prototype and documentation tools more powerful.

We’re also working on updates to make Hive easier for our iOS and Android engineers to contribute to it, and use in their projects.

Who knows, as our API advances it might even make sense someday to open source Hive so that our users can take advantage of what we’ve built to build their own unique experiences.

The future of UX at Teem is bright, in part because our experience building Hive has proved that there is real value in a living design system beyond style consistency. It can alleviated major pain points in how designers and engineers work together to build a product, and it might just end up being the most powerful tool in your toolbox for crafting a solid user experience.

A Note On Design Systems

If you’re looking for more info on what a design system is, if they’re valuable, or how to build one, there are countless articles on Medium from very respectable companies and designers that I highly suggest you read. I wish I would have a long time ago, it probably would have helped us avoid some of the growing pains we experienced here at Teem.