Oda’s first design system hackathon
Why we asked our colleagues to Tune In and Slack Off
Kolibri
Oda’s customer-facing design system is called Kolibri, which is the Norwegian word for hummingbird. There are internal stories about where this name came from, but these days (to me, at least) it seems fitting mostly in the sense that these are very lightweight creatures that flit about supporting their ecosystem — just as a good design system should.
Fun fact: A group of hummingbirds is called a “tune”, which gives us a nice link with the name “Oda” and its nod to poetry and lyricism.
So let’s create a tune
At the time the Kolibri team was founded,
had been at Oda for a year and a half (which in Oda-time is more like five years anywhere else— kind of like dog years). He’s always been a developer with an affinity for design, and he’d been working on Kolibri alongside other work for quite a while when designer Martin Gaard was brought onboard. Martin was a great addition, since he has such a strong design systems background. But is two people really a team? It needed something else…but what? Who?Me! I was Oda’s only UX writer and, after a bit of shuffling following yet another growth boom, I was sort of floating around in a global role without a team. At that time, the Kolibri team seemed like a logical choice, even if we’d be working on quite different tasks. But, as we soon discovered, it turned out to be a perfect match.
So, there we were, a freshly minted team of three by the end of August 2021: a designer, a developer, and a writer. All seasoned professionals, all karaoke and pop-culture enthusiasts. It took less than a week before we had established our first in-joke. 🌬 The first of many.
Creating a community
From the start, we agreed that while the team was made up of three dedicated people, the design system wouldn’t succeed if we didn’t involve its users all the way. The word we came back to again and again was community. It wasn’t enough to think of our Oda colleagues as users; they needed to feel like they had a voice in its creation and development so that they’d have a real stake in its future.
The idea of holding a hackathon came pretty quickly and we decided that, since covid had backed off a little at the time, an in-person event in our own office was the way to go — and we had to do it right away. We wanted it to kick off the work we had ahead of us, and to be a way for us to discover what was most important to our colleagues. Our thinking was that if this hackathon was an engaging, motivating and inspiring event — with laughter and snacks built right in — our people would know we valued them, their ideas, and that we wanted them to be in focus. After all, this is the way Oda thinks of its customers, and these people are our customers.
What is a design system hackathon?
As we said in our interview with Design Systems Hour earlier the same week*, it’s not too important to us what the textbook definition of a design system is. This is because at Oda, we like figuring out exactly what we need and building it ourselves. The hackathon was no different. We knew we wanted our participants to get away from their desks and turn off their Slack notifications for two days to focus on design system tasks, but beyond that, it didn’t need to fit to a specific hackathon mold.
Although we worried we hadn’t provided enough structure by simply coming up with a list of tasks and dividing them into “Explore” and “Build” categories, it worked surprisingly well. After a Day One breakfast of smoothies, cinnamon scrolls and raisin buns, everyone found the tasks they were interested in on our Miro board, and the teams just formed themselves. People who had never met, never worked together, or had only talked to via Google Meet, were suddenly heads-down, tails-up teammates working toward the demo on day two.
*Note: Planning a worldwide live-broadcast talk-and-interview session and a two-day hackathon in the same week is a really stupid idea. 🤯 3/10 would not recommend.
How it went down
Our agenda was pretty simple. Breakfast on both days, a cozy social gathering with pizza on day one, and a demo, a party with sushi, music, snacks, beer and Just Dance on day two.
Our teams split off to work on their tasks, but the Kolibri team, true to their name, flitted from group to group, helping out and adding resources, coffee or snacks where they were needed. We made sure there were enough breaks, called everyone together for lunch in our on-site canteen, and generally kept the days flowing.
The atmosphere was amazing. Inspiration and enthusiasm crackled in the air, and no one was just sitting around chatting like it was a good way to get out of normal work. People were really working hard on their tasks, feeding off one another’s energy, and racing to get their work ready for the demo. I lost count of how many times I looked up at the smacking sound of another round of high-fives. Other colleagues came by to see what was happening, their eyes lighting up at the buzz of activity, and told us how they regretted not signing up to join us. We assured them there would be other opportunities, and there absolutely will.
Lessons learned
Let me just note here that I really hate the (non) word “learnings”. Learn is a verb, people! My team knows this is a bugbear for me and I love them for only using it mockingly these days. End rant.
So, what did we learn in two days of design system hacking?
- You don’t have to plan everything in detail. Letting the participants choose tasks and form groups worked out amazingly well and really helped people get to know each other.
- Don’t underestimate how much people actually want to contribute. Most of the contributors chose what we had thought would be “boring” tasks, and they really wanted to help get new components into the design system.
- Some people will sign up for the event and not show up no matter how many tasty snacks, prizes, and evening dance-offs you arrange. 🥲
- It’s very easy to order too much food. 😳 But it’s a great way to bring in others from around the company who might want to participate next time. There was quite a bit of atmosphere-envy that we plan to use as a selling point next time.
- People (and not just Norwegians!) get more excited by a cozy breakfast of fresh bread with a good variety of toppings than they do by sugary pastries. This might have had something to do with the camaraderie we built on day one, but it gave us ideas for future cozy breakfast meetings.
- As much as people asked if we could do this once a month, we see the benefit in making it a very special event that people will really look forward to. There will be others, but not so often they get boring.
- Everyone involved in the event came away with a work-crush on our wonderful, sunny colleague Peter Hilden, who flew in from Finland to join the hackathon. He deserves a shout-out in this summary because he was such a key factor creating a great atmosphere. Takeaway: Every hackathon needs a Peter.
- If you’re going to award prizes, make sure you have a good voting system in place. Pointing at people does not work.
What’s next for Kolibri?
It would be easy to accuse the organizers of a hackathon of crowdsourcing design system work, but in reality, it creates as much post-hackathon work as it generates during the event. There is a lot to do afterwards! The event also generated ideas both for new components (and componentizing copy, which I’m very excited about), as well as confirming our theory that community is going to be the key to our success.
We are now solidifying our plan to hold a regular forum for design system contribution and feedback, which will absolutely include future hackathons.
Design system hackathon: 10/10 would buy again.
