Inspired by Naum Gabo (opens in a new tab)
From the first question to the last release.
Discovery, design, development, QA and launch for digital products, with accessibility and the people using them as the starting point.
Human-centered design
Advocating for the people on the other side of the screen.
Good products come from organizations that keep their users in the room. Part of the work is making that case — to stakeholders, engineering teams and new designers — and building the habits that keep it true.
Start with people
Decisions come from the people who use the product — observed, asked and tested.
Design with, not for
Bring users, clients, engineers and subject experts to the table early, so the solution is shared before it ships.
Plain language
Say it simply. Clear words are an accessibility feature and a conversion feature.
Inclusive by default
Designed for the widest range of people: every age and ability, every device, every connection.
Evidence over assumption
Prototype, test, measure and change course when the evidence says so.
Teach the practice
Workshops, design reviews and mentoring, so human-centered design outlasts any one project.
Process
Seven phases, one thread.
-
A shared picture of the problem, the people and the plan, before anything is designed.
- Stakeholder interviews
- User research
- Analytics review
- Heuristic and competitive audits
- Accessibility audit
- Project brief
- Schedule and releases defined
-
How the product works, tested with the people who will use it while changes are still cheap.
- Information architecture
- User flows
- Wireframes
- Keyboard and screen-reader flows
- Clickable prototypes
- Usability testing
-
A look that holds together, built from tokens and components that design and code share.
- Visual design
- Contrast-checked design tokens
- Accessible component libraries
- Figma ↔︎ code parity
- Documentation
-
How it moves and responds, specified so engineering builds it as designed.
- Interaction specs
- Focus and state design
- Micro-interactions
- Motion design
- Prototypes in code
- Reduced-motion variants
-
Work engineering can estimate and build, with what “done” means written down.
- Engineering user stories
- Acceptance criteria
- Edge and error states
- Accessibility requirements
- Backlog refinement
-
What ships matches the design, works in every browser and passes accessibility checks.
- Development
- Design QA
- Accessibility testing: automated and manual
- Cross-browser testing
- Debugging
- Performance
- Core Web Vitals
-
A launch with a plan, then measurement, refinement and support after it.
- Release planning
- Analytics
- SEO
- Accessibility monitoring
- Iteration
- Ongoing support
Accessibility
Public means everyone.
Accessibility starts in design, not as a fix after an audit — on every screen, from the smallest phone to the widest display. For government, healthcare and education, that means meeting the law; for everyone else, it means not turning customers away.
- Semantic structureReal headings, landmarks and labels, so assistive technology reads the page the way it looks.
- Keyboard and focusEverything reachable and operable without a mouse, with a focus state you can always see.
- Contrast, measuredText and controls measured against WCAG ratios, not judged by eye.
- Screen reader testingFlows walked through with screen readers before release, not after a complaint.
- Motion and mediaReduced-motion alternatives, a pause on every animation and nothing that flashes.
- Video captions and descriptionsSynced captions, a transcript that follows along and a description of what’s on-screen, for every video. On MIT’s Media Literacy module, 13 videos were captioned with a Whisper-based tool, then proofread line by line.
- Audits and remediationAutomated scans plus manual review, prioritized fixes and documentation that supports a VPAT / ACR.
98.8
Siteimprove WCAG AA score on the Labor History Resource Project for Georgetown University.
AA
WCAG 2.2, the level every project is designed, built and tested to.
Working together
How an engagement runs.
It starts with a conversation
About the product, the people using it and what stands in their way, before any scope or schedule is written.
Inside your team, or end to end
Alongside your product and engineering teams, or taking a site from first sketch to launch.
Phased, with something to see
Each phase ends in work you can review: research findings, prototypes, designs, stories, a build.
Yours to keep
Figma files and design systems, code, documentation and stories with acceptance criteria, ready for the team that carries the work on.
