App Audit

I started by auditing the current experience. I was pretty confident that many changes would be needed but wanted to validate my assumptions. Unfortunately, there wasn’t much documentation for the previous app, but combining what we had with the live/prod app I was able to pull together enough details to get a feel for where things were at.

After finishing my dive and talking with developers and stakeholders along the way, I came away with a few core takeaways.

Information Architecture Flows

With these ideas in mind I started creating flows. I like using visual artifacts to share what’s in my head and help other people share what’s in theirs. In this way we work towards alignment on the direction of the project. I do this at every step of the design process, but during these early stages I feel it’s much more critical in establishing a strong foundation for the project.

While reviewing the flows with the developers and stakeholders I focused on 3 key areas that would have the highest impact on both the user experience and developer experience.

The discussions were a big success and everyone agreed on the focus areas and things I called out! We all felt like we had a strong, cohesive vision for the project, and this alignment was pivotal to move into LoFi designs with clarity and purpose.

Holistic Information Architecture

While sketching I ensured we were thinking holistically about the app experience to avoid 2 things: scope creep and “painting ourselves into a corner”. One example of this can be seen in the image below where I explored how we might support both shopping (a future feature set) and sharing (the current feature set).

Because they are both very important product related actions, they needed to be considered together at this stage to ensure we were setting ourselves up for future success. However, we also needed to make sure that the system was flexible enough for future discoveries and that it didn’t paralyze us from finishing the product sharing designs.

While sketching and sharing them with others I would ask questions like:

Product Sharing & Lists

What’s the difference between product sharing and product lists and why am I making a big deal out of it?

In theory these lists could be used for any product related task (like adding to cart, subscribing, or sharing them with others). In reality, product lists at Usana can only be shared with others (for now). But the current implementation was causing issues that we needed to address before the upated Product Sharing experience launched

Why is this a big deal? And example of how this might go can be seen below.

I created many different sketches to explore how we could more clearly differentiate between these 2 actions and other improvements to product sharing. I used the sketches to communicate with others on the project different ways we might achieve our goals and specifically why the change for product lists would be so valuable to make.

Thankfully, after sharing the sketches, everyone was on board to give the power back to the users! This meant that they could choose how to share their products and when and that we were no longer forcing list creation on them when they didn’t ask.

More Sketches

Here’s a few more of the concepts and ideas that were explored to hone the product sharing experience, communicate with stakeholders and devs, and prepare for high fidelity designs.

I had been pushing for us to switch to Figma since I started working at Usana and this was the first project after we made the switch (so I was stoked!). This allowed me to improve file organization with sections, notes, and more details that would help devs and stakeholders. Example below.

I was also able to finally build a really solid component kit using my favorite Figma features like Auto Layout, and start building prototypes! 🤩 All of these things combined to really help step up our level of polish, coordination, and project solidity.

The Magic of Prototypes

Here’s a few pieces of the prototype I created for product sharing broken up into different feature sets. I’ll swap between iOS and Android so you can get a feel for both.

For some reason interactive design prototypes aren’t something people used much at Usana. Although I know they’re a decent chunk of work to set up, they can be built in to the design process to minimize that work and the value return is immense. Here’s the main reasons I prioritize creating prototypes as much as possible.

Whatever the reasoning is for a lack of prototypes at Usana, it was really fun to blaze new trails and showcase how awesome design can be! ✨ The devs and other stakeholders really enjoyed using the prototype during this project and I hope it catches on more in the future at Usana.