Design System Kickoff - Hackathon
This is Part 2 of a multi-part blog series that follows the Design System project at Turing School of Software & Design. Read Part 1 here.
Our software team was ready to start dedicating time to build a shared design system for our suite of applications and sites. Research and discussions around tools and solutions had been happening among a few teammates, but not across the entire team. A Hackathon over our week "off" felt like the perfect opportunity to collaborate on the upcoming project.
The Juicy Details
Hackathon Kick-Off
We kicked the Hackathon off with a session that helped us ensure everyone had a shared understanding of the project goals, risks, milestones and unknowns. Katelyn made this Mural template which provided a great structure for the conversation. By using Mural tools like private mode and the timer, we were all able to have our own time to process and ideate without falling into "group think". This series of exercises helped us build a shared understanding of the overall project as well as how we might best use our time for the Hackathon; narrowing in on the purpose and goals of this special time together.
Working Sessions
After grouping areas of interest in the Exploratorium on the Mural board, we decided to break off and do some work in small groups. Over the next day and a half, we had three working sessions for researching, brainstorming and spiking. Some of this was independent and some was paired. During each session, we were working to answer a question that would help us move forward. At the end of each session, we came back together as a full group for 30-60 minutes to share out what we learned, document takeaways and next steps and determine how we'd use our next session. Here are some of the questions we asked and topics we explored in our working sessions:
- What are our guiding principles, the North Star that will guide our decisions? The Guiding Principles we came to can be found here.
- How will we build our documentation site?
- How will we host this design system in a way that allows all our various apps and sites to consume it?
- What would hosting on a CDN look like?
- Do we want to build our Design System on top of TailwindCSS?
- What can we do to make this as easy to maintain as possible?
- How will we version the design system?
- What does the path to our final product look like? How long should we estimate this will take?
- Could we build our design system inside of a Jekyll site to keep the source of truth as contained as possible?
Big Decisions
- We outlined a rough timeline and order of bodies of work for the next 7 months. We fully acknowledge that it's unlikely we will stay on course, but needed a bit of a roadmap so we were all clear on the direction and priorities.
- We decided to start by hosting the design system on a CDN. If, down the road, we want to add dynamic components that require JavaScript, or have other needs, we can always build a ruby gem or npm package.
- We decided to use a homegrown approach and not bring in any other libraries or frameworks. After a long pros and cons discussion, it was unanimous that this solution feels simpler and gives us more control, and seems like a more interesting route to take that we will all enjoy and learn from.
- We will use SCSS to take advantage of imports, mixins, for loops and the ability to nest rules. SCSS comes built-in with Jekyll and is already a Turing standard.
- We will build our documentation site with Jekyll. It's a Turing standard; most of our static sites are built with it and we are already comfortable with it.
- We will call the design system Savile. Savile Row is a street in London that is known to be the home of upscale men's tailoring.
Tips for a Project Kickoff
- Get the team on the same page. Put the time in, sooner than later, to make sure all team members who will be working on the project have an understanding of the purpose and motivations of the project. What impact will this product have on the company? On individual users? Other team members? This may include welcoming their contributions to the creation of that vision. The perspective of various stakeholders should be solicited and those should be transparent to the team as well.
- Give choice. Providing the team with flexibility to work independently or in groups, have choice on topics and potentially move around several topics is empowering and allows each team member to be at their best. This can also help continue the context building noted in the previous point.
- Prioritize decisions. In any project, the number of decisions the team will need to eventually make may feel infinite. You don't need to answer every question now; but you do need to start somewhere. Some priorities may come from a strategic lens (X must come before Y) and some may come from a more human lens; if team members are curious or anxious about something, exploring it now may be worth the time so they feel they have the necessary context and/or mental capacity to move forward.
- Document your decisions and work. If you've made some decisions and started some work and you don't have a good system for documenting and communicating, pause the work and get that situated sooner than later. The larger a team is, the bigger of an impact this is likely to have; but even small teams need to document and use systems that make sense for everyone and are sustainable to maintain.
What's Next?
Taking the big decisions and rough timeline into account, we have some clear next steps about how to move forward. In the coming weeks, we'll share out on our progress and updates!