As someone hoping to find a job within the UI/UX field of computer science, I was amazed at how little I knew about how a design system team works. My classmates at university were the same. They too didn’t realise the scale of these teams and had never come across the phrase “design system”.
This internship has been a crash course in why design systems are so important. I think it’s something more students should know about.
Okay, so what is a design system?
A design system is a catalogue of the fundamental building blocks and best practices that make up the user interface of a product. This includes foundations like colour palettes and typography, reusable components like buttons and data tables, and patterns that solve common interface problems like form validation or loading states.
An engineer building a feature like a login page doesn’t need to start from scratch; they can go to the Design System documentation to grab components like buttons and use patterns like error messages. They can do this knowing they will all fit the FreeAgent style as they’re using the foundational colours and spacing. This speeds up the process, creates consistency in style and quality, and allows for central control of these elements. It’s like using constants in coding – set the value once (and well) and it’s much easier to use or update later on.
So, what does that look like day to day? Here are some of the main roles the team takes on, and some of the things I got to work on this summer.
1. 🔍The Detective Work (aka Research)
Nothing gets built without a plan. Before writing any code, the team does thorough research to figure out the best way to build a component. It’s all about making sure it’s useful, efficient, and accessible, as what goes into the design system will be reused throughout the product.
- What I did: I helped research a potential new feature for our data table component. This meant seeing how other systems implemented it, assessing if those approaches would work for us and checking if it aligned with our coding practices. It was a great experience to take an idea the whole way through the research process and learn what industry experts advise when constructing this type of component.
2. 🏗️The Construction Zone (Building Components)
This is where all that research is put to use. The solution found in the researching stage now gets built, tested and iterated until it’s working at a high standard. This building stage could be building a brand new component or adding in new features to already existing ones.
- What I did: My first project was helping to add a new “total row” feature to our data table. This was my deep dive into the codebase. I spent a lot of time using the Visual Studio Code search tool to figure out how everything was connected, untangling that “Ruby magic”. It was a great project for me to get comfortable with the code. Later, I built a “compact view” for the same table – this made use of the knowledge I gained from the previous project as well as challenging me to learn more. These are now up and running on the FreeAgent website and it’s amazing to know that something I built as an intern is making a positive impact for customers.
3. ✉️The Mail Room (Communication Across Teams)
A design system isn’t a good one unless it listens to what other teams need. A large part of the job is encouraging other teams to come to you with problems, or things they think would improve the system, and making it happen. Collaboration is the only way to have a well thought out system.
- What I did: I saw this in action when another team asked for a new, smaller size for our Avatar component which I then built and shipped out for them. This was a great example of how we collaborate with others teams to add current, needed pieces to the design system to help them out.
4. 📒The Handbook (Documentation)
Even the best component in the world could be rendered unused and useless if it goes undocumented. Good documentation, with examples, dos and don’ts, and code snippets, is everything. It’s like someone asking you how to make a cake and you just hand them the finished product: great in the moment if they’re hungry, useless in the future when they want another cake.
- What I did: For every single thing I built, I also wrote the documentation. This outlined the changes made, explained my work, and gave example code to be easily used across the site. Not only is this important for others, but I also really enjoyed the process of looking back on the work I’d done and condensing it.
The Takeaway
My university courses gave me a great foundation for front-end development, but this summer taught me what truly holds a large product together. Getting a real feel for how development works at a larger scale taught me so much; I feel that I am walking away as a better and more thoughtful programmer.
So if you’re a student exploring the front-end development world like me, I’d encourage you to have a look at the design systems hiding underneath the websites you know and love. It’s where you’ll find the work that makes these great products cohesive and allows them to add new features so quickly. For me, getting to be a part of that process on the design system team has been an amazing way to spend my summer at FreeAgent.