Designing My Portfolio as a Scalable, Accessible Product
This work reflects how I operate as a Staff Product Designer and Design Engineer: defining constraints, making tradeoffs, and building systems that scale. My Role: Staff Product Designer / Design Engineer Scope: UX Strategy · Information Architecture · Design System · Accessibility · Frontend Collaboration
Problem
Traditional portfolios over-index on visual output. At senior levels, this fails to communicate decision quality, system ownership, or real-world constraints. Much of my recent work lives in regulated, enterprise, and security-sensitive environments where full visual disclosure isn’t possible due to NDAs and compliance requirements. At the same time, senior hiring decisions are rarely based on screens alone. Recruiters and hiring managers are evaluating how designers think, make tradeoffs, and operate within constraints — often in under two minutes. The challenge was to design a portfolio that clearly communicates judgment, systems thinking, and measurable impact, without relying on proprietary visuals.
Solution
• Enable reviewers to quickly evaluate my judgment, system thinking, and execution approach. • Make senior-level impact and decision-making scannable in under two minutes • Support multiple role paths: • Staff Product Designer • Design Engineer • Ensure accessibility, performance, and clarity across light and dark modes • Enable fast iteration as new work is added, without frequent redesigns
Constraints
NDA and security limitations on shipped enterprise work
Solo designer and builder
No marketing or content team
Limited time alongside client and full-time work
Needed to serve multiple audiences:
Recruiters
Hiring managers
Designers
Engineers
These constraints informed not only the content, but the structure, hierarchy, and interaction design of the site itself.
Key Design Decisions
This portfolio was designed by intentionally prioritizing decision quality, system clarity, and scalability over visual novelty. Each choice reflects how I operate in real product environments.
Minimal Interface Over Visual Expressiveness
I chose a restrained visual language with clear hierarchy, generous spacing, and typography-first layouts.
This meant intentionally deprioritizing visual flair, animation, and decorative elements in favor of:
Faster comprehension
Easier scanning for time-constrained reviewers
Stronger emphasis on written rationale and outcomes
Tradeoff accepted:
Reduced aesthetic expressiveness in exchange for clarity, credibility, and signal strength.
Why this matters:
At Staff and Lead levels, hiring decisions hinge on judgment, tradeoffs, and system ownership — not surface-level visuals.
Depth Over Volume in Case Studies
Rather than showcasing many projects with limited context, I focused on fewer case studies with deeper explanations of:
Constraints
Decision-making
System-level thinking
Measurable outcomes
Tradeoff accepted:
Less visual breadth in exchange for deeper insight into how I think and operate.
Why this matters:
Hiring managers evaluate whether a designer can operate in ambiguity and scale decisions, not how many screens they’ve produced.
Dark and Light Mode as First-Class System Features
The site supports both dark and light modes using a token-based color system. Contrast, readability, and hierarchy were tested across both modes and common viewing contexts (low light, glare, extended reading).
Tradeoff accepted:
Increased system complexity in exchange for accessibility, flexibility, and real-world usability.
Why this matters:
This mirrors how I collaborate with engineering teams — designing systems that maintain parity between design intent and implementation while supporting accessibility and theming at scale.
NDA-Safe Abstraction as a Design Constraint
Given the security and compliance requirements of much of my work, I avoided showing proprietary UI or data. Instead, I abstracted visuals and focused on:
Systems
Workflows
Decision rationale
Outcomes
Tradeoff accepted:
Reduced pixel fidelity in exchange for protecting client trust and demonstrating transferable leadership skills.
Why this matters:
Systems, judgment, and outcomes scale across organizations — proprietary UI does not.
Designing the Portfolio as a Composable System
I structured the site as a small, composable system rather than a one-off artifact. Components, spacing, and hierarchy are consistent and reusable, allowing new case studies to be added without restructuring the site.
Tradeoff accepted:
Initial setup effort in exchange for long-term maintainability and faster iteration.
Why this matters:
This reflects how I approach product work: investing early in structure to reduce friction and cognitive load over time.
Summary
Each decision prioritizes clarity, scalability, and operational leverage — the same principles I apply when designing enterprise systems, design platforms, and cross-functional workflows.
