Designers love a new tool, especially one that opens new ways of
thinking. LLMs are shiny! shiny! new! new! and the possibilities
are quite real. Having spent the past year building,
experimenting, and researching, I've developed a clear-eyed
understanding of what they can do and where they fall short,
including how they work, how they were built, and the broader
economic and environmental implications of their use.
There is good and bad, and still much to discover, but what I do
know is that automatically reaching for the same tool before
considering the problem fully is hardly good design thinking. My
first priority as a designer is deep understanding: gather
context, ask questions, research, talk to people, poke around,
and generally, fuck around and find out why.
I maintain a healthy curiosity and a healthy skepticism about
AI-based processes. My approach to design prioritizes the need
of the problem over the tooling: it is quite easy to write a
prompt, harder to ask a good question, and even harder to figure
out if it’s the right question.
Responsible use matters to me, not just on an execution level
but on a human one. There are no clean datasets, no
hallucination-free models, and all of them use vast amounts of
energy, offsetting huge environmental costs to those with no say
in the matter.
"AI first", or default without consideration, is not a neutral
act.
Good design is not a generated outcome—it requires curiosity,
judgment, and genuine care, and I strive to bring that to
everything I do as a designer.
*** Shannon Miwa
***
sheriff@onehorse.town | (415) 508 8205 | Seattle, WA
http://onehorse.town
http://onehorse.townSenior Product Designer with 13+ years of experience across SaaS,
fintech, and enterprise platforms.
Proven track record leading complex 0-to-1 product builds,
establishing and scaling design systems, and driving
cross-functional alignment between product, engineering, and
business stakeholders. Skilled in end-to-end UX, from discovery and
user research through high-fidelity prototyping and production, with
a strong background in design strategy, mentorship, and emphasis on
systems thinking.
Provide contract-based product design and consulting for clients
across web and product design engagements
Redesigned a client's e-commerce site architecture and
navigation, introducing a scalable component system and
modernized UI
Maintain an active independent design and writing practice,
exploring AI-assisted design and development tools including
Claude Code, Replit, and Figma Make
Senior Product Designer
Assembled
May 2022 to June 2024
Managed relationships with 3–5 major enterprise clients,
retaining two churn-risk accounts and establishing a new
partnership that led to a new product initiative
Built a design system from a single page of legacy Figma
components into a fully-fledged system with design tokens,
variables, and multi-theme support; fully adopted by the product
team
Identified critical gaps in the user experience that led to a
repeatable model for new product launches, now used to guide
product strategy org-wide
Designed two products from concept to launch over ~6-month
cycles with large enterprise clients, owning the most complex
and ambiguous design challenges on each
Served as lead design consultant on Assembled's first AI
product, working alongside engineering and accounts through
tight timelines and fast-moving iteration
Senior Product Designer
Karat
March 2020 to April 2022
Served as one of two designers supporting a 30+ person product
organization, independently leading projects with high
conceptual complexity and sensitivity, including systems that
determined how clients hired people
Identified a critical communication gap between design,
marketing, PMM, accounts, and product that was causing sales to
oversell, and formed a working group to align teams on launches
and timelines
Redesigned internal tools and legacy features to unlock deeper
data insights, cutting multi-step processes from hours or days
down to 1–2 hours
Built and documented a design system with a focus on
accessibility and lightweight components, expanding developer
handoff materials to support engineering without dedicated UX
developers
Senior Product Designer
Braintree (Paypal)
August 2015 to April 2019
Spearheaded Braintree's first design system, building consensus
across a 14-person design team where no shared approach to
design decisions or visual cohesion had existed before
Led a full audit of the existing product, cataloging 20+ core
components plus icons and smaller elements, then defined usage
standards and aesthetics adopted across all design teams over
the course of a year
Drove a 2-year redesign of a legacy product, achieving immediate
adoption among large clients and 75–80% adoption overall,
improving a merchant experience that processes millions of
dollars annually
Served as de facto product lead in the absence of a dedicated
PM, driving research, communications, and product direction with
the engineering manager
Unified information architecture across Braintree docs,
marketing site, and new GraphQL docs, strengthening the
connection between Braintree and parent company PayPal's
positioning
Creative Developer
Software for Good
January 2014 to January 2015
Built frontend experiences using HTML, CSS, and JavaScript,
partnering with clients to deliver user-centered solutions
Provided design support for clients without in-house designers,
running the process from concept through launch
Designer
Swayspace
August 2008 to August 2013
Designed and built websites and applications for banking and
other enterprise clients, managing stakeholder relationships end
to end
Delivered a wide range of design work: branding, advertising,
web, and print across a diverse client base
Ran letterpress shop production and operations alongside client
design work, from concept through final print delivery
A Handful of Tasters
A space for experiments, not full case studies, ongoing and
unfinished by design. Right now that means three parallel threads:
building a card game app with Claude Code, stress-testing a real
design system as an AI skill, and chasing a specific art direction
across different AI design tools. Different questions, same
underlying curiosity: where AI genuinely helps design and
development work, and where it still falls short.
Cards with Friends
An app for playing card games remotely, built with React and
Supabase using Claude Code. The real goal is flexibility: getting
as close as possible to what a physical deck of cards can do,
where you can play any game and bend the edit rules on the fly.
Long term, the idea is to configure entirely new games through
prompting, not hard-coded rule sets. (Deck illustrations are their
own case study, see Standard American Playing Cards case study.)
Addressing game mechanics, rules and rule changing
Improve aesthetics, less clunky UI
Building this is as much about practicing a working relationship
with an AI coding tool as it is about the app itself. I want to
stay in the driver's seat rather than defaulting to "yes,
install this for me" on every prompt. If it's a command I
already know, I type it myself instead of auto-accepting. When
it comes to things like environment secrets, I ask it to walk me
through how they actually work and what could go wrong if I get
them wrong, rather than treating them as a black box to trust.
Along the way I'm picking up real working knowledge I didn't
have before: how YAML files and deployment jobs fit together,
and a much better grasp of working with databases. Small habits,
but the kind that keep me actually learning instead of just
shipping.
BPO Manager Clickable Prototype
A prototype built after wrapping up my work at Assembled, using
real production files and the actual design system to test
something I don't always get to fully explore: building a design
system into a working "skill" for AI tools, and seeing how far
that can go with real product complexity. Less about the original
design decisions (covered in the case study here), more about
probing the edges of what AI can and can't do inside actual design
work.
This project is less about changing how I work and more about
mapping where AI tools are actually useful in design work versus
where they still fall short. Lightweight, mechanical tasks work
well: randomizing values, matching up math, small time-saving
cleanup. Anything requiring nuance is harder. Asking for a
single line to be added or removed often takes several attempts
to land right, and getting good results depends on how
thoroughly the design system states are already fleshed out. The
more specific and well-defined the system, the better the
output. A big part of this is learning how to actually describe
design changes in a way the tool can act on accurately, which is
turning out to be its own skill worth building.
Portfolio Art Direction
A separate design exploration for this same portfolio content,
testing four different AI design tools against one specific
reference: Japanese commercial art from the 1920s and 30s.
Minimal, deco, patterned, duotone, asymmetrical but balanced,
mixing organic and geometric shapes with a playful color sense.
The question isn't whether these tools can build a portfolio site,
it's whether any of them can actually interpret a specific,
unusual aesthetic rather than defaulting to their own.
Tooling
Claude Code
Claude Design
Figma Make
Loveable
Status
Initial passes, 2-3 rounds on each system
Moving most promising options forward, pushing towards
uniqueness
Capture screenshots, create gallery
Claude Design and Figma Make struggle out of the box, and
several rounds of prompting later, the results are still far
from the reference. Neither seems to genuinely interpret the
source material so much as apply a generic layer on top of a
standard layout. Claude Code takes a different approach,
building out a moodboard before executing, which helps early
on, but it still struggles with simple pattern requests once
it gets to actual execution. Lovable comes closest on pure
design sensibility, offering pre-built directions that are
noticeably more informed by the reference, including theming
and placeholder copy that pick up on the source material in
ways I didn't expect. But it struggles more with actually
building out the execution.
None of the four have produced anything finished or shippable
yet, and none break meaningfully away from a fairly standard
portfolio layout, though Lovable gets closest. The real
finding isn't which tool "wins," it's where each one's
interpretation breaks down: some tools are better at
surface-level styling, some are better at structural building,
and almost none are good at both when the aesthetic target is
specific and unfamiliar to them.
AI makes it easy to produce more work, faster. It's much harder to
make that work meaningfully better. The difference comes down to
editing: knowing what's actually worth keeping. But you can't edit
well without reading and writing well first, reading closely enough
to know what a tool actually did, writing precisely enough to give
it real intent to work from. Anyone can generate more. Fewer know
what to do with it.
Drop-in: Case Study
Drop-In UI had been around for years, but by the time it landed on
our team it had no clear owner. As Braintree had grown, the
product had drifted between teams without a permanent home, and it
showed. It was dated, visibly rough in places, and we didn't fully
understand how badly it was failing users until we started doing
the research.
Our team inherited it because we had the right combination of
resources: a focus on developer experience, the ability to work
across both web and mobile, and a natural connection to
documentation, since Drop-In was often a developer's first real
introduction to Braintree. What started as a redesign project
quickly became something larger. My co-designer left partway
through, there was no dedicated PM, and I stepped into the lead
role, taking on both design and product responsibilities across a
two year project that would turn out to be one of my most
formative experiences as a designer.
Responsibilities
Lead designer
Product planning
User research
Design work
PM duties
Production CSS
Product rollout
Team
3 Designers
6 Engineers
Engineering manager
Head of Developer Experience
PayPal UX Research Lab
PMM and marketing
Product Impact
Drop-In UI continued processing millions in revenue annually
Existing clients upgraded and were instantly able to accept
multiple new payment methods
Improved user workflow, accessibility, and eliminated
previous confusion
Allowed mobile apps to take advantage of easy, secure
payment acceptance
Still. In. Use. (9 years later!)
The original Drop-in was an isolated iframe that merchants could
include on their website as a snippet of code, with a bit of
integration. It was a product meant to have a low bar for entry
which would allow merchants to accept payments easily while not
having to go through a lengthy compliance process, and included both
a web and mobile version.
This was great for merchants, but for Drop-in users, the interface
for Drop-in was fairly confusing. There were no clear input borders
and the design was pretty opinionated, it didn't always mesh with
Merchant's websites. Some Merchants were even sending out annotated
screenshots to their customers explaining how to pay.
Before any design work began, we had to answer a more fundamental
question: was this product worth saving? Drop-In had a legitimate
competitor within Braintree's own ecosystem. Hosted Fields served a
similar purpose but scoped specifically to the credit card input
rather than the full widget, and the argument for sunsetting Drop-In
in its favor was reasonable.
We interviewed clients who had reported usability issues, ran
competitive analysis, and pulled usage data. What we found surprised
everyone. Drop-In was processing millions of dollars in transactions
monthly, and product marketing had research showing real brand name
recognition among merchants. A product doing that much business with
that many usability problems was low hanging fruit. The decision to
redesign rather than sunset wasn't mine alone, but the evidence made
it clear: the question became what it could be, not whether it
should exist.
Due to timelines and engineer availability, we chose to refresh the
mobile version of Drop-in first. The issues with the mobile version
were fairly straightforward, we needed mainly to clean a few
usability issues up and also accommodate more payment method
options.
After lots of testing of different layouts and styling, we settled
relatively quickly on something that fit with existing iOS and
Android system styles. We then spent time to refresh the credit card
form and built a custom keyboard for expiration date input.
We ran the mobile version through more usability testing and
prepared the mobile version for release.
While the mobile redesign clipped along at a fairly quick pace and
was pretty straightforward in terms of design decisions, when it
came to tackling the web version, the story was quite different.
I spent the initial sketch phase working on the issues of usability
with the first version, and also on the scaling problem that had by
this time become more urgent. ApplePay, VisaCheckout, and GooglePay
had all recently launched and merchants wanted to easily accept
whatever methods were available.
We settled on a fancy customized dropdown as the main design
direction. This was in order to minimize the space on the Merchant's
checkout and be less of an obtrusive element on the page. There were
two main directions we tested, one that was a two step process and
another that could be a one step process.
The two step process had the advantage of funneling the user down a
path and removing distraction, and the single step process had the
advantage of speed.
Between user testing and speaking with the consumer group at PayPal,
we found that though usability wise there were no issues with the
dropdown, there were other considerations that would affect the
design. There was a cognitive cost for a user to open a dropdown,
not knowing what is under it and needing to parse out that
information.
So, we stepped back and did a little loop into some earlier sketches
that were based more on a radio/accordion selection process. We
re-used the idea of funneling the user down a path for clarity from
the dropdown approach, but refined it so that Drop-in now behaved
more like an isolated widget all to itself.
Then, we tested the shit out of that version. We built a little fake
store with all the directions in them and ran users through
different flows getting them to complete checkouts in various ways
to make sure there were no issues.
We also did what we could to prep Drop-in for as many possible
situations, including a mobile-web version for small screens or
spaces, and dialed in assets that would be served by Braintree.
Throughout all this, we were busy refining, refining, refining. The
aesthetic got closer and closer to something that was both modern
but generic enough to sit on a wide range of pages, and after all
the detailing down to making it IE9 compatible were tightened up, we
were ready for release.
Finally, we hit release after all the perfecting. There was so much
more to this than just pushing the code, we needed to create assets
and documentation for the new version, tutorials and work with
marketing to adjust the website, not to mention communicate to
account managers the need for Merchants to upgrade their versions,
no small task.
We got Merchants processing millions of dollars to upgrade, and most
of our top selling Drop-in Merchants updated to the 2.0 version.
Since release, even more payment methods have been added, and
Drop-in handles that scaling beautifully.
The redesign touched every part of the product, took two years, and
landed without a dedicated PM or a full design team behind it.
Stepping into the lead role mid-project, learning as I went, and
carrying both design and product responsibilities across that
timeline was the kind of experience that doesn't show up cleanly in
a case study but shapes how you work for years afterward.
What did show up cleanly was the outcome. Merchants processing
millions of dollars upgraded. The product scaled seamlessly as new
payment methods came out in the years that followed, which was
exactly what we had designed it to do. A product that had been
neglected and nearly sunset became one that merchants relied on and
that Braintree could build on.
The real proof of scaling and longevity came in 2025 when I went to
buy Girl Scout cookies online and found myself checking out through
my old friend, Drop-In UI. Nine years after we shipped it, new
payment methods and all, it was still doing exactly what we designed
it to do.
BPO Manager: Case Study
Business Process Outsourcing, or BPO(s), is how many large
companies handle customer support at scale. Rather than hiring and
managing support agents directly, they contract third party
providers who staff, train, and run support operations on their
behalf. For workforce management tools like Assembled, this
created a significant gap: the product was built around direct
teams, and had no way to account for the complexity of managing
vendors, capacity, and performance across multiple external
organizations.
This was Assembled's first expansion beyond its core product, and
the first tool of its kind in the workforce management space.
Responsibilities
Lead designer
User research
Design work
Herding cats
Production CSS
Client collaboration
Product rollout
Team
PM
6–8 Engineers
SME
Account manager
PMM
Many, many client stakeholders
Product Impact
Maintained churn-risk Stripe as a major client, strengthened
relationship
Onboarded Robinhood and expanded product capabilities
Onboarded new clients and upsold existing ones
Helped land 1M Salesforce contract as proof of concept for
co-developing with clients
The project was already partially in progress when I joined. A PM
and engineering manager had been working through a churn risk with
Stripe, one of Assembled's largest clients, and I was pulled in to
start sketching wireframes for a product I'd never heard of. No
brief, no background, just a relationship on the line and a problem
that needed a shape.
Stripe was managing their BPO vendors entirely through spreadsheets,
and it wasn't working. The complexity of tracking capacity, hour
commitments, and vendor performance across multiple third party
providers had outgrown what a spreadsheet could handle. We saw an
opportunity to mitigate the relationship risk and propose something
more substantial: a product that would give Stripe a real system for
managing their BPOs, and one that didn't exist anywhere else in the
workforce management space.
After pitching the idea to Stripe of collaborating on a new product
for managing BPOs, we realized we needed to back up and really get a
team and data sorted. We set out for Ireland to meet with the users
and SMEs to really understand their process.
It turned out that everyone had a slightly different understanding
of how the BPO process worked, so I got everyone in a room with
post-its to figure out exactly what the end-to-end workflow was. The
result was a big and complicated diagram that served as a touchpoint
throughout the project.
Once we returned from Ireland, I jumped into design mode. Working
from both the new flow diagram and some requirements we'd gathered,
I started roughing out the layout for what we began calling the
Vendor Management Product. I used a storytelling technique to refine
the requirements and create a bridge between text and design to get
a more detailed view of functionality.
The idea of the product was to create a single source of truth for
client and vendor. This would allow them each to request a certain
amount of work and commit to a certain hour of work, therefore
providing a transparency and history that could be billed/negotiated
on later.
There was quite a bit of iteration in this phase. There were many
new concepts that needed to be fit into our existing product in
order to replace Stripes spreadsheets. Simple seeming things like
having a time breakdown of being able to view months and weeks
quickly exposed complications of concepts, is a month 30 days or
does it vary or is it 4 weeks? 5 weeks? 6 weeks?
The alpha never got much traction. We followed up with Stripe, sat
through several rounds of meetings, and dug into usage data. What we
had to reckon with was that the alpha hadn't failed because of
execution. It had failed because we had built the wrong thing.
We had never actually gotten to the people using it. Getting direct
access required pushing through real resistance from the client, but
once we got there the problem was immediate and clarifying. The
original requirements had been dictated by the client, and we had
made the mistake of trying to replicate their spreadsheets rather
than rethinking the problem holistically. The end users revealed
that gap directly: they kept asking whether the product showed data
that had never been in the requirements, because the requirements
had never reflected what they actually needed.
What they actually needed was a dynamic picture of their data: the
ability to zoom out and see patterns, zoom in to investigate
specifics, and pull from multiple data sources to get a complete
view. We walked Stripe through everything we had found before
proposing the change, then threw out the design and rebuilt from
that foundation.
With this new take on the data, I built out a vertically scalable
data view that focused on data density and flexibility.
The Beta release proved much more successful, and this time we got
much more feedback for refinement around the product, which went
into the General Availability release.
In parallel with development with Stripe, we had also partnered with
Robinhood to fill out different aspects of the product to make it a
marketable standalone product, and to develop future features.
The BPO Manager launched to GA in six months. For a single designer,
that meant carrying the full design process alongside significant PM
responsibilities, adapting to a mid-project PM departure, finding an
entirely different way to communicate with an engineering lead who
required it, contributing to design system work, and shipping other
product work in parallel. It was as much an exercise in
collaboration and interpersonal navigation as it was in design.
It was also Assembled's first real product launch, which meant the
team was figuring out go-to-market, market research, and client
onboarding largely for the first time together. The signal that it
had worked was simple: Stripe and Robinhood fully onboarded, and
people actually using the product. The Salesforce contract that
followed drove it home further, not just as a client win, but as
proof that companies wanted to actively partner with Assembled to
build. After everything it took to get there, that was an incredibly
validating win.
Design Stystem side dish
At Braintree, I
kickstarted the very first design system, but at Assembled I got to use all of those discussion lessons
learned. As the Chief Button Officer, I was often elbows deep in
component configuration in Figma. Working closely with other
designers and engineers, we were able to significantly move the
product aesthetic to a more modern direction, and at the same
time, create an organized, scalable, maintainable system.
Responsibilities
Designer
Organization
Grunt work
Accessibility
Auditing
Component building
Chief Button Officer
Team
3–4 Designers
2–3 UX Engineers
Head of Design
Product Impact
Organized and streamlined scalable design system
Created and maintained easy to use components for designers
and engineers that match 1:1
Helped standardize reliable color and typography systems
Created consistency for end product, less overhead for
designers, and faster implementation for engineers
Working on the design system at Assembled (Assemblage) was an
ongoing and iterative process. We had overarching goals regarding
consistency and working towards upgrading many legacy parts of the
product.
There was no real established color palette when I started at
Assembled, but over time we evolved the system to have a full
palette of primary and secondary colors, tested for accessiblity.
One of the biggest issues that we went through several rounds of
revision on was the backgrounds of each application theme, dark and
light.
Beyond color, I also worked on dialing in the typographic system.
There was a basic type system, but it didn't cover our needs, and it
wasn't quite scalable or flexible. I revised the system so that
designers had access to multiple different standard weights and
sizes and we upgraded to a variable version of the typeface.
Buttons are one of the most common components, but we had very
little consistency in the app around them. One of the first things I
did as a system audit to understand areas that needed work.
All the button work dovetailed with the color work, and each piece
informed the other. We wanted to move towards closer branded colors,
but also needed to maintain accessibility standards along with all
the different states of buttons.
As the system evolved, so did the actual Figma components. We were
able to continually update the system to the newest features in
Figma components, finally getting to a point where with Figma
variables we could create components that worked automatically in
both light and dark themes.
Once we had an established baseline for things, we had a lot of
upgrade work to do for the actual components themselves.
Assemblage came a long way in my time at Assembled. Initially, all
we had was a single page of inconsistent components, and in my time
there we moved from that to a robust Figma library that could handle
multiple themes, and a matching 1:1 code repository for developers
to copypasta. So much design is discussion based, and though I
pitched in a lot of grunt work to get a robust design system in
place, the conversation itself always informed the development of
the system.
Miscellaneous Sweets
I have completed two certificate courses for type design, and one
for calligraphy, along with many lettering and signpainting
workshops. Here are a few snippets of projects over the years.
American Standard Playing Cards was a two year personal project
that allowed me to flex my type, lettering, illustration, and
system design skills. I loved putting thoughtful details into
every piece of this small object, down to the stickers closing the
box.
Responsibilities
Solo designer
Conceptualization
Illustration
Custom lettering
Print production
Distribution
Team
Just me
Product Impact
Printed an offset run of 3,000 decks, donated most of them
to youth shelters in every state
Got some very nice thank you letters
Intangible? Immeasurable? Hard to measure what
representation means to someone who doesn't often see
themselves in other things
These cards started as a side project as I was learning to play
bridge at work lunches. I thought it would be really nice to create
some custom playing cards for our group, but I had no idea it would
morph into something so much bigger and more fraught.
I'm sure you've seen these before, just some generic playing cards.
I tried to think of how I could make mine unique, but what I started
to realize was just how pathetically Eurocentric the 'default' set
is.
Every project I do, I approach from a product angle. I spend a lot
of time conceptualizing and refining that concept, researching and
trying to figure out the core of the project, doesn't matter if it's
a deck of cards or a payment product.
I started to sketch with better representation in mind, and it got
complicated and confusing. I struggled with making them different
and obviously diverse, but at the same time trying to maintain the
"traditional" aesthetic, in order to serve as a straight
replacement, potentially without anyone really noticing.
Adding the patterns and coloring for each card and making them
consistent with one another, but still unique to each face card
required so many revisions and sheer willpower to keep going. I
iterated and iterated on the face cards and kept refining the
patterns. There's a lot of back and forth and trying things out,
testing things together and letting go of certain parts that just
don't work. As in my regular product design day job, I know through
iteration that each version will bring me closer to the aesthetic
that's in my mind.
I did a fair amount of design system creation, making a custom
typeface that included the suit pips and the numerals/letters. Every
deck needs the same consistency in its design system to work
together as a whole but still allow for easy differentiation.
Sometimes with a design system, I'll take an idea or a sketch like
this ace of spades, and the first sketch or idea will almost nearly
end up to be the final.
Then, the challenge becomes trying to get that idea to mesh well
with others and apply it to other areas of the product effectively
in order to grow the system and make a cohesive product.
There's always room for refinement and growth and one of the hardest
parts of design is knowing when something is really done.
There's a user interface for physical products, and when designing
for print that always needs to be taken into consideration. The way
things face or sit on a 3D object and considerations when designing
are not so different from anticipating user needs on a web form.
You can sure as hell bet when you go to print there's some damn user
testing and prototyping, too. In many ways, 'go to print' is so much
harder and irreversible than 'ship it'.
The same sort of detailing and thought goes into these decisions and
how interactions work whether it's the lettering on a deck of cards
box or the pixels on a credit card icon.
I aim for the same level of thought and care with any design I do,
regardless of the qualifier of graphic, UI/UX, product or who knows
what else they're gonna come up with next.
And, if you're curious, you can read a thing I wrote about the
struggle of it all, because writing is an invaluable design skill,
too.
The project began as a redesign exercise to make some cool new
cards, but ended as a philosophical design exercise that challenged
and used all my skills. I struggled with the concept quite a bit,
and though I completed them in 2020, the conversation they are
involved in feels even more applicable today.
Buy a deck!
