A UX Case Study
How to overcome working on a remote team, confirmation bias, and a 3-way deadlock of design strongholds
I was recently working to solve a UX design problem with several other designers on my team. The challenge was to make it easier and more intuitive for users to create a new group — seems straightforward enough. We needed to come up with a solution that was flexible enough to accomodate groups with just a single field as well as complex groups with a secondary level of configurations.
Each designer proposed an approach to solving the problem that made the most sense to them and each solution was unique and different. We were able to come to an agreement on a solution for a simple group, when there was only one field, but when coming up with a solution that was consistent and scalable, to accommodate more complex groups, we had differences of opinion.
Option A : One modal with two tabs — allow the user to configure group settings and then move on to the secondary set of configurations on the next tab.
Option B : Two modals that are linked — provide an optional link to navigate to a new modal for the secondary set of configurations.
Option C : One modal and one configuration page — only show the primary group settings in the modal and force the user to save the group before configuring the secondary level settings on a different page.
Each approach had pros and cons, leaving us feeling like there was not one solution that was obviously better than the other. In Option A & B, the UI leads the user to believe that it is recommended to complete the secondary set of configurations at the same time as creating the group — which is not a typical workflow for most users. Option C simplifies the process of creating a group, but risks the discoverability of the secondary set of configurations that are not straightforward to find.
As a team, we discussed the three proposed solutions at length, but could not come to an agreement to move forward. With the existing stalemate, we decided to track down a product expert, with vast experience working with real customers, who could walk us through typical workflows and give us feedback on our proposed solutions.
After finishing the training session with the product expert, I left the meeting feeling like my solution was the obvious choice for how to move forward and that all the other designers would agree when we regrouped. Little did I know, the other two designers left the same meeting feeling exactly how I felt.
Each one of us felt completely validated that our design solution was clearly the strongest. We chose to hear what we wanted to hear. We wanted validation for our own design solutions and we found it — each of us — in the same training session.
By this point in time it was becoming increasingly difficult to explain to executives why we were still working on this project. The project was starting to cost the business more than the solution was worth and we had to get serious about making a decision.
After realizing that we all fell victim to confirmation bias, we decided to try something new and agreed to find the simplest solution for an initial implementation, with the understanding that we could spend time improving it later, after collecting some customer feedback.
Ideally we would have collected feedback before implementing, but as anyone who has worked in software knows, ideal can sometimes be far from reach.
In order to discover and agree on the simplest solution, we would still need to reconsider our designs and decide which one is actually the simplest. As a fully remote team, spread across three countries and timezones, we lose a lot of time working separately, posting results, and waiting for feedback. In an effort to maximize our time, we decided to organize a remote workshoping session that consisted of a video call, a screenshare, and the ability to work in the same file at the same time, with Figma.
The workshop was great because in just over an hour, we were able to come to an agreement on a single solution we all supported. In addition to the efficiency of real-time communications, we were able to narrow down our choices by identifying the usability and technical problems with each solution.
We found that options A & B both presented significant technical and usability challenges when dealing with saving the object and handling potential error and validation states between two different tabs.
Option C faced significant challenges because with this direction we would need to make additional changes to another component in the application; increasing the scope of the project and disqualifying this solution as being the most simple.
Our final outcome was a variation of previous designs — we decided to add a link to the group creation confirmation toast message that would give the user the option to configure the secondary set of group configurations. This new solution proved to be the most straight-forward option and also solved our biggest concern:
How do we make sure the user is able to discover the secondary level of group configurations, while being careful to not encourage the user to configure them during the group creation process.
This project was one of the most challenging for my team. For most projects, we are able to agree on solutions fairly quickly. However, this project tested the strength of our team and I am proud to say that we were able to work together to move past our confirmation biases and come to an agreement, but most importantly what I learned is that there is no such thing as a perfect solution. As designers we need to keep our biases in check and always weigh the pros and cons of our designs. Every design decision is a hypothesis that will be tested by users, iterated on, and improved over time.
