00 — Problem

Customers couldn’t navigate Premier

Customers were having difficulty navigating Premier, prompting them to contact sales representatives or leave Premier entirely.

01 — Discovery

Listening to stakeholders and customers

Stakeholder research: 6 workshops with the Premier HP stakeholders, 2 with the global merchandising team, and 1 ideation and 1 problem statement workshop with the core team.

Customer research: 10 Premier customers across medium business, commercial, channel and sales representatives. The goal was to uncover gaps in their journey, validate expectations and test hypotheses.

• 10/10 want to talk to their sales representatives to purchase and update products, because it’s easier than doing it themselves
• 10/10 want to place bulk orders quickly, but struggle with the current interface
• 10/10 don’t find the current homepage content useful, since they rarely buy outside their preconfigured products
• 9/10 want to customize Premier to suit their needs

Stakeholders flagged clarity, information access and personalization, automation of common actions, collaborative shopping, and notifications such as expiring quotes.

02 — Framing

How might we…

• get customers the information they need, so they don’t have to rely on sales representatives?
• help customers quickly access the Premier features they use most and that matter to them?
• give each user type (shopper, buyer, admin) a valuable, delightful, tailored experience?
• personalize the homepage based on the customer’s intent?

03 — Design iterations

We iterated on the designs based on the research

Each iteration tested one of the insights from discovery.

04 — Feedback

What customers said about the new design

90% of customers liked the new design because it gives them tailored data for their business.

They also pointed to a few opportunity areas:

• Wouldn’t scroll past the dashboard to explore other areas (4/11)
• Didn’t like the advertising banner (3/11)
• Didn’t order new products, so popular products weren’t needed (2/11)

Based on this feedback, Phase 2 focused on strengthening the Dell Premier experience.

05 — Final design

Quick access first, then purchase history

I prioritized quick access to the most frequently used features and key customer information.

Next, I used purchase history to surface frequently bought items for faster reordering.

Finally, I placed support and spotlight sections at the bottom of the page to finish the journey.

06 — Before and after

Before and after

00 — Problem

A landing page without a clear value story

Dell Premier lacked a clear brand identity and a consistent value proposition, which made it hard to attract new customers and build loyalty.

01 — Discovery

Competitors and customers

I ran a competitive analysis of 20+ companies, then reviewed internal and external qualitative research.

• Unique value: what is the unique value of Dell Premier compared with other competitors?
• Dell branding: users expect Premier to be the final layer of what Dell offers customers
• Customer-centric benefits: users want to know what they will get, not just what we offer

02 — Framing

What the page needed to do

Users wanted to quickly scan the content, and they needed shorter videos that get to the point.

• Design workshops: user flow, content strategy and framework, wireframes, hi-fi design and prototypes
• Unmoderated user testing: 3 rounds with SMB, large and enterprise customers

03 — Final design

A landing page that explains Premier quickly

The new Premier Landing Page makes it easier for customers to quickly understand Premier’s value. Clear, scannable benefits, an interactive Premier Tour, and data-driven impact stories help users see how Dell Premier can support their business.

With added FAQs to address common questions, we reduced uncertainty and helped customers onboard more confidently.

04 — Before and after

Before and after

01 — Audit

Finding the gaps

I audited both platforms against WCAG 2.1 A and AA. The audits uncovered failure rates of 37% on ShelterTech.org and 24% on SFServiceGuide.org. I turned the findings into prioritized, actionable fixes.

02 — Enablement

Building capability, not just fixing issues

I created a “How to Test for Accessibility” training deck and a step-by-step checklist, so developers could test and remediate issues on their own. The goal was to strengthen compliance over the long term and build a culture of inclusive design across the team.

Process

How this project is moving

1. ProblemWhy people skip consent
2. FindingsWhat early research says
3. A/B testLong vs short consent
4. ThemesWhat people said
5. How might weOpportunities to design next
6. PrototypePolicy Summary

03 — A/B test

Long consent vs short consent

To see how people respond to consent, I built one sign-up flow for a made-up game, Stop@5, and changed only the privacy step.

Try Recipe A ↗ (opens in a new tab)  ·  Try Recipe B ↗ (opens in a new tab)

04 — Themes

What people said

I grouped what people said across both versions into four common themes.

• Too long to read

  With the long policy, people scrolled past or ticked the box without reading. Time was the main reason.

• Hard to tell what matters

  Dense legal wording made it hard to find what is collected, who gets it, and for how long.

• Short is easier, but is it trusted?

  The short card was quicker to get through, but people wanted a way to check it wasn’t leaving something out.

• Consent feels like a formality

  With a checkbox or an Agree button right there, agreeing felt like a step to get past, not a decision.

05 — How might we

Opportunities to design next

1. How might we help people understand what they’re agreeing to in under a minute?
2. How might we surface the few things that matter most (what’s collected, shared and kept) before the legal detail?
3. How might we make a short summary trustworthy by linking every point to the exact text it came from?
4. How might we make agreeing feel like a real decision, not a formality to click through?
5. How might we make consent feel like part of getting started, not a barrier to it?

06 — Prototype

Policy Summary: how it works

Policy Summary is my answer to these how-might-we statements. It is a browser extension concept that sits in the toolbar, reads the policy on the page, and shows a short summary next to the original text, so people can check every point against the source.

3. It answers in plain language

• What you’re agreeing to. A short paragraph, with the key actions in bold.
• Data collected. The types of data at a glance, as simple tags.
• Needs your attention. The few items worth a closer look, each with a section reference back to the policy.

Try the Policy Summary prototype ↗ (opens in a new tab)