Skip to content
Est. 2011

Design & Experience

We design for the people who actually use it.

Every interface starts with the same question: who is this for, and what do they need to get done? From there we shape something the people you serve can actually use.

Trusted by public-good organizations

  • City of Arlington Virginia logo
  • Americares logo
  • Arlington Public Schools logo
  • City of Ashville logo
  • Bond Dealers of America logo
  • CVSA logo
  • DCHS logo
  • DrAxe.com logo
  • George Mason University logo
  • MACPAC logo
  • MedPac logo
  • Motorola logo
  • Military Womens Memorial logo
  • National Housing Conference logo
  • National Industries for the Blind logo
  • National Science Foundation logo
  • Oliff Law llogo
  • PRB logo
  • SFI logo
  • Wesley Seminary logo

Research

We learn the room before we move a thing.

Every project starts with the same question. Who is this for, and what do they actually do on a Tuesday morning. We sit with the program staff who run the site, the editors who keep it current, and the audiences who depend on it.

What it covers

Stakeholder and audience interviews, content audits, analytics review, and a competitive scan of the organizations doing similar work.

How we get there

Two to three weeks of structured conversations and desk research. Findings get synthesized into a single, readable brief your team can act on.

What it looks like

  • Research brief
  • Audience personas
  • Audit + analytics review
  • Competitor scan

Information architecture

People find what they need without thinking about it.

Someone arrives looking for one thing. A form, a deadline, a program they qualify for. Good structure gets them there in a few clicks, without ever making them stop to wonder where it lives. We shape the site around how your audience actually looks for things, not how the org chart is drawn.

What it covers

Sitemap design, content modeling, taxonomy work, URL strategy, and editorial roles. Shaped around how people search, so the path to what they need is the obvious one.

How we get there

We map what you have, draft what it could be, and pressure-test the structure with real people looking for real things. All before a single page gets designed.

What it looks like

  • Sitemap
  • Content model
  • Taxonomy + tagging plan
  • Editorial role map

Wireframes & prototypes

Where your digital world takes its first real shape.

Every key page and flow gets drafted in low fidelity, the rough working version of the site you can click through and react to. It is the clearest place to make decisions together, while the structure is still soft enough to move.

What it covers

Low-fidelity wireframes for every primary template, clickable prototypes for the critical flows, and reviews built into the schedule. So feedback lands on the calendar instead of a Slack thread at 11pm.

How we get there

We work in real content from week one. Stakeholders see the site working before anyone argues about a shade of blue.

What it looks like

  • Low-fi wireframes
  • Clickable prototype
  • Annotated user flows
  • Review notes + sign-off

UI & design systems

Every piece of your digital world, built from the same set of rules.

Then the high-fidelity work begins. Typography, color, motion, components. The full visual language your site is built in, documented as a system instead of a stack of one-off pages.

What it covers

Type ramps, color tokens, spacing scales, component states, and motion specs. Delivered in Figma and in code, so the build follows one set of rules instead of drifting page to page.

How we get there

We start with the smallest pieces (tokens, primitives) and compose upward. Every screen in the site speaks the same alphabet.

What it looks like

  • Design tokens
  • Component library
  • Motion specs
  • Usage documentation

Accessibility

Accessible from the first sketch, not the final audit.

For the public-good organizations we serve, accessibility is not a compliance task tacked on at the end. WCAG 2.1 AA and Section 508 get designed in from the first sketch.

What it covers

Color and contrast systems, focus order, keyboard navigation, screen reader semantics, and assistive-tech testing. Validated against the standards your funders and audits actually require.

How we get there

Designers and developers work to the same checklist from day one. Audit week stops being a scramble. There is nothing left to scramble against.

What it looks like

  • Accessibility audit
  • Contrast + focus system
  • Screen-reader QA notes
  • VPAT-ready report

Let's talk

You're doing work that matters.
We'll handle the design side.

Start a Conversation