It’s actually painful that apple’s new “liquid glass” isn’t a joke. It’s a design nightmare ๐ and it’s so easy to spot! ๐คฆโโ๏ธ
visualdesign
It’s actually painful that apple’s new “liquid glass” isn’t a joke. It’s a design nightmare ๐ and it’s so easy to spot! ๐คฆโโ๏ธ
It’s been fun exploring open source design collaboration with people helping build F-Droid. Here’s some sketches that I made to communicate potentially design options for an upcoming app store design update to Material 3.
A really cool animated prototype I made towards the end of my time at Usana. I love making really polished prototypes that showcase not only interactions but also how things might animate on screen. ๐คฉ
And here’s a couple images of the designs I created for the same project.


Platform
Android & iOS
Project Type
Solo Designer
My Role
Lead UX Designer
Tools
Figma, Figjam
Timeline
Sep 2023 – Mar 2024
Suddenly, our team faced an unexpected deadline. The product sharing app’s core software was about to be shutdown, and it was a highly used mobile app feature. I led the effort to not only replace but improve mobile product sharing at Usana. It was a tale for the storybooks, proving that solid design practices and processes create the best digital experiences, even in unexpected circumstances. ๐
An old app housed the product sharing features, and was going to be deprecated unexpectedly. It was built using a technology called Xamarin, and Microsoft (the owner of Xamarin) was shutting the technology down in less than a year.
The Problem
We unexpectedly needed to design and develop a new product sharing experience and only had about 6 months
The app was both difficult to maintain and not a good look for the brand. However, we had been planning to focus on design and development of other feature sets and this threw a wrench into the mix! Regardless, we pushed those dreams aside to make way for this imminent change.
TLDR
Starting with an app audit to understand the existing experience better I was able to start understanding which areas we might want to focus on with the improved design. This helped inform the flows and questions I brought to the developers and other stakeholders.
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 production 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.
There wasn’t much structure or strategy behind the app’s features or layout
The code was unwieldy for developers and the design and interactions were confusing
No one really knew how or why certain decisions and features were made or included
We had a really successful and enjoyable workshop that helped us gather a lot of highly relevant ideas, perspectives, and information from many different areas of expertise. These workshops focused on getting designers, developers, project owners, and other stakeholders with highly relevant domain knowledge together so that we could ensure as many pieces of the puzzle were being considered. Here’s a couple of great snapshots from the workshop.


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.
Improved navigation and information rachitecture
Improved clarity about product sharing and list features
Implementation of native OS share sheet tech
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.
TLDR
With our newfound alignment and focus areas I started to guide the conversation to more detailed sketches. Not only did we decide on some solid information architecture that would set the foundations for both this phase and the next, we also had a big win for stakeholders getting on board with a change to product sharing that would enhance the user experience.
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:
One
Could shopping and sharing exist in the same space or do they need their own spaces?
Two
How might we structure sub-navigation elements to support all product related features, not just product sharing?
Three
What might we prepare now so that both the user experience and technical foundations are strong and long lasting?
Four
What would the intermediary steps be to support product sharing until the full app feature set was ready?
Thinking broadly about the app and talking openly with developers and stakeholders allowed us to reduce technical and UX debt and create a reliable experience that people could enjoy now and not need to relearn when new features launch.
What’s the difference between product sharing and product lists and why am I making a big deal out of it?
As simple as sending a product link to someone from your favorite online shopping platform.
Think of product lists as a group of products you save to use multiple times. Similar to “Favorites”.
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 updated Product Sharing experience launched
UX Calamity
Whenever someone shared a product, a list was being created whether they asked for it or not.
Why is this a big deal? And example of how this might go can be seen below.

After a selection of one or multiple products, if the “Share” button was tapped it would create a list with a default name applied. But what if the user didn’t want to save a list? What if they just wanted to share products on-the-fly? After a while, these lists also start to clog up and make it difficult for users to find the lists they did actually want to save.
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 why this 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.
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.





TLDR
We finally switched to Figma right before this project started and I got busy building the mobile component kit and setting the groundwork for better file organization and prototypes. The shift to native sharing tech was a simple but big win for both developers and users.
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.
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.
Android
Showcasing functionality of category navigation, list and grid view, and the category menu’s.
iOS
Showcasing functionality of product lists and where they’re located within the app hierarchy.
Android
Showcasing sharing products and adding products to a list.
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.
Devs, stakeholders and anyone else can quickly understand interactions and design intent
Designer catches more UX issues and solidifies the interactions and variants much deeper
A magical tool for anyone to communicate project details, design rationale and more
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.
Share sheets (like the one below) have become such a common interaction on mobile devices that you probably don’t think twice about what they are or how an app could build their own custom version if they really wanted to.


