IT-блоги • Brief Considerations on Design Topics: 16.

Brief Considerations on Design Topics: 16. Desirability Studies, Usability Testing and Leveraging Applicable Research Methods

Research is always an interesting topic to tackle in an article, since there are various types and methods associated with it, all of which merit their own focus and attention. However in this series of brief considerations on Design topics, I’m going to specifically address a situation that occurred with me and my team in the past, and how leveraging Desirability studies and Usability testing, permitted us to quickly change the direction of a product solution, and be further aligned with what our original intent actually was. It’s also a demonstration of the importance of Research, and the ability to be flexible, while also being substantial and succinct in what is both being showcased and also what eventually ends up being iterated upon.

Context and setting the Stage. Every problem is a unique one. Even if at times one can draw close parallels between problem statements, chances are demographics, the economy, politics, innovation & technology have had an impact on habits and expectations of users, which means by the time a Product Design team tackles a problem, you always have to understand the context of what you’re about to solve for. Another aspect to consider: not every solution that is out there on the market actually matches what users need, and how their habits (and expectations) have evolved. In the example I’m about to describe, this is exactly what happened, unmet expectations and needs from users that were never truly addressed. In order to summarize the context: a rather complex application (SaaS) built by a product team had been delivered to market a while back, and it failed to ignite the response the Business group aspired to (in terms of adoption, new subscriptions and client engagement), therefore forcing the solution to be repurposed in a different direction. However the gap that had been identified and analyzed in the market alongside the opportunity to satisfy users/clients still persisted, and that continued to be at the core of that problem all along. This pain point (and opportunity) was still being documented through Customer Support engagements, which were also a source of data for the reinforcement of the need to deliver a pertinent solution. The problem statement was therefore revitalized, thanks to multiple data entry points (Research aggregation essentially), which included Market Research/Benchmarking, Customer Support Data, Data Analytics, and also Voice of the Customer Engagements. All of this research pointed out to the fact that an opportunity to revisit that solution was imperative and a need for a lean Design process was also essential.

Understanding the Problem, Design Sprints, Rapid Iterations. Hopefully by now it comes as no surprise that understanding a problem thoroughly is essential when you set out to solve it. And that walks hand in hand with understanding the Characters who are involved in that ecosystem, what their roles are, and how they influence both utilization journeys (or just journeys in general) and expected outcomes. In our case, the goal was to understand the problem our clients were having, which we did thanks to Interviews, Customer Engagement Sessions, and Metrics (which could have also been further crystalized by Surveys and Questionnaires). Eventually the synthesis of all this feedback, manifested itself in the desire to have a self service solution which allowed clients to have autonomy and the ability to address their own needs (while retaining customer service ability if needed). And this statement married the intention of the Business and Product Stakeholders, which envisioned this direction as a means to scale product efficiency and client onboarding (and retention). In order to tackle this problem I partnered with a small but resourceful team, with the purpose of going through a deconstructed Design Sprint (meaning few hours every week, as opposed to a lot of hours in a single week), which manifested itself in a series of Workshops and Ideation sessions. All these sessions had the specific purpose of parsing through the problem statement, users needs & journeys, legacy product and quickly develop a new solution that addressed those user pain points and simultaneously the business objectives. We quickly ideated and subsequently started prototyping based on a pre-existing Design system with enough components which allowed us to assembled these first outputs rather quickly.

Desirability Studies, Capturing Feedback and Changing Direction. One of the things that further crystalized while going through this process, is the need for convergence from a team perspective (I had already witnessed this before both in successful Product Design endeavors, and others that were quite more challenging). While I had to momentarily remove myself from the project to focus on other topics, I realized that the project tilted and went in a slightly different direction that I didn’t necessarily fully endorse, and that people on the team were somewhat mum about. This is something that should never happen. Teams and team members need to be able to trust each other, in order to be able to question what is being made, and also volunteer any type of questions they feel needs to be answered and addressed. Even with this hiccup, we quickly decided to perform Desirability Studies with Clients, and document what their reaction to the early prototype was. And for the most part, it turns out the results of the studies, alongside their feedback, did not support what that initial prototype/solution was illustrating. While they applauded the business intention and clearly understood how the intended solution married their product journeys and habits, they still felt that the prototype failed to address their needs. All this data retrieved from these studies, alongside the Benchmarking studies we had performed, alongside additional product requirements which were ultimately reinforced, further informed my decision to quickly pivot. This pivot manifested itself in a few strategic workshops, followed by the delivery a slightly different solution (and prototype) one that aimed to reflect the consumed data points, users needs, business requirements (and constraints), while still adhering to the Organization’s product design principles. All of this of course with the additional constraint pertaining to development cycles and go to market strategies and timelines, all of which were encroaching rather quickly.

More Studies, Usability Testing and Moving Forward. The goal for a Lean Design Process is ultimately to build, test, and iterate quickly and effectively (which is one of the venues where Design Systems and Shared Libraries help tremendously). Upon completing the new refined solution and prototype my goal and that of my team, was to quickly test it, and get both qualitative and quantitative data which informed of the robustness (or otherwise) of what we were proposing. And this time around we pierced through the needs of what users had informed us. We performed Desirability studies and Usability Testing, focusing on the main 5 topics from that method: Learnability, Satisfaction, Efficiency, Memorability and Errors. We tested across a variety of users, including clients, all of which provided relevant data which informed how our proposed solution was working and where we could further iterate in order to more effectively solve the problem. These tests were performed according to a process which included: scope of what we were testing, building scripts for the sessions which enabled us to consistently document the output from session to session, surveys in order to capture data quantitatively and auditing and synthesizing all the feedback that was captured. All this data enabled us to further iterate, but also successfully keep moving forward to next stage of the process.

Scope and Flexibility. Our scope essentially never truly changed from when we started this project all the way through the discoverability that came from it. We mapped out the types of Research we intended to do, and we were always aware of time and resources constraints (and go to market expectations). There’s at times the temptation to do more or less when it comes to feature development depending on what is uncovered from the Design process, and while teams need to be Agile, they also have to keep in mind that there are aspects to a solution that are imperative to be addressed (the DNA of the problem itself). You can’t sabotage a process just because you don’t like what the research is informing. In the particular example I provided, the convergence of team members, research methods, artifacts delivered, all contributed to the quick pivot that had to be done, but even with that event, we stayed on course with our timeline, and managed to document user stories, and commence the development cycle according to the timeline we had established at the commencement of the project.

Hopefully this article provides some interesting fodder for discussion when it comes to Research endeavors, further reinforcing the need to test, synthesize and iterate frequently. Only by continuously going through this process, can we attain results and solutions that are accurate representations of what users want to use, as opposed to projections and interpretations from biased sources, which can at times tilt solutions in a certain direction.

Samuel Beckett wrote:
“Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better.”

Brief Considerations on Design Topics: 16. was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.