Design System, Design Operations, Research Operations
Role
I started out as a UX intern for the company, then I was promoted to a DesignOps Manager, working on design and research operations together with our design system.
Results
We were able to create more streamlined workflows between design and development, have a more structured research process, and are rolling out the design system in increments.
NextPay is a business banking alternative that provides invoicing, disbursement, and payment solutions for Filipino MSMEs.
The startup focuses on making processes faster for these small business owners, removing the barriers imposed by corporate banking for them to manage their finances. Through its payment solutions, NextPay has enabled hundreds of small businesses in the country, processing over PHP 1B worth of payments throughout two years of operations.
As one of the earliest designers of the team, I was given a lot of freedom and flexibility with my projects and systems set in place. Back then, we could work with a simple pattern library and a few routine meetings. As we continued to grow, more gaps were uncovered, and we needed to set some more systems in place to help us out — daily design reviews and weekly scoping, to name a few. This gave us a better feedback loop within the team to improve our designs, learn more from each other, and take more ownership of our different projects and tasks.
As my internship came to an end, I was assigned to a project that exposed a few problems from a design-development perspective.
I had to work with our engineers to optimize our platform for mobile responsiveness. Since I had background knowledge in front-end development, I also took the initiative to look at the code used for the NextPay product. This showed me lots of inline styling and a lack of a simple design system. I was at a startup that was only starting to scale, so it made sense that our product was developed fast and quick instead of investing too much on systems. This sadly led to us to having to go through each page one-by-one editing lines of code, instead of fixing it from a single source of truth.
I brought this up with our team, and proposed to build our design system as my last intern project for NextPay.
I only had a month left in my internship when this project started, so I focused on setting style foundations and templates for the design team to use in the long run.
We introduced design tokens into our system, accompanied by specific use cases, to help both the designers and engineers with color usage. I worked together with the other designers to kickstart typography and iconography systems for us to use, while also laying down templates and guides for building the base components. With my internship ending, I left the company having set the foundations needed to build the design system for future designers and engineers to use.
Turns out, my time away from NextPay would only last a month and a half. I returned to work on the design system and design operations of the company hands-on.
I missed NextPay after a month! Goes to show how awesome our culture is 😉 (join us at https://nextpay.ph/careers). Anyway, I rejoined NextPay to focus on owning the design operations and the design system as we continued to scale up.
The team was scaling up, so it was time to put some systems into place. As a startup, we knew we needed to work on these since the start, but the fast-moving environment and limited manpower prevented us from working on these early. This caused these gaps to grow.
After analyzing the workflow, recalling my experience as a product designer, and talking to a few members of the team, we uncovered the following gaps in our operations and workflow:
No set process for using new patterns and styles
New features kept coming in, and we had no set process of adding new designs and patterns into our design system. This led to a lot of undocumented designs, inconsistent patterns, and a slower workflow — there were times we’d be making patterns that already existed in other parts of the product.
Lack of proper design-development coordination
As our velocity kept going faster for each sprint, proper design-development hand-offs were becoming difficult to maintain. The product kept growing too, so it was getting harder to organize designs to make it digestible and easy to understand for the developers. The lack of a design system further exacerbated this situation, slowing down shipment in some cases.
Lack of research within the design team
One of the biggest problems we encountered was the lack of user interaction for the designers. While we do have account managers who conduct customer development calls and get constant feedback from our users, we still wanted our designers to be more hands-on and directly involved with talking to users. This would give them additional context to design with, opportunities to test, and more opportunities to ideate solutions based on raw data from these conversations.
Designers need to focus on their craft, not operations. My task was to lift the operational tasks away from the designers.
Design Process Improvement Meetings
Every end of the sprint, we have our own design team retrospective meeting to identify what’s working, what isn’t, and what we can improve on from an operational and process standpoint. This has helped us identify and quickly solve different issues every sprint.
Capacity and Estimation
Another issue that was brought up within our team was the problem of underestimating projects, leading to an overload of stories and tasks in a sprint for the designer. To communicate load and project weights better, we worked on creating an estimation system (loosely based off Gitlab's Handbook) to help the product managers plan out sprints for the designers in a more realistic way, considering the load of research, design, reviews, testing, and revisions. This proved to be very useful, as the sprints that came after this implementation became more balanced and fit for the designers, with them being able to finish the tasks slotted in for the sprint.
Figma Organization Guide
We decided to create a system to keep the organization consistent for easy navigation for both designers and developers. Through this system, we were able to standardize frame naming and flow mapping to really provide as much context as we can with the product designs on Figma, making hand-offs easier to understand for our devs.
We also established a better research system to give designers independence and ownership of different research projects conducted for the product.
Research Guide
We created a more documented and systematic process for initiating, conducting, and concluding research projects within the company. Prior to this, feedback and discoveries were free-flowing — we had constant calls that allowed the account managers and product managers to process insights from their interviewees. This put the design team out of the picture, as mentioned earlier.
Some key points from our research guide:
We created a research plan template to standardize and guide the primary researcher of the project.
We also created a synthesis template to aid the primary researcher in documenting their findings.
We split the research guide into discovery flows and feedback loops — this allowed us to specify specific processes depending on what type of research project is being conducted.
These were important for us to do as it gave us a more structured system to work with, allowing us to initiate 2 new research projects involving customer research. The sudden growth in the research side also prompted the company to hire 2 UX research interns, further solidfiying the value of user research in our process.
Usability Testing
We also created a guide for conducting UTs. Prior to this, tests were conducted informally and with no proper synthesis, therefore causing us to lose revisions and insights in translation. With the guide, our team was able to standardize a workflow for conducting UTs — from initiating the project to creating design recommendations based on the synthesis.
Some key points from our UT plan:
Given the agile environment, it was difficult to create an extensive UT plan that ran through multiple weeks. To address this, we introduced the RITE method found in Gitlab’s handbook. This allowed us to do rapid tests on our prototypes, iterate quickly, re-test, and hand off to developers.
Similar to the research guide, we also made a workflow document to outline the process, provide templates, and give additional resources that could be used to write an extensive research plan.
Research Repository
To have proper documentation for every project done on the research end, I built a research repository using Notion. This kept things organized, easy to find, and provided us with a single source of truth for customer feedback and insights. I would say building this repository was the most fun part of my work on our research operations — creating all the Notion templates, linked databases, and filtered tables was tedious, but the end result was amazing and honestly, fun to use. #NoCode for the win!
We also implemented a few things to help us govern the design system better:
Creating a component drop-off system
As part of our governance plan for the design system, we created a drop-off system for our designers to use. We streamlined the process by creating a #support-designsystem channel on Slack for requests, bug fixes, and other related concerns with the design system. Through an integration with Shortcut, we’re able to easily create tickets for creating new components, followed by a template made on Figma for dropping off components. We also made a set criteria for assessing whether a pattern should be turned into a component or not.
Implementing the design system
Our implementation plan follows Brad Frost’s atomic design — we’re starting off with styles, then the base components like buttons and form fields, then moving onto bigger patterns like modals and navigation bars. This also helps our developers create a system that ties the different components together, making it easier to implement changes in the future should they be needed.
The design system is a living product — we’ve plotted out a quarterly roadmap for the next year to guide the direction of the system.
I’ll be working hand-in-hand with our designers and developers to build the design system and implement it incrementally across the whole product. A design system is every designer’s dream, and seeing it come to life is definitely a big milestone for us as an entire design team. This work is a whole team effort, and I’m glad to be spearheading this initiative.
Key Takeaways
I’ve worked on different tasks and projects throughout 2021 with NextPay, ranging from product work, design system management, to the establishing of our design and research operations. Here are some takeaways I’ve had from what I’ve learned this year:
Talk to people. Treat operations and the design system as another product you’re working on — do research, talk to your users, ideate solutions, then go from there. This helps you take a design thinking approach into building systems for your organization, starting with a problem instead of a solution.
Always test your work. Operational work is similar to creating a service for your organization — you want to test it, iterate, test again, and iterate. More often than not, you won’t get your solution right the first time, so it’s important to keep trying it out with your users in your team, to see if what you built works for them and matches their current workflow and behavior. You want to make processes as easy as possible for your team.
Do what’s most usable, not what looks flashy. Figma variants look sexy to make, but ask yourself: “Is this really what my designers need? Or am I just overloading them with these awesome Figma features?” Remember, you’re not building something to prove you know how to use the tool. You’re building it to make the lives of your teammates easier. Create something usable, not flashy.
Special thanks to Aldrich, Janyl, Nikki, Amera, Patrick, Juancho, Jake, and Mike for all the support and help with building our team’s operations.