Usana had been using a totally custom interface for sharing. Don’t get me wrong, I’m all for breaking things and trying new ideas to make things better, but in this situation the custom solution was worse than the default. Even more concerning is that no one at Usana seemed to know why this was used instead, here’s a peek at the previous experience:

The value for switching to native share sheet tech was clear for users, developers, and the business:
We were all very excited to have found alignment between all of our needs and a really great solution to a problem that many didn’t even realize we had.
Insight
Part of the design process for me is evaluating dev, stakeholder, and business needs along with user needs.
As we continued to explore both the HiFi designs and prototype together we were able to solidify the experience through additional review meetings and conversations. We were on track to meet our deadlines with the app deprecation, but there wasn’t too much extra space to spare. Here’s a closer look at a more of the HiFi designs.







Thanks to the improved file organization and the use of an interactive prototype, the handoff to developers went smoother than ever! Here’s a snapshot of the entire file that was delivered. Like most projects there were a few unexpected design changes during development, but nothing we couldn’t handle. ๐ช

Not only were we able to deliver the product sharing feature set within the needed time frame, but also improved the experience in all of our focus areas! The new experience matches current mobile design patterns, modern technologies and improves both the user and developer experience. Lastly, although we didn’t have enough data analytics set up to measure user engagement or other metrics, we have heard consistently and frequently from users about how much they love the new app and how it’s changing their Usana experience in big ways!
How to navigate challenging conversations better with more focus on using visual artifacts
Starting with a project exploration workshop really helped set the project mood & foundation
Understanding each person’s goals & current view is really crucial to moving together
I’ve thought for so many years that Google could have had a much more powerful rebrand for its many app icons if it did something like this:

I designed these icons a few years ago to match the beautiful new Chrome OS icons that we’re coming out, cuz I loved the aesthetic so much! Then Material You came out and it felt like this style was the perfect match for the next iteration of Google’s design system, and I’ve always been confused why they decided to go with their confusing multicolored icons instead.
Like c’mon, this other style has so much more character and life! ๐คฉ
It’s actually painful that apple’s new “liquid glass” isn’t a joke. It’s a design nightmare ๐ and it’s so easy to spot! ๐คฆโโ๏ธ
It’s been fun exploring open source design collaboration with people helping build F-Droid. Here’s some sketches that I made to communicate potentially design options for an upcoming app store design update to Material 3.
A really cool animated prototype I made towards the end of my time at Usana. I love making really polished prototypes that showcase not only interactions but also how things might animate on screen. ๐คฉ
And here’s a couple images of the designs I created for the same project.


Platform
Android & iOS
Project Type
Solo Designer
My Role
Lead UX Designer
Tools
Figma, Figjam
Timeline
Sep 2023 – Mar 2024
Suddenly, our team faced an unexpected deadline. The product sharing app’s core software was about to be shutdown, and it was a highly used mobile app feature. I led the effort to not only replace but improve mobile product sharing at Usana. It was a tale for the storybooks, proving that solid design practices and processes create the best digital experiences, even in unexpected circumstances. ๐
An old app housed the product sharing features, and was going to be deprecated unexpectedly. It was built using a technology called Xamarin, and Microsoft (the owner of Xamarin) was shutting the technology down in less than a year.
The Problem
We unexpectedly needed to design and develop a new product sharing experience and only had about 6 months
The app was both difficult to maintain and not a good look for the brand. However, we had been planning to focus on design and development of other feature sets and this threw a wrench into the mix! Regardless, we pushed those dreams aside to make way for this imminent change.
TLDR
Starting with an app audit to understand the existing experience better I was able to start understanding which areas we might want to focus on with the improved design. This helped inform the flows and questions I brought to the developers and other stakeholders.
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 production 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.
There wasn’t much structure or strategy behind the app’s features or layout
The code was unwieldy for developers and the design and interactions were confusing
No one really knew how or why certain decisions and features were made or included
We had a really successful and enjoyable workshop that helped us gather a lot of highly relevant ideas, perspectives, and information from many different areas of expertise. These workshops focused on getting designers, developers, project owners, and other stakeholders with highly relevant domain knowledge together so that we could ensure as many pieces of the puzzle were being considered. Here’s a couple of great snapshots from the workshop.


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.
Improved navigation and information rachitecture
Improved clarity about product sharing and list features
Implementation of native OS share sheet tech
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.
TLDR
With our newfound alignment and focus areas I started to guide the conversation to more detailed sketches. Not only did we decide on some solid information architecture that would set the foundations for both this phase and the next, we also had a big win for stakeholders getting on board with a change to product sharing that would enhance the user experience.
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:
One
Could shopping and sharing exist in the same space or do they need their own spaces?
Two
How might we structure sub-navigation elements to support all product related features, not just product sharing?
Three
What might we prepare now so that both the user experience and technical foundations are strong and long lasting?
Four
What would the intermediary steps be to support product sharing until the full app feature set was ready?
Thinking broadly about the app and talking openly with developers and stakeholders allowed us to reduce technical and UX debt and create a reliable experience that people could enjoy now and not need to relearn when new features launch.
What’s the difference between product sharing and product lists and why am I making a big deal out of it?
As simple as sending a product link to someone from your favorite online shopping platform.
Think of product lists as a group of products you save to use multiple times. Similar to “Favorites”.
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 updated Product Sharing experience launched
UX Calamity
Whenever someone shared a product, a list was being created whether they asked for it or not.
Why is this a big deal? And example of how this might go can be seen below.

