Pass 1 of 3 · Alison Blake — design

Alison Blake treats design as a decision log, not a decoration pass. She starts with language—what the company says in elevators, what it avoids saying on the record—then translates that into typography, color, and spatial rhythm. Her comps assume real copy, not Greeking, because Blake+DuCharme pitches with the same honesty the studio expects from clients.

In workshops, Alison is the person who redraws the whiteboard when the conversation drifts. She names tensions: premium vs. approachable, editorial vs. product-led, bold vs. institutional. Those tensions become axes in the system, not footnotes in a PDF. By the time engineering sees the file, the grid already knows how to behave when marketing adds a fourth module nobody planned for.

Interaction design under her direction feels calm. Buttons look clickable because hierarchy is clear, not because they glow like slot machines. Motion is choreographed in small loops—hover, focus, handoff—so Peter can implement with CSS first and JavaScript only when the behavior truly needs it.

She cares about photography the way editors care about ledes: crop, tone, and sequence either support the argument or they delete themselves. Blake+DuCharme often art-directs custom shoots rather than defaulting to stock libraries that make every SaaS site look like cousins at a reunion.

Accessibility shows up in Alison’s work as contrast choices you do not have to squint to approve, type scales that survive user font settings, and components that still make sense when translated into languages that run longer than English. She does not treat WCAG as a QA gate at the end; she treats it as part of taste.

Design QA, in her vocabulary, includes “does this still feel like the brand when the Wi-Fi is bad?” If the answer is no, the layout is not done. She will happily spend an hour tightening line breaks so a headline survives narrow viewports without orphaning its confidence.

When clients ask for “something cooler,” Alison asks what cool means for their audience—not for Dribbble. Sometimes the answer is restraint: fewer gradients, more whitespace, sharper photography. Sometimes it is play: a typographic moment, a scroll beat, a sound design sketch she knows Peter will budget realistically.

End of beat one—the sticky photograph beside this column should slide away left as you approach the next eyebrow, clearing the slot for a chapter about how Peter DuCharme turns these intentions into code that survives launch week.

Pass 2 of 3 · Peter DuCharme — engineering

Peter DuCharme writes the kind of code reviewers call “boring,” which is his favorite compliment. He prefers explicit modules, predictable data flow, and tests that fail loudly before a client ever sees a white screen. At Blake+DuCharme, engineering is not a translation layer from Figma to React; it is part of the creative argument about what is possible on the open web.

Performance budgets start early. Peter sizes images, subsets fonts, and argues for fewer third-party embeds with the same energy other people argue for brand colors. He ships Core Web Vitals improvements that never become slides because they are simply how the site behaves when nobody is demoing it on conference Wi-Fi.

Accessibility is implemented, not declared. Keyboard traps get fixed before launch, not after a Twitter thread. Focus rings are designed with Alison so they look intentional instead of like a browser default apology. Screen reader labels are written by humans who read them out loud and wince when they sound robotic.

Security and privacy show up in form validation, in how tokens are stored, in how analytics respect consent. Peter assumes attackers read documentation too, so he keeps dependencies lean and provenance clear. When Blake+DuCharme integrates a CMS, he thinks about editor roles, audit trails, and rollback paths—not just the happy path demo.

He likes Locomotive-style smooth scrolling in demos because it shows what careful motion can do; in production he pairs it with reduced-motion media queries and content that does not depend on scroll position to make sense. The agency’s reputation lives in those details.

Handoff to internal client teams includes README files people actually read: how to add a module, how to preview before publish, what to do when the build fails because someone pasted a 12-megabyte PNG from a phone. Peter would rather write that doc once than answer the same Slack at midnight six times.

Second beat complete; the third image inherits the sticky slot for a shorter chapter about how Blake+DuCharme behaves when the lights are on and the client is watching.

Pass 3 of 3 · Blake+DuCharme — the partnership

Blake+DuCharme is not a merger of two freelancers with a shared calendar. It is a studio model where design and engineering negotiate scope in the same room, on the same timeline, with the same definition of done. Alison brings the story; Peter brings the stack; the client gets a site that feels expensive because the details compound instead of fighting each other.

The agency’s culture is unsentimental about trends. If a pattern is everywhere, Blake+DuCharme asks whether it belongs on this brand—not whether it will win awards. Cool is allowed, but only when it clarifies positioning instead of distracting from it.

Retainers are framed as continuous improvement: analytics reviews, accessibility sweeps, performance budgets that evolve as traffic grows. The studio would rather tune typography after launch than vanish until the next redesign emergency—relationships over transactions, craft over churn.

When things go wrong—and they sometimes do—Blake+DuCharme communicates early, documents clearly, and fixes without blame theater. Alison updates the client on design tradeoffs; Peter updates them on technical tradeoffs; both sign the same postmortem with action items instead of excuses.

New business begins with fit. The studio turns down work that expects miracle timelines or unlimited free pitches, because that work would force corners that neither Alison nor Peter is willing to cut. They would rather be slightly harder to hire and much easier to trust.

Deliverables are packaged like a studio product: design tokens, component references, CMS schemas, deployment notes, and a short film of the scroll experience for stakeholders who will never open DevTools. Blake+DuCharme wants the client team to feel proud handing the site to the next hire—not anxious about which Slack channel holds the truth.

If you scrolled this third beat to the end, you have watched the paired-column demo do its job: three photographs, one sticky frame, each exit clearing space for the next entrance—same choreography Blake+DuCharme uses when a case study needs scope without losing the thread.

Three beats, three images, one sticky frame—each photo leaves left before the next arrives from the left, and the studio moves on to the next launch with the same rhythm.