Adobe's new e-commerce storefront framework designed obsessively with modularity and customizability.
Overview
My role
Design systems
Wireframes
Prototyping
Responsive design
Accessibility
Interviews
There are a few reasons why Adobe's storefront offering needed a face lift.
It's monolithic.
Hard to take apart and start with the pieces you like. Changes in one area could break things somewhere else, and you'd have no idea.
It's complicated.
Impossible to customize without sinking thousands of $$ into development costs. Designers and engineers waste time reverse-engineering it.
It's outdated.
It doesn't look or feel great on mobile, which comprises most of e-commerce traffic today. Even on desktop, it feels… straight out of the 2000s.
"Magento is not incredibly adaptable. You have to be technical to understand how to change anything. Even the smallest change costs us a lot of money"
— Ecommerce Manager, Wholesale Company
Composable
The pieces can be swapped as needed while maintaining a quality experience and fast site, meeting the user needs of any merchant who may pick up our product.
Unopinionated
Our users don't want a "theme" to reverse-engineer. Whether in styling or structure, we provide the starting point for as many types of merchants as possible.
Quality experiences
The default experience we provide should follow modern best practices. At every scale, we should provide an excellent user experience, accessibility, and fast load times out of the box.

In our first year, we had 2 engineering teams working on a single app. Within the second year, I supported 5 different engineering teams working on 6 apps.
One of my major responsibilities was to identify opportunities to reuse functionality between all 6 of our apps, thus contributing it back to the design system and making it configurable to fit between the different contexts.
Of course, all the components and experience we created needed to be fully responsive and accessibility-checked.
At the time of writing this, we had been in beta for about 4 months, and for frustrating reasons such as shaky sales relationships or technical issues, haven't gotten authorization to interview the handful of clients using the apps. While waiting, we interviewed some internal sales teams that had to use our components and apps to create demo sites. Our research goal was to learn about the developer experience for adding apps to a site, styling, and customizing them. We discovered a huge success towards the main goal of the project:
The sales demo developers (working solely based on documentation) reported getting the site into a working state MUCH faster than with previous offerings.
They were impressed with how easy it was to toggle on and off common features of the cart and checkout process, and how good they looked out of the box.
We also uncovered pain points which have kick started discussions for several teams:
The publishing process with our Google Drive integration requires many manual clicks to publish all the files.
The style sheet for the storefront is hard to maintain alongside the style sheet for the entire site.
It can be confusing which APIs to use for what when connecting to different Adobe offerings.
App (dropin) developers can access the components we designed from Storybook.

They can preview all the configurations that they'll have access in the drop-in editing environment. Each component and container has been designed to look good no matter the breakpoint and configurations enabled.
The public boilerplate shows all the drop-ins in their default state working together. Here you can see the Product Detail Page, the User Auth, and Cart (mini cart) working together.
The drop-ins connect with real-time stock data from Adobe Commerce to show stock notifications and discounts.




Patina Network: Leadership, Workshops, and Strategy
How I led a series of workshops that transformed the vague ideas into an actionable roadmap, already benefitting dozens of students in just 4 months.
Leadership/Management
Service Design
IBM Storage Object Unification
An ambitious vision to merge two projects, carried out by rapid prototyping and testing.
UX Design
Rapid Prototyping
Research