After a selection of one or multiple products, if the “Share” button was tapped it would create a list with a default name applied. But what if the user didn’t want to save a list? What if they just wanted to share products on-the-fly? After a while, these lists also start to clog up and make it difficult for users to find the lists they did actually want to save.
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 why this 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.
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.





TLDR
We finally switched to Figma right before this project started and I got busy building the mobile component kit and setting the groundwork for better file organization and prototypes. The shift to native sharing tech was a simple but big win for both developers and users.
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.
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.
Android
Showcasing functionality of category navigation, list and grid view, and the category menu’s.
iOS
Showcasing functionality of product lists and where they’re located within the app hierarchy.
Android
Showcasing sharing products and adding products to a list.
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.
Devs, stakeholders and anyone else can quickly understand interactions and design intent
Designer catches more UX issues and solidifies the interactions and variants much deeper
A magical tool for anyone to communicate project details, design rationale and more
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.
Share sheets (like the one below) have become such a common interaction on mobile devices that you probably don’t think twice about what they are or how an app could build their own custom version if they really wanted to.


Usana had been using a totally custom interface for sharing. Don’t get me wrong, I’m all for breaking things and trying new ideas to make things better, but in this situation the custom solution was worse than the default. Even more concerning is that no one at Usana seemed to know why this was used instead, here’s a peek at the previous experience:

The value for switching to native share sheet tech was clear for users, developers, and the business:
We were all very excited to have found alignment between all of our needs and a really great solution to a problem that many didn’t even realize we had.
Insight
Part of the design process for me is evaluating dev, stakeholder, and business needs along with user needs.
As we continued to explore both the HiFi designs and prototype together we were able to solidify the experience through additional review meetings and conversations. We were on track to meet our deadlines with the app deprecation, but there wasn’t too much extra space to spare. Here’s a closer look at a more of the HiFi designs.







Thanks to the improved file organization and the use of an interactive prototype, the handoff to developers went smoother than ever! Here’s a snapshot of the entire file that was delivered. Like most projects there were a few unexpected design changes during development, but nothing we couldn’t handle. ๐ช

Not only were we able to deliver the product sharing feature set within the needed time frame, but also improved the experience in all of our focus areas! The new experience matches current mobile design patterns, modern technologies and improves both the user and developer experience. Lastly, although we didn’t have enough data analytics set up to measure user engagement or other metrics, we have heard consistently and frequently from users about how much they love the new app and how it’s changing their Usana experience in big ways!
How to navigate challenging conversations better with more focus on using visual artifacts
Starting with a project exploration workshop really helped set the project mood & foundation
Understanding each person’s goals & current view is really crucial to moving together
I’ve thought for so many years that Google could have had a much more powerful rebrand for its many app icons if it did something like this:

I designed these icons a few years ago to match the beautiful new Chrome OS icons that we’re coming out, cuz I loved the aesthetic so much! Then Material You came out and it felt like this style was the perfect match for the next iteration of Google’s design system, and I’ve always been confused why they decided to go with their confusing multicolored icons instead.
Like c’mon, this other style has so much more character and life! ๐คฉ
Form supports function
Curiosity is essential
Space for anyone
Curiosity
Driven
Critical
Thinking
Detail
Oriented
Analysis
Paralysis
Foolish Idealism
Variant Maelstrom
Form supports function
Curiosity is essential
Space for anyone
Curiosity
Driven
Critical
Thinking
Detail
Oriented
Analysis
Paralysis
Foolish Idealism
Variant Maelstrom

