Abbott work overview
Given all my projects are under NDA with Abbott, I will share high-level methods I've used during all my projects at Abbott rather than technical details.
Role
Sr. Design System Lead
Tools
Figma
Sketch, Abstract, InVision, InVision DSM
Jira, Confluence, Teams, Microsoft 365
UsabilityHub, Miro, FigJam
Sketch, Abstract, InVision, InVision DSM
Jira, Confluence, Teams, Microsoft 365
UsabilityHub, Miro, FigJam
High level process
Requirements > Research > Design exploration > Review > Hand off and delivery
Requirement gathering
Methods I've used during requirements gathering or validation are listed in the following paragraphs.
1. Design audit
Collected and compared all existing design patterns for the established design system and looked for areas that needed design improvements. Usually these are around inconsistency across system patterns (e.g. Vertical and horizontal Cards are using inconsistent vertical gutter spacing for no functional reason; states of primary and non-primary buttons are referring to colors in an inconsistent way with their visual priority level etc.).
2. Content audit
Mapping existing content around how to use components in design and implementation, then analyzed effectiveness of each piece of content. Based on the analysis, proposed and executed ways to improve content performance (e.g. how easy it is to find a certain piece of documentation on how to design with a Button component).
✅ Related projects that I worked on showed 40% increase in design system user satisfaction.
3. Survey
I established a design system feedback survey to collect both qualitative and quantitative comments from stakeholders across the company spreading across engineer, business, product, and design. All survey questions were carefully crafted in a way that ambiguity was minimized and non-leading.
4. Day-to-day observation
We have regular meetings where users of the design system would come together to request contributions to the design system. I observed how users interact with our team or listen to their use cases for components to spot areas of improvements and innovation for the entire design system team.
5. Design thinking & workshops
Sometimes we had a clear problem to solve or we knew the general problematic areas. To bring clarity on execution strategies and align team members, we ran design thinking workshops to help flesh out the tangible requirements (e.g. How might we keep evolving the design system as a product? then our team would get together and use divergent and convergent thinking to generate actionable solutions).
Image of an analysis on survey to gauge areas of improvements for the design system.
Research
Once project requirements are tangible enough to be worked on, depends on the problem, I used a variety of research method to help me move forward.
1. User interviews
If users were involved on the problems that I was trying to solve, user interviewed would be conducted ahead of design explorations to understand how users think about the subject matter. This helped me understanding their existing workflow, attitude towards the subject, desires and potential requests that mattered to their relative personas. These info supported my design decision making when I moved onto the design exploration phase of the project.
An example of this would be interviewing developers before I design a new design system onboarding curriculum for the developer persona. The interview would be used because that is the best way to let research participants openly share existing workflows and what they like or don't.
2. Secondary research
When the requirements were specific like updating the design to offer more usability on a certain component. The research process may also involve secondary research. Typical things I did were:
👉 Reading design best practices articles on how to design a component (e.g. best practices for UX of CTA buttons in 2023).
👉 UI research online (e.g. look at nice visual design options for a Form on Dribbble or Awwwards).
👉 Learning about similar components on other popular design systems (e.g. look how Material 3 site is documenting design specs for a Switch)
👉 Reading design best practices articles on how to design a component (e.g. best practices for UX of CTA buttons in 2023).
👉 UI research online (e.g. look at nice visual design options for a Form on Dribbble or Awwwards).
👉 Learning about similar components on other popular design systems (e.g. look how Material 3 site is documenting design specs for a Switch)
Screenshot of a UI research board to see industry trends and potential art directions for our project.
Design exploration
1. Pen and paper sketch
I love pen and paper sketches for quickly generating ideas for both design and non-design project. I used it for user flow analysis, initial journey mapping, and low-fi wireframing for component designs.
I used this method especially at the early stage of the design phase, when I had some general ideas of how to tackle the project but not anything that worth more time commitment. This was quick to flesh out ideas and easy to throw away and pivot.
2. Rapid prototyping
I used rapid prototyping to quickly mockup solutions. Sometimes for complex components, I would intentionally keep prototypes mid-fi so that I can test and pivot quickly if one design did not work, e.g. I was designing complex search and filter components where the component properties needed a lot of test in logic, instead fully prototype all visual details, I would just use some squares placeholder text to test functionality, then once functions were solidified, I went back to add color and typography details.
3. Cognitive walkthrough to ensure UX
When designing, cognitive walkthrough were used together with rapid prototyping to make decisions on the best design options. Cognitive walkthrough is a method when you assume characteristics of a persona for your product and test out potential likes and hiccups in the design.
This was used mainly during design exploration when nothing was mature or ready enough to conduct usability testing. Later in project review stage, usability testing with real users would still be conducted to ensure we heard real users' feedback so that we were not "assuming" the best options.
4. UI design skills
Color theory, typesetting, graphic design skills were all used in design exploration when appropriate for the project. An example would be explore the best modular type scale to renew our typography spec for the design system.
Image of a pen and paper sketch for a new component.
Review
Once the design exploration was done, a design review would happen. Iterations would also happen based on the review feedback. Iterated versions would go through review again till the design can be signed off for development.
Some typical methods I used during design review were:
1. Presentation & design critiques
I did most design reviews by presenting and taking feedback along the way. This was the best for me to collect stakeholder feedback collectively and answer common questions. This worked well for reviewing items with internal team members or business stakeholders.
2. Usability testing
Usability tastings were also conducted when users of the design system or end-users for a design system supported product/website were involved. Both qualitive and quantitative data were collected to understand users attitude, feedback, and satisfaction on both high-level and specifics. The quantitative data also helped us create benchmarks when comparison of metrics was needed (e.g. # of errors when using the old vs. new Input component on a design file).
Hand off & implementation support
1. Design requirements grooming
In addition to initial scoped business requirements for the project, any design requirements that needed to be scoped would be grooming and reviewed during the hand off process.
✅ I closely collaborated with Business system analysts, Products, Business, and Developers to groom functional design requirements in Jira. My business stakeholder has openly shared that they consider my grooming and hand off support sessions effective in terms of offering clear guidance on what to do next for implementation.
2. Standard hand off template
I created a re-usable hand off template for all designers in the company to leverage. The file included dedicated pages to add links like Jira stories and existing research materials, wireflow, component level customization markup, and additional interactive design specs.
✅ The standard hand off template for Figma has received many positive feedback from both developers and designers. One developer commented that my hand off template has significantly reduced the hours needed for detailed design review and improved developer experience.
Image of a hand off design file with clear markups.
Implementation support
1. Asynchronous collaboration
We used a lot of agencies so many developers that I've worked with were offshore. To best accommodate for time zone differences, I openly adopted asynchronous collaboration and review methods for developers to comfortably ask me design follow-up questions or request design adjustments during coding.
I made sure to them that it was ok to leave me a message on MS Teams (our main direct message channel), email me, or @ me on the design file or Atlassian tools. When I had a preferred communication channel (e.g. all messages should come to me in Figma), I also made ensure the team clearly know how to reach me the best. This allowed product delivery to be seamless despite my team worked in complete opposite time zones.
2. Clear communication
When communicating in both writting and verbal, I made sure to speak according to the developer's language and keep converstaions open.
3. HTML/CSS/JS + React
During support phase of a project, I also used a lot of HTML/CSS/JS knowledge to reduce communication cost to developers. Being able to directly explain the design with technical terms like "CSS Variable" has made developers understand the design easier, which reduced unnecessary UI implementation errors that needed to be fixed either during design QA or post-release as bugs.
Additional skills
1. Storytelling
I polished my storytelling skills at Abbott as the lead for the design system. I often needed to push for design enhancements that were not what the business directly asked for but would be beneficial in the long term. These were times that I needed to explain technical and boring design decisions in a way that business stakeholders would not only see, but also understand the value of design.
2. Product strategy
As the lead, I also spearheaded design system strategy. Some were in collaboration with our design system Product Manager.
Strategy-related projects included:
👉 Defining design system metrics
👉 Defining design system roadmap
👉 Defining design system contribution standards
👉 Optimizing design processes surrounding the design system (e.g. setting up self-service guides on how to use certain tools or components)
👉 Defining design system metrics
👉 Defining design system roadmap
👉 Defining design system contribution standards
👉 Optimizing design processes surrounding the design system (e.g. setting up self-service guides on how to use certain tools or components)
