Table of contents
est 10 min read
Introduction Usability Testing is a pillar part of my processes, it has become so obvious for me that I rarely use the word in dialogs or display it on my portfolio either CV. I have been doing regularly, transparently, since 2014 with tweaks in the methods I use.
One significant development was when I began working on internal products such as a design system. I integrated internal user testing with my coworkers into my workflow. This not only exposed me to new approaches but also introduced new challenges, ultimately making me a more adept collaborator and a staff designer.
Internal usability testing With my background and experience in UX, I've conducted various types of usability testing in the past, including eye-tracking, moderated and unmoderated sessions, remote and in-person tests, card sorting, observation, and session recordings. Working with teams of different sizes and diverse business goals, I found that usability testing wasn't approached the same way everywhere I was working.
Sometimes, I was the sole member responsible for conducting tests, with limited time available. Other times, I worked in teams with dedicated UX researchers who provided me with data to back my designs. While every product led company recognises the importance of usability testing, my diverse experiences have shown me that there's rarely a one-size-fits-all process for it. From this experiences usability testing was not an area that I actively pursue to develop myself and have had limited experience.
Although usability testing came back into my workflow and helped me a lot in developing one of the design system I was working on. The adoption of this particular design systems was low, especially the documentation part, therefore I conducted internal user testing to find out why and where is the problem.
Through this process, I gained insights into our organization product development efforts. By engaging with various stakeholders, I obtained diverse perspectives. Internal usability testing allowed me to understand how different teams incorporate the design system into their workflows. Moreover, it shed light on the entry points to our documentation pages and provided valuable insights through session recordings, revealing how stakeholders navigate and utilize the documentation: where they click, how they search (search bar or ctr+f), their different understanding of some wording etc.
The primary objective was to understand why adoption of the design system was low. However, the process gave me valuable insights beyond that. It revealed how different teams collaborate based on their unique workflows and needs, offering a glimpse into their day-to-day processes with code and design available to them.
These insights guided my team in revamping our design system structure to better align with these needs. One specific outcome was the decision to split our documentation into separate sections for developers and designers in our source of truth. Additionally, we implemented component changelogs for both areas, providing transparency and clarity with a design changelog and a developer changelog. We created developers and designers internal personas, that helped us deliver design system work according to those internal personas user journeys. It added an extra layer that we never thought it will be valuable when we started. Because we though every developer and designer in our organisation will work the same. Wrong.
After realizing the value of internal user testing in supporting our product teams to be more effective, we began using it more frequently in design system team. However, instead of conducting it after delivering a feature, we adjusted our approach. We now prioritized usability testing before starting work on each feature or project in our backlog.
Framework My most common method that I used to conduct usability testing internally was “The Interview Snapshot”
The principles of product development in the organisation I was part of back then were based on Teresa Torres book: Continuous Discovery Habits. The book advocates for integrating ongoing user research and testing throughout the product development process. And provides some methods how to do that. These methods were used by our product teams to discover and deliver for our external users, I applied the same methods but internally.
The book recommends teams use three different artifacts to keep track of what they are learning from their customer interviews: