Powersupply is a meal delivery service that caters to the diets of vegetarians and paleo interest.  They got their start in the CrossFit community and have been able to accomplish scale by scouting existing related meal delivery services, their delivery logistic software and an ability to tap drivers and CrossFit gyms for ensuring the meals make it to their desired niche fresh and ready to heat and enjoy.

MY Role

I would come on to perform as a UX Product Designer and Prototyper consultant for both web and mobile products. We worked iteratively in a validation driven-agile style, where much of the improvements were legacy issues discovered after the accrual of some significant technical debt.  I would make iterative designs and prototypes to the web product, and would later shift my focus to designing and prototyping for native mobile platforms. 

The User

Powersupply serves a range of customers, though the brand evokes the spirit of the CrossFit community. Health enthusiasts who are on the go between work, the gym, and an active social life find the meals to fit their dietary needs and allow for committing to a lifestyle that is gaining popularity in California, New York and other metro cities. Powersupply also fairs well with those who are earnest about a dietary regimen but may not always have access to healthy options at the workplace.  

Initial Project: Improving the Menu

Recurring users, the user group we focused on for much of my tenure, find themselves at the menu more frequently than any other place on the site. Powersupply was engineered to remove the What should I order? decision from the user, therefore when users have elected a meal plan (consisting of the meal type and quantity, also delivery day) the meals are preselected for their upcoming order.

Displayed is the menu the user sees when s/he has elected to change the default selection of meals that are set for delivery. That the meals are pre-selected, users who want to modify (or 'mod) their delivery have found a few issues when it comes to using it.


How do we know there is a problem?

  • Users frequently go over or under their meal plan, which results in an error state in the UI when they go to update their order.
  • It takes a considerable amount of time to modify their order when they do not have meals on the way that they'd like to enjoy; a high-value investment that can mean the user has food arrive that they don't particularly care for should they not have time to commit changing their order.
  • The selected items aren't very distinguished from the rest of the menu; even more of an issue for colorblind users.
  • The requirement to read the menu without the aid of images or icons, making it difficult to scan and make decisions.
  • The lack of information hierarchy, which means all of the information on the page is equally important to the user.
  • The action to update the cart is at the very bottom of the view, which, in order for the user to access, they must scroll out of view of items they may have selected. Since this view doesn't update in real-time, the user is forced to count the number in the drop-down selectors so to know how many items are in their cart. 
  • Once I've arrived at this view, I'm not 100% sure of where I am independent of the breadcrumb at the sub-header level of the view. Further, notice the different menu options top right of the header: There are actions that may be best displayed within a more related context (e.g. Refer a friend, for example, may be more relatively actionable within the billing or order summary views. This way, any incentive could be better articulated as beneficial to the user's actions.)
  • The closeness of the different menu items makes them almost appear related when they're not.
  • The lack of color variance also makes the meal items appear related, therefore monotonous to the user as s/he reads down the page.


what is the Impact of solving these problems?

  • Less time modifying the user's order means a less likelihood they will cancel their meal plans or bounce off the menu when they'd actually like to change their order.
  • The faster a user can ensure they will receive meals they enjoy, the likelihood they will find the meals tasty, enjoyable and worth their value.
  • The more meals users enjoy, the most likely they will recommend our product to a friend, coworker, or family member.
  • The more users are retained, the more sustainable growth is for the business. 

what are the USER CENTERED Goals?

I came up with a list of user-centered goals developed from the pain points and supporting hypothesis:

  • Reduce the time it takes for the user to know what is being delivered
  • Reduce the time it takes for the user to modify their weekly order
  • Make it (more) obvious what meals will be delivered
  • Reduce the number of clicks for the user to know about a meal's nutritional value; reducing the time it takes to make a selection
  • Aid in the accessibility of actions

what Hypothesis can be tested?

As a designer...

...by addressing the view's information hierarchy, layout, actions (swapping buttons for downtown selectors), and an additional feature of displaying a cart summary, the user will save time and have more clarity when it comes to knowing what is in their weekly meal order, making modifying their meal orders more efficient and enjoyable. 

    what are the constraints?

    Designing and developing digital products never have the most ideal circumstances. Even the largest organizations face constraints when it comes to shipping products people in joy. It's best to know the constraints before going into any design, but sometimes its good to focus on the user and the user alone. Here are some of the constraints I navigated in order to ship valuable pixels to Powersupply customers. 

    • The product’s architecture did not support some of the designs out of the box given there were no front end helpers (eg. Javascript); each action would make a call to the backend, which required the view is refreshed even for updating items in the user’s basket.
    • The container of the view was constrained and did not allow for full-width design implementation.  This meant the concepts had to fall within a certain grid, which may limit some holistic approaches to a design's layout. 
    • The scope or concept around filtering was borrowed from other products; it's ideal to let the problem define the approach and not the feature. 
    • There was only a single engineer tasked with implementation, who already had their hands full overhauling the stack to incorporate react.
    • Product direction was led and supported by the CEO, who at the time was raising a funding round. The round was never acquired and once back to the day-to-day in office, the shift to a brand overhaul took precedent of both resources and focus.
    • The stack did not allow for photographs of food to be displayed in the menu, which may have improved the speed and efficiency of users finding meals they’d likely enjoy. It is also the reason for why the menu items relied so heavily on written descriptions. 
    • There wasn't a user-centered, consistent style guide used through the design system and there wasn't that much time to explore implementation given some the product direction and vision on the roadmap. As a designer, you have to know what to fight for and some of the allowances to make quality work aren't always affordances. 

    Design Iterations - Grand in Vision, Reductive in Practice

    The design approach took the initial information from the living designs (e.g. food title and chef information) and added ingredients as the second most important set of information according to our customers. We imagined improving the product as a whole by focusing on the view the user sees the most: their menu and order for the week. 


    As a user, I want to have some control over what food gets delivered since the application auto-selects meals for me that I may have already enjoyed, especially when I want to try something new. That I'm on the go, I want to be able to quickly distinguish what's on the menu so I can make decisions quickly, so I can save time.

    menu wireframe: first design pass

    • Attention to hierarchy, surfacing more meal information, and making actions obvious through buttons look to solve some of the initial user problems.
    • The layout allows for more space between meal items. It also allows the user to read three items in line, improving the speed which the menu items can be scanned. 


      Quickly bringing color into this pass, there is still a lot more to think about like the title lengths, but it is more obvious in this pass what has been selected for the next delivery. This pass also experiments with the notion of filters being applied to narrow down the menu choices, a feature I was asked to explore during this exercise.


      This design is starting to take shape, but there is more we'd like to surface like ratings and meal nutritional data.


      With color variances, stronger subtitle descriptions for ingredients, use of subtle icons like the star rating, and tags for further categorization, this UI is finally starting to look more like a product that could ship in the future. 

      The cart summary has been added to this view, which anchors upon scrolling, which when the user makes a change to their menu, is updated to make the user aware of whether or not they are within their meal plan.


      Below you will find a few task related to the designs I was happy to contribute, though they never shipped given the aforementioned. 

      Task: Add / Remove a Meal Item from an Order

      Task: Modify Meal Item Quantity via Input

      Task: Filter Menu by Dietary Preference

      *Disclaimer This feature was pre-baked or defined upon my arrival, and pushback was in some ways futile, though I was not 100% on board initially. If I were to reapproach this particular use case of disocvering meals based on preference, I would have taken an approach displayed in the mobile design featured here.  By displaying the meal types as a subheader, the types of meals would have been more accessible and much easier to filter by.

      Pivoting (Backwards)

      While the above concept took the back burner, we pivoted our focus given the aforementioned constraints, mainly the container layout. We drastically scaled back the menu experience implementation around a single pain point rather than addressing multiple issues in a single design.

      REFINED Challenge

      There is no obvious way to know what items have been selected for your weekly delivery. 

      REVISED Hypothesis

      By displaying the meals selected for the week as a summary in the right column, users will always know what’s in their upcoming weekly delivery, no matter where they are in the menu’s view; they will less likely commit an error should they elect more or less of what their meal plan allows for.  Placement of the update button would have to remain in view at all times; even better if it's not pushed around given the changes to the user's selection.


      Make meals selected for the week's delivery more obvious, as well as items that will be added to or replaced from the user's selections.

      Iteration Pass: Menu w/ Basket Selections (Error State)

      You can see how that implementation fairs below, in this instance, the error state is displayed in the situation that the user goes over their meal plan. 


      You can see how that implementation faired in an interview I conducted below. 

      Design Interview: https://cl.ly/150N2a2B0H0K

      Other Design Explorations

      Pricing Page: Living Design

      Displayed is the pricing page selected from the header. 


      The amount of and clarity around dopy was one of the major issues with this current design, not to mention there isn't a strong hierarchy of information.  "Boost" and "Standard" aren't clearly indicative of what the user is getting, though the supplemental copy helps; it means the user has more burden placed on their availability to find out what it is they may be looking for.

      The extremely small fine print is really difficult to read and would be best if summed on a dedicated view or section for questions and answers.

      pricing original view.png

      Pricing Page: Single iteration pass

      This iteration sought to better describe what is in view: pricing for meals, but not limited to the cost of having them delivered. There is an emphasis on legibility, and reducing the view's copy to the most important information pertaining to making a budgeting decision more easier.  The smaller copy in the previous design would live behind the FAQ link.

      The call to action "Place an Order" is added so the user can take action on the information they have learned from the pricing view. 

      Order View: Living Design

      Displayed is the view that allows users to place a meal plan order, specifically the form where they would enter their address. 


      Forms are some of the most important yet consistent problem areas on the product. Here, the text alignment is a bit disorienting from the header and leading into the form. The summary information in the right column, which is currently empty, does not explain what will in its view. There are also inconsistencies of button size and button titles throughout the view.


      Attention to the layout, typographical hierarchy, and consistency of actions, as well as clarity around the copy,  are the emphasis this pass. The order summary (in the right column) reads like one, giving the user a sense of what choices they have made throughout the order process, striving for clarity and ultimately an order placed at the end of the required tasks. Attention to the form's content and input titles were also emphasized.

      Design Learnings

      A ton of lessons were learned during my tenure at Powersupply. I learned the importance of a user-centered, value-driven product roadmap and how constraints should be best surfaced in the initial onset of a project, even when you have full liberty to imagine the future of a product. 

      The best products consist of components that work together to comprise a system. Products, simply put, allow people to accomplish their goals. And design is how we approach solving these problems for customers. Designing an experience from beginning to end around a user's needs require understanding the importance of what people want and giving it to them; no more and no less. It's an intricate dance where balancing tradeoffs for what's feasible and research and insights, should always take precedent over bias and influenced mythical outcomes. If you don't know your customers and are not echoing their voice of concerns in meetings, then you're doing it wrong. 

      Good design is a business driver. Design as a practice isn't always thought of a as way to make money. It's not until you begin to add data to funnels that design seems to take on the shape product owners will care about. The sooner a designer's hypothesis has a quantifiable goals, the sooner teams realize that design can make money. And therefore can make or break a business. 

      Talking to users, capturing feedback and prioritizing user's wants against companies goals and a product roadmap is a mirror on two sides of the conference table. The product roadmap should mirror not only what the user has in front of them, but should also reflect the vision of the needs they don't already know they have. This is the talent of leadership vision and how well a group of individuals can synthesize business and customer needs into products people take delight in. 

      Applying Learnings to Native Mobile

      You can experience some of these learnings and UX design improvements in the mobile application I designed.