Ben Avatar

Platform

Android & iOS

Project Type

Solo Designer

My Role

UX Designer

Tools

Figma

Timeline

May 2024 – Now

How I Use Design to Solve Wicked Problems

Intro

One skill that I focused on a lot while working for Usana was learning how to have conversations about problems in a way that made people curious and want to dive into them together to solve them.

It’s REALLY hard.

I got burnt out a lot, and I’m actually burnt out with it right now which is how this post started. But I believe deeply in collaboration, and not as a buzz-word. I believe that when each person brings their expertise, passion, and their niche of knowledge and skills, we can genuinely build better things. Let the designers design, let the writers write, the developers develop, and any other role you can think of. Lean in to their expertise and include them in the conversations. Let people know that you want them to be included in the conversations and that their opinions and ideas are valuable.

Sometimes I’m terrible at this.

Other times I think I’m doing alright.

There was one project we worked on though that I think this ended up going incredibly well on and the results were pretty amazing.

The Problem

You see, Usana has traditionally made it very difficult for their users to get info about their commissions. I believe this was unintentional due to how many complicated rules we have across 24 different markets in the world. It’s a beastly problem. But I was determined to start making meaningful changes so that users don’t have to continue to manage the complexity of Usana’s systems! This is because I believe that any organization needs to take on the complexity of their systems rather than let others deal with that complexity.

LoFi and Exploration

It makes sense why Usana would do this since their compensation plan is incredibly complex, but it doesn’t make it okay to force users to take on that complexity. I had some great support from multiple people who either already knew that we needed to change this, or who quickly realized the value it would bring as I began to point out the huge gaps and confusion through sketches and questions. Here’s a reference of one of those sketches.

As we kept diving in, we continued to unravel the complexity and it kept getting deeper and more complex, which continued to prove the point that something needed to be done about this. It also continued to emphasize to me why something never had been done with it in the past.

I think it’s really cool that if someone or a group of people will put energy into asking a question or starting a conversation, that many others will begin to see and join in the cause for change.

Although it took a lot of conversations, follow up, and tons of question asking and design iterations, we started to land in a solid spot! People began to see that it actually was possible to do this and they really wanted to make it a better experience. It was exciting! Here’s a look at a bunch of the design options that I explored. I used them to help drive the conversation forward and call attention to the outstanding gaps we still needed to resolve.

I chose to use a more high fidelity design asset for this part of the project even though we were still in exploration because it felt like the level of fidelity we needed to have these conversations. I had enough of the components and styles built into our mobile design system that it was pretty easy to swap things out on the fly in a similar way to what I would be able to do with something messier like sketches. But having a higher fidelity asset to look at with stakeholders allowed us to start visualizing some of the deeper challenges and questions that needed to be addressed. I’m glad I chose this instead of sketches and it worked out really well.

As we kept exploring options together things started to make sense. Some things we knew we wanted to implement with the first launch of this new tool. Others we needed to explore more before implementing them in our apps. But, we knew that even just a few key pieces of the puzzle would be a vastly improved experience compared to the confusion that users have been forced to deal with up until now.

HiFi Design

As the conversations and design exploration continued to be refined, we decided on a few core pieces of this experience:

  1. Help the user see at a glance whether they’re commission qualified or not
    • If not qualified, help them understand why and give them an action to take.
    • If qualified, are there any other relevant messaging or actions they might need or want to take?
  2. Let the user quickly see at a glance their next commission amount and next pay date.
  3. If their commission are on hold for any reason, change the pay date to a status that indicates that change

Here’s an image of what that might look like:

So we had the core component structure defined, but I was having a difficult time keeping track of all the rules and variables that we wanted to help users understand. I also felt like we hadn’t uncovered enough of the details or answered enough questions about the rules to truly be effective in communicating with users.

Because of this huge amount of dependencies and options to consider across all or our 24 markets I created a helpful visual. The image below is just a portion of the actual FigJam file, but I think it communicates enough of the complexity and large amount of details we were dealing with.

Initially it was just for me to keep track of the full user experience and make sure there weren’t pieces getting lost, but it quickly became very popular for the people working on the project. I used the flows to explain how all the pieces fit together and which messages would take priority over others so that it was easier for the devs to build out the logic. It also helped other stakeholders and anyone else to see at a glance the differences between markets and get oriented around how everything fits together. Even though it was a challenging to make I’m very proud of what it helped us accomplish together!

With the help of those flows we started to understand how something like this could actually be possible. We began to identify the different messages and states we could support for the initial launch of this new tool. We knew that even a portion of the options we explored would be a massive step towards a much improved user experience and we wanted to start with a simple set of core pieces. We knew that we had everything we needed to continue explorations in the future and keep building on the solid foundation that we created together. Here’s what some of those might look like:

Throughout all these conversations I was also continuing to refine the HiFi designs. I also started working with one of our amazing UX Researchers to get some really scrappy research done. We weren’t officially approved for UX Research on this project but we still wanted some insight from others. The testing was done with a very small number of Usana employees to gauge the overall effectiveness of the layout, hierarchy, color, and messaging. Although it was a small number of people and none of them were from our target user base, they did have relevant domain knowledge as employees. We were able to gather some valuable insights that helped us further refine the HiFi design.

After the testing I worked with the UX Researcher to make some adjustments to the design based on the feedback. I also made sure to stress test the designs against situations like when people’s text is displayed much larger on their device. Doing this helps me further solidify the design to be more flexible for more people.

I held a final design review with the entire UX team to check if there were any other missing pieces I might want to consider. During that meeting the primary takeaway was that we could improve the behavior for when someone switches between qualified and not qualified.

I had been looking at two different styles for communicating that status change. One was a small colored badge and the other was a larger colored banner across the top of the card.

My approach was to use one or the other, but we decided that a hybrid of the 2 might actually work much better. We decided that if we displayed the larger banner whenever the status changed that it would have more impact and reduce potential banner blindness. The small badge would replace the banner if the status hadn’t changed after a set amount of time. That way they could rely on the less intrusive badge communicate their status most of the time and when the status changes the banner would emphasize that really well. I really like how that turned out!

Delivery

The project is still ongoing as I write this, and it will take further iterations to achieve our full vision, but the initial launch is set to happen within the next few months, and it’s truly incredible to see how much value there will be even in this first iteration!

After all the iterations and exploration it’s time to wrap things up for this first phase and send it to the devs. To do that I needed to coordinate with our writing team to approve all final content and get translations. It’s not a simple task with all the languages we support especially when different markets have different messages that they need to be translated. We’re currently wrapping this up and I’ll update with more once we do.

Outro

Although impact hasn’t been measured directly yet, we know that many users are very excited for this to launch. We also know that it’s going to push Usana into new territory for the quality and depth of experiences needed for the future. Although it’s hard to say if more projects will get this much focus and depth in the future at Usana, I’m incredibly happy with what we created together! I hope users will find them just as insightful. 🤞