L.L. Bean
Summer 2026
Customer Preference Center
Role
UX Design Intern
Team
Me (sole designer) + UX manager
Timeline
8 weeks
Platform
Web (desktop)
Tools
Figma Figma Make Baymard
The TLDR: Eight weeks. One intern. A project the company wants to build and plans to prioritize.
L.L. Bean’s email preferences lived on a single page: subscribe, unsubscribe, pick a frequency, and choose a category. It covered the basics, but the company saw room for it to do much more. As customers expect more control over how brands communicate with them, and as first-party data becomes more valuable, L.L. Bean wanted to explore what a more robust, centralized Customer Preference Center could look like inside Account. I joined as a UX design intern to research, design, and validate that experience.
The result was a clickable web prototype built in Figma Make, a competitive audit across 15 brands, six stakeholder interviews, a solo-run usability study with four participants, and a final readout presented to my organization’s leadership, including a separate presentation to L.L. Bean’s CMO and CEO.
The brief: Exploring best practices for a customer preference page
Customers increasingly expect to control how brands communicate with them and personalize their experience. The brief hypothesized that L.L. Bean’s preferences were likely spread across multiple systems and touchpoints, which can create confusion for customers and inefficiencies for the business, and it framed the project as an opportunity to explore a clearer, more centralized approach within Account.
Part of my job was to test that hypothesis. Stakeholders told me the existing preference settings were lightly used and rarely promoted, and the competitive audit showed how fragmented preference experiences are across the category. We had no internal data on customer confusion, so I treated the project as an opportunity to build the case for better preferences rather than fix a measured problem.
What that brief didn’t say (but became clear quickly) was that this project sat at the intersection of email marketing, personalization, CRM, site analytics, and product strategy. Getting the design right meant understanding all of them.
Phase 1: Understanding the landscape with a competitive audit across 15 brands
I audited 15 brands across outdoor, fashion, and retail, from direct competitors like Lands’ End and REI to references like Sephora and Nordstrom, looking at structure, customer control, and personalization depth.
15 brands audited
The audit pointed toward a clear recommendation: a single-page, unified preference center with visible status signifiers, frictionless navigation, meaningful personalization options, and clear feedback loops.
Phase 2: Interviewing stakeholders across the Direct Consumer Insights organization
Before touching a wireframe, I needed to understand what was actually feasible inside L.L. Bean’s systems. I conducted six 1-on-1 stakeholder interviews across email marketing, site analytics, personalization, CRM, and product strategy, developing my own questions for each after my manager gave me context on each person’s role and how it might connect to the project.
Three conversations shaped the design most directly:
The synthesis: Personalization and control were important patterns
Across all six interviews, a few things crystallized: personalization was a shared priority across teams; the email marketing system had real constraints that needed to be designed around, not ignored; and the CPC had potential to serve as a data source for personalization that went beyond just communication preferences.
Phase 3: The design, keeping what worked and tackling personalization
What the MVP needed to do
Based on research, I defined four design principles for the CPC:
Visible status signifiers: users should always know their current subscription status, active email, and saved preferences at a glance
Frictionless navigation: preferences should be accessible in as few steps as possible, directly within the Account page
Clear feedback loops: changes should be confirmed visibly, with realistic expectations set about when they'll take effect
Reduced cognitive load: the page should feel helpful, not like a form to fill out
The preference categories
For MVP, I recommended four content areas:
MVP vs. Redesign
One of the earliest constraints I identified was that the CPC would need to be built, and building takes time, budget, and engineering prioritization. Designing only for an ideal future state would produce beautiful work that sat on a shelf. So I designed both.
The MVP version stays within L.L. Bean’s current design system: radio buttons, plain text labels, and the existing type and spacing patterns. It’s a meaningful upgrade over what exists today, with a cleaner structure, visible status signifiers, and the frequency feature surfaced more prominently, but it asks nothing new of the engineering team. It could ship without a design system overhaul.
The redesign version draws from visual direction L.L. Bean was already moving toward (rounded cards, flat color blocks, and a more modern spatial rhythm) visible in internal work like the (at the time) unreleased Rewards page. It’s the version that earns the experience its weight, makes personalization feel inviting rather than functional, and sets the page up to grow. It’s the version worth building when the time comes.
01 Current Page
02 MVP
03 Redesign
The Prototype
Iteration
The process to reach the final redesign took many iterative attempts and feedback sessions. From sketches to mid-fi prototypes, the page's structure stayed cohesive, but its aesthetic changed as new considerations arose and other inspiration was incorporated.
01 Sketch
02 Lo-Fi
03 Mid-Fi
Phase 4: Usability testing, better understanding visibility and feedback
I wrote the study script, designed the tasks, and ran all four sessions myself, getting feedback on the script from a colleague before going live.
I tested with four fellow L.L. Bean interns from different organizations across the company, who used the prototype on my laptop while thinking aloud.
The scenario was built around getting too many emails, so participants were primed to look for a way to cut back. I read the frequency result as a strong directional signal, not proof, and one worth A/B testing against unsubscribe rates after launch. From there, I let them navigate naturally rather than directing them step by step.
The version tested was stylistically almost identical to the final design, except for the save feedback, which I provide a visual for later in this section.
What worked better: The email frequency
“I’d choose frequency instead of unsubscribing.”
— Usability study participant
What I didn’t expect: Feedback that is too subtle may as well not be there
Feedback That Works Without Sight: Accessibility Considerations
The save-feedback problem was also an accessibility problem. A toast that disappears after a few seconds is easy to miss for anyone, and for screen reader users it may never be announced at all. That’s one reason the fix pairs a toast with a persistent save bar: the confirmation stays on the page instead of depending on a single transient element.
I documented these accessibility considerations for the build team:
Status announcements. The toast and the “unsaved changes” state should be announced politely to assistive technology (
role="status"/aria-live="polite"), and the toast should stay up long enough to be read.Frequency options. These should be grouped as a labeled radio set so a screen reader announces the question along with the choices.
Keyboard and focus. Every control should be reachable in a logical order, and the floating save bar shouldn’t cover the field a user is focused on.
I didn’t test with assistive technology users, so this is a handoff checklist, not a validated result. Testing with screen reader users would be a first step before launch.
The final readout
I presented the full project (competitive audit findings, stakeholder synthesis, design decisions, and usability results) to my organization’s leadership: my manager, my manager’s director, and the organization’s VP, along with other stakeholders.
I also presented a shorter version at an intern open house to L.L. Bean’s CMO, Nick Wilkoff, and CEO, Greg Elder.
What happens next
Not yet scheduled; the team is prioritizing budget. The research and prototype are handed off for when it is.
Reflections
Systems thinking is a research skill
Going into stakeholder interviews, I thought I was gathering input to inform design decisions. I came out understanding that design decisions at this scale are really decisions about systems, marketing infrastructure, data pipelines, personalization models, loyalty programs.
Frequency may be a retention lever hiding in plain sight
All four usability participants said the frequency option would keep them subscribed; small, but a clear signal. Most brands don’t offer it. L.L. Bean already had it but wasn’t highlighting it. Sometimes the right design move is making visible what already exists.
Consequential feedback needs to be unavoidable
The save bar taught me that subtlety is a liability when users need confirmation that something important happened. If a person has just managed their relationship with a brand’s communications, they need to know it worked, clearly, immediately, and without having to scroll to find out.
Beyond the brief
Internships aren't only about the deliverables. Some of the most meaningful work I did this summer happened outside my primary project.
Sketch → Framer component library
Alongside the CPC, I ported part of L.L. Bean's Creative Design component library from Sketch to Framer: about 10 components with variants, plus a set of icons. It meant working across two teams at once and switching between a product UX mindset and a brand design one.
Camp Beantern keychain
As a farewell to our intern cohort, I designed an L.L. Bean-inspired keychain. HR then licensed the design for all future cohorts, so a personal gesture became a small, permanent part of how the company welcomes its interns.
These experiences were a reminder that the impact you have at a company rarely stays inside your job description.
Shasteny Maclang