I didn’t choose Design Ops, it chose me!
In 2019, I received an invitation from Invision to join a select group of Design Ops leaders in a small pod, as a token of appreciation for organising a DLF Sponsored event in Melbourne. Small fish in a big pong, I sat there quietly listening to shifters and shakers from design ops leadership for Netflix, Nike, LinkedIn, Apple and more. I was inspired. I didn’t know when or if I will ever use the insights I had gathered but one thing I did know- I wanted to invest in operations.
Since then I have hired and worked with dedicated ops, as well as formed communities of designers and researchers around ops.
I did whatever I can to make designers happier, products greater and problems smaller.
Check out the examples below that highlight my experience leading design and research ops,
Design and Research Operations
State of Design
Design and Research Operations
A few years in a row, I have been using the State of Design survey to kick start our Design Operations activities.
It’s a custom made longitudinal survey with approx. 30 Likert scale questions, investigating the state of the design team, its practices, and its work- using different inputs that come out of Design Maturity reports and Design Ops ‘menus’. This form of rapid discovery sheds light on the meatiest problems to solve and helps create greater focus for team members, mostly for those who like to solve ALL of the things.
At Seer, I used the help of the dedicated Design Ops Coordinator (DOC) to gather and synthesise the survey results, as well as lead a workshop with the broader design team. Our goals was to democratise design and research operations. In order to achieve this, we formed small groups to tackle the highly voted-on problems within a timeframe of 3-6 months. The process included discovery, iteration, comms, and measuring success.
The DOC focused on the number one issue, while also playing a critical role in creating guides for the other members and checking in frequently on progress.
To achieve greater accountability, we set up a Design Objective <Elevate design practice, work and people> and worked with the groups to define relevant KRs.
Some of the outputs included best practices for onboarding, skills assessment, design reviews and design briefs.
Additionally, we were in the process of establishing Design Principles and a "Design All Hands" ritual until very recently (March 2023).
Seer Medical
Design Systems
Design and Research Operations
During my tenure at A Cloud Guru, I formed a systems team with three members. One designer and two engineers, all reporting to design. The significance for doing so was the rapid growth of A Cloud Guru’s offering that had resulted in duplicated code bases (e.g- four versions of the header), slow front end practices and overall inconsistencies in the experience.
The business strategy was also growing to the U.S public sector (government) which required a high degree of WCAG accessibility compliance (vpat) and made a great case to invest in systems.
Being an early stage team, we focused on building awareness and advocacy towards Cumulus as well as setting OKRs to tie our work to the overarching business goals. We did foundational work like establishing tokens, setting up the Figma environment and designing a public page (Image attached)
We also and set up a front end guild to promote good practices and contribution to the systems code base.
One year in, ACG was acquired by a major US-based competitor with an already mature design system in place. In the aftermath of the acquisition, I was tasked with leading both system teams and facilitating the process of merging them into one cohesive unit.
————
A Cloud Guru
SEEK
During my tenure at SEEK, I played a pivotal role in establishing a systems team by creating a dedicated, full-time designer headcount for Braid. Prior to this, design choices for the system had been mostly made by developers as they struggled to get traction and focus from design. As the Braid team began to take shape, our focus was on moving swiftly, measuring saturation across teams, and establishing OKRs.
At the time, SEEK's UX team had a VD/UX split, which meant that the system was largely viewed as a "VD thing." My objective was to promote the system more widely and break down any barriers to adoption. To achieve this, I invited UX designers to meetings where the system was discussed, rewarded designers that embraced the ‘system first’ mindset and had worked with the design leadership team to think of ways to upskill in that area.
It was obvious to most that the experience was fragmented between the product and brand experiences. To address this, I made concerted efforts to break down silos and bring the right individuals together to collaborate on a cohesive plan. The design vision work was framed as collaborative effort between the two departments, seeking to form ONE source of truth for design at SEEK.
Revamping Product & Design Reviews
(AKA 30-60-90%)
Design and Research Operations
Problems to solve:
Designers, leaders and PMs were lacking visibility over design work
Design researchers were lacking visibility over research work that isn’t owned by them
Both groups were lacking opportunities to give feedback and share their knowledge EARLY
Discovery was narrow and at times, absent
Design reviews were lacking focus and relevancy
Under my leadership, a cross functional working group was formed and conducted the following activities below:
Forming three new rituals that were spread across the design process, giving more visibility for both design research and product management.
Creating templates to assist with discovery, research planning and brief writing
Creating templates for the review presenters and participants, allowing for better context setting and better discussions.
Impact:
An increase in participation and engagement during our new team meetings
An increase in quality of research plans! (better variety of tools used and better research questions!)
An increase in consistency of experiences
A Cloud Guru
Research Ops
Design and Research Operations
The research process at A Cloud Guru (ACG) was in a state of chaos, with no established guidelines or standardisation.
Every team was conducting research independently, leading to a lack of consistency in tools, recruitment methods, and incentives. There was no centralisation of research insights, which led to the loss of valuable data every time a member left the team.
Enter: Research Ops!
We set our eyes on the prize -unblocking research and achieving greater consistencies for an improved participant experience. Some of the activities we focused on were:
1. We audited all tools that were used and created a recommended short list.
2. We aligned the team on incentive types and the request process. We budgeted in advance based on predictions.
3. We created a Research Tracker (Airtable) <Image attached>
4. We created an Insights Repository (Airtable)
5. We ensured compliance by obtaining consent from participants and protecting sensitive data.
6. We created a Research Brief template for better alignment on process
Some of the activities we had planed on focussing on before ACG was acquired were- streamlining recruitment for ‘Continues Discovery’, Retiring Survey Monkey for Qaultrics and Design Sprints training.
A Cloud Guru
Design QA & Managing Experience Debt
Design and Research Operations
Experience Debt accumulates with each sprint as product teams deviate from an ideal solution in order to meet deadlines and other constraints. Similar to Tech Debt, overtime this leads to a significant deterioration of the product experience as more features are added without overall cohesion and pain points remain unaddressed.
During my time at ACG, I tried to solve this issue. let me tell you how!
ACG’s The engineering team had introduced new development cycles together with a new concept of a CANI Sprint (Continuous & Never-ending Improvement). Every 6 weeks, product teams stop the feature factory to reflect, review, plan ahead and clean up tech debt. I used their framework to introduce Experience Debt and followed up with the activities below:
1. We defined the term Design QA and what a good process looks like.
2. We trialed Design QA with ONE team that had logged design issues and prioritised them.
3. We waited until the next CANI sprint for engineers to address these issues in the backlog of that particular team.
4. We shared learnings with the broader design and engineering community
5. We engaged in a discussion with senior leadership and successfully secured a commitment to allocate a minimum of 30% of the CANI time for investing in Experience Debt
6. We branded it Polish Week and scaled to other teams
7. We started seeing Experience Debt reducing 📉