Project File / 13 / Client product work
The handoff disappeared because I stayed in the build
Mobile and web product work for a platform serving more than 1 million people, with product design, UI systems, and frontend delivery treated as one job.
Most portfolio case studies stop at a Figma prototype. My work on Tallo does not. I design product surfaces and stay close enough to implementation that responsive behavior, component states, and accessibility decisions can survive release.
Tallo connects more than 1 million students and early-career users with colleges, scholarships, and employers. At that scale, a small interface decision can travel across devices, audiences, and product teams. The useful work is not only making one screen look right. It is making the next screen easier to get right too.
13.01
The job spans design and frontend
I turn product requirements into Figma prototypes, interaction specifications, edge-state decisions, and production interface work. The work crosses responsive web, iOS, and Android surfaces, so a decision has to survive more than one ideal viewport.
Staying involved through implementation changes the quality of the design conversation. Layout behavior, empty states, content pressure, accessibility, and the awkward middle widths are resolved as product decisions instead of being discovered after handoff.
Operating modelDesign the behavior, then stay until the released interface still has it.
13.02
Scale makes consistency a product problem
A platform serving more than 1 million people cannot treat every new flow as an isolated composition. Reusable components, shared states, and clear interaction rules reduce the amount of product judgment each team has to recreate from scratch.
My contribution includes component and design-system work across mobile and web. The goal is not a library that looks complete in a file. It is a set of patterns that stays useful when real content, responsive layouts, and edge cases arrive.
13.03
The component is not finished when the variant exists
A reusable pattern needs more than a default state. It needs focus, error, loading, disabled, long-content, small-screen, and accessibility behavior that engineering can actually ship. That is where frontend fluency becomes product-design leverage rather than a separate specialty.
Working directly with product managers, engineers, and stakeholders keeps tradeoffs visible. The design can become simpler when the implementation cost is real, and the implementation can become better when the intended hierarchy is explicit.
System testA pattern is real when another surface can use it without reopening the original debate.
13.04
This project file is intentionally incomplete
Tallo is active client work. This public file does not disclose unreleased features, roadmap details, internal metrics, private user information, or confidential team decisions. The screenshots and facts here stay inside what is already public and what I can truthfully describe about my role.
That boundary is part of the proof. Good product work requires judgment about what to reveal as much as judgment about what to build. The public signal is the operating range: product design, UI systems, mobile and web implementation, accessibility, and delivery at meaningful scale.
What survived
Three things I would carry into the next build
- Staying close to implementation removes handoff as a common failure point.
- A design system is shared behavior, not a shelf of polished components.
- Client proof can be specific about the work without exposing confidential product details.