Background
This section of the wiki is still a work in progress.
The Hack for LA Website Project ran into a roadblock where they needed to find a way to "componentize" the website for developers to work faster. Project contributors learned that this process is known as a Design System. The HfLA stakeholder made the requirement that all projects at HfLA should have a design system.
The first attempt at implementing a design system was to ask individual projects to take on the task of making their own design systems, but it was found the results were very inconsistent. The decision was then made that the Community of Practice should work on making a design system. However, there was not enough shared knowledge on how to properly build a design system from the ground up and the project came to a halt for a few months. The project was revived in 2021.
Origin of Project, 2020
- The Hack for LA Website Project ran into a roadblock where they needed to find a way to componentize the website for developers to work faster
- Project contributors came to the realization that it is known as a Design System
- After conversations with the HfLA stakeholder around what needed to be made in order to componentize the HfLA website, the stakeholder made the requirement that all projects at HfLA should have a design system
- The first attempt at implementing a design system was to ask individual projects to take on the task of making their own design systems, but it was found the results were very inconsistent
- The decision was then made that the Community of Practice should work on making a design system
- However, there was not enough shared knowledge on how to properly build a design system from the ground up and the project came to a halt for a few months
Project Revival, May 2021
- UI/UX lead decided documentation and notes were needed to guide people on the basics of what a design system is, how it functions, and how it’s built
- For the revival of the Design System project, the main project stakeholder wanted a design system built out for all projects that could just be pulled from as needed. This is similar to the stakeholder need in Stage 1A, however there was more pushback on this need at this point since it was recognized building a design system from scratch required a high amount of research, documentation, and collaboration.
Project stalled due to low team counts and focus on other projects
Universal Design System, August 2021
UI/UX lead looked to move to research design systems and wanted everyone on the team to start with a basic understanding of how a design system was constructed. In this phase, the objectives were to understand how some established design systems worked, and then use that knowledge to build out examples of various pieces of a design system
The following was done to build understanding of the workings of a design system and how to create them:
Began to draft the different pieces of a standard design system
- Over a period of 6-8 weeks, the team went section by section and created the pieces of a standard design system based on our research of established design systems. We built out the following sections so that volunteers from other projects will be able to follow its example when they work on their own design systems and to include this information in the Design Systems Guide:
Colors
-
Rationale for choosing MVP option
-
Had usage examples
-
Included design tokens
-
Included functional colors
-
100/200/300 number values for multiples color variants
Typography
- Rationale for choosing MVP option
There is one preferred option (Draft V3) with typography displayed horizontally this was voted as most preferred by the team because:
- Easier to understand at a glance
- Breakpoints are easily sorted
- Headings, Body, and other categories are separated
- Easy comparison of different sizes in different viewpoints (i.e. desktop vs. mobile size)
Icons, Grids, Spacing
- Rationale for choosing MVP option
Drafts of Grids were chosen because:
- Grid display was clean
- Included descriptions/grid info on the side
- Uses device mockups to display grid (easier for visualization) Icons example was chosen because:
- It followed established design system standards to make a template
- Simple categorization of icons as either filled vs. outlined (HfLA only needs simple categorization) Spacing example was chosen because:
- The root size in most websites is 16px, which is what this spacing chart follows
- Followed established design system standards
- Elements are kept to multiples of 2, 4, 8, or 16
- Rationale for choosing MVP option
- Rationale for choosing MVP option After each section was created, the UI/UX team would vote for and receive feedback from stakeholders on the work they had done to determine which examples could potentially be included in the guide
It should be noted that the work done in this stage (1c) was centered around creating an advanced guide, not an actual design system to be used across HfLA
Figma Checklist, Dec 2021
The research and brainstorming for the following section can be found the the projects FigJam file under the “Design System Checklist Research & Brainstorming” section
Began working to get an understanding of what design systems are like across the whole org Needed to determine the “definition of done” for each DS element
- This requirement came about because of the realization that different HfLA project’s definitions of a complete design system and the parts that made up a design system could vary wildly
- We needed to develop a unifying “definition of done” so we could have a baseline to evaluate each project and determine the state of each design system across HfLA To determine the “definition of done” the team researched different design systems
- How different design systems determine when an element is done
- What is common to include across different design systems
- Team brainstormed checklists based off research conducted around what defined “done” to apply knowledge to HfLA design systems
The research and brainstorming for the following section can be found the the projects FigJam file under the “Design System Foundations Research & Brainstorming”, “Figma Audit Insights”, and “Wiki Insights” section
During the research and brainstorming for the checklist, the team came to the realization that since many projects at HfLA were at different stages and had different baseline metrics of “done” there needed to be better unified guidance on documentation of decisions as well as guidance on how to create the foundations of a design system.
-
Since each HfLA project was supposed to have a wiki that would aid in documentation for project onboarding/offboardiing, roles, work done, project history, etc. Work for improving documentation was centered around project wikis
-
The design systems team began with an audit and developed guidelines on what each successful Wiki should have:
- Project Definition/Context
- History
- Glossary
- Objectives of the project
- Onboarding
- Offboarding
- Team info (meetings, agendas, etc)
- Guide for specific roles
- Resources/Links
Knowing the state of the wikis was important because it allowed a report to go back to HfLA leaders so they could implement changes on how project wikis were being built/maintained. Enabling projects to have more detailed and uniform wiki layouts would help to ensure that the Design System foundations detailed in the next step would be successful since part of starting off a successful design system was an understanding of the project, team, and project guidelines
- The team then developed a list of requirements that each design system should have in order to be built up correctly:
- Project set up
- Figma Cover image status
- Indications where to start
- Table of Contents/Menu
- How the Figma File was organized
- Results of Figma Audit
Foundations Work (Ongoing as of 01/2022)
We are working on the Figma Foundations template based on the Figma and Wiki insights. View presentation here
Here are the screen shots from the final slides.
Qiqi Zheng, Sept 2021
HfLA React projects component audit
Current Hack for LA React projects use UI component libraries, such as Material-UI and Semantic-UI, to build their in-house components. With our research, we have no need to create a full-fledged UI component library. We plan to document our Design System with tools like Storybook with a handful of simple components.
Our next steps in making the design system MVP is to finalize tech stack and explore various documentation tools with one in-house button component.
- What would be the starter components for the design system repo?
- What components do the projects have?
- Should we reinvent the wheel?
- What is our next step in making a design system MVP?
Documentation Tools research
The documentation tools we researched use different methods to render the documentation:
- Fractal, Pattern Lab, Cupper use templating engine.
- Storybook, Styleguidist, Docusaurus and Cupper use md and/or mdx.
- Storybook and Styleguidist both support TypeScript and PropType.
- Bit have own ecosystem and use their cli.
All of the documentation tools have out of the box demo setting which provides the project base templates. All documentation are straightforward and easy to understand. All documentation tools are good for documenting source code and visual representation of the components. Depending on the project's needs, they may choose any of the documentation tools.
Styleguidist is the fastest to setup and integrate with the existing project.
Dev team is done with all research. User research findings and conclusion determine whether dev team is necessary for design systems project.
Background
With lack of any central and shared information across the organization, it became clear that research should become a strong pillar of support to inform the design team.
A crucial part of the primary research was creating a literature review to build the base knowledge of the team about the design system. We researched why other organizations and companies needed a design system, what generally goes into a design system, and which roles will be actively involved with it. This led us to think about the definition of the design system.
We quickly learned that each organization and company follow a slightly different definition of a design system. After analyzing these findings for the purpose of using the same terminology we adopted the design system definition of Alla Kholmatova (author of “Design Systems- new practical guide to creating effective design languages for digital products”) for this project. She defines design systems as “a set of connected patterns and shared practices, coherently organized to serve the purposes of a digital product”. We have chosen this because this definition fits the unique nature of Hack for LA more where there is a high turnover of volunteers, and thus the standardization of governance, handover processes, onboarding and offboarding processes are crucial for institutional knowledge retainment.
Based on our findings we concluded that all in all design systems include not only style guides, component libraries, and pattern libraries, but more importantly guides and governance documentations.
Due to the very unique nature of hfLA, we wanted to make sure that the design system is based on the needs of the volunteers. Documentation and templates were a big portion of the projects in hfla. In order to learn about the documentations of the organization we had to do audits of figma files and as well wiki pages. Currently, the Wikis are the single source of truth for the HfLA projects that include all the information on the project background, work processes, work methodologies, and future project steps.
For some more information, here are some of the key resources that we used in the discovery phase to develop our knowledge of design systems.
Problem statement/ knowledge board
A crucial part for our initial research we gathered insights from all the team members in order to get a better understanding of the project. We analyzed this document in order to discover the key themes that were brought up in the conversations. Here you can read the initial problem statement.
Following the conversations about the problem statement, in order to better understand the scope of the project, and the data on hand we created a knowledge board to narrow down the topics we want to discover the research objectives. We also explored the questions that we have going into the research and what we want to gain from it.
Research objectives and roadmap
Based on the original problem statement the team wrote the research objective for this project. Initial research objective is:
- What is the state of the current design and development process in your projects?
- How is the interaction between designers, developers, and PMs?
- Which projects will benefit from a design system guide?
- What are the insufficiencies in the current design and development processes?
- Will the design system facilitate the onboarding process of volunteers?
- How can the design system be implemented for different projects (in progress and new)?
- What are users' pain points for users that are on the projects as well as new joiners?
As we operate in an agile environment we were expecting to edit these objectives as we develop the research and get more data along the way.
Research map is a step by step outline of the whole research process. It includes detailed information about the process of research and what will be coming next in the process. All operational and organizational details of each step have been included in the research roadmap. There are also additional educational resources included for future recruits.
Stakeholder interview insights
In order to fully understand the stakeholders' expectations and perspective on this project, we conducted an interview with her early in the discovery phase. The questions were designed to:
- Identify business Goals and expectations.
- Understand the background of the project and its constraints.
- Identify the pain points.
- Discover the best approach to implement the design system
- Explore the possible effect of the design system on the team onboarding.
- Identify the types of projects in which the design system could be beneficial
Following the interview the team came together to extract themes, patterns and interesting finds from the interview. After a session of affinity sorting all the findings were organized in multiple categories and the analysis was delivered to the product manager in a form of presentation.
One interesting theme that emerged from this interview was the lack of documentation which was causing an institutional memory loss with each cycle of active volunteers. The team revisited the research objectives and problem statement. Based on the information gathered in the discovery phase we revisited the problem statement with an open coding activity. The idea behind this exercise was to gain clarity on the initial problem statement and research objectives. This helped the UX research team to entangle the organizational and user needs from the research objectives.
The following insights were extracted:
- Volunteer staff: generally, there is a high turnover of volunteers throughout the timeline of the projects. It is assumed that most volunteers join while looking for a job, which in turn also means that volunteers are likely to offboard suddenly once they have found the required job. A second assumption is that most volunteers join HfLA to gain experience, which would mean that a high proportion of volunteers are novices in their regarding roles.
- Volunteer experience: there seems to be an inconsistency between project teams and programs in terms of collaboration processes, workflows, and project onboarding activities. It appears that there are no common governance rules on locations or points of contact for volunteers to turn to in order to receive documentation, guidance, or mentoring.
Thus, the research team gathered that it is of great importance to home in on sharing practices and its current challenges. Subsequently, the team decided to examine the current state of project onboarding workflows while uncovering previous project onboarding successes, challenges, and volunteer experiences.These two elements are intertwined with the question what does HfLA inherently need in order to effectively design and build products.
Updated research objectives:
- How is the interaction between designers, developers, and PMs, both within their project teams and across the HfLA organization?
- What are the current design and development practices of each project team, and what role does documentation play in them?
- Would a design system framework facilitate onboarding and retention of volunteers?
- How do project teams manage offboarding and institutional memory?
- What kind of projects will benefit from a design system framework?
- How can the design system be implemented for different projects (e.g., in progress and new)?
- What are users' pain points for users that are on the projects as well as new joiners?
Although the structure of the interviews for all the roles were similar, the questions were mostly focused on the workflow and performance of that specific role. Therefore the team prepared 3 separate documents for each of our target user roles. The objective of our user interviews was to be able to have a response to these questions by the end of the project.
- How is the interaction between designers, developers, and PMs, both within their project teams and across the HfLA organization?
- What are the current design and development practices of each project team, and what role does documentation play in them?
- Would a design system framework facilitate onboarding and retention of volunteers?
- How do project teams manage offboarding and institutional memory?
- What kind of projects will benefit from a design system framework?
- How can the design system framework be implemented for different projects (e.g., in progress and new)?
- What are pain points for users that are on the projects as well as new joiners?