How the design partnership works on a Dock90 build

I don't do visual design. That surprises some people who come to me for a healthcare website, so I want to explain how design actually works on a build: who does it, how they're chosen, what I do with what they produce, and what it means for you.

Why doesn't Dock90 do design?

Because design and implementation are different skills, and the sites are better when each is done by someone who specializes in it.

I spent years on the design side before I moved to building. What I learned is that a designer who is also the developer makes design compromises to suit the code, and a developer who is also the designer makes code compromises to suit the design. Neither notices they're doing it. The person who specializes in visual design for healthcare will produce a better provider directory, a better condition page, and a better appointment flow than I will, and I'll implement it better than they would.

There's a second reason, which is focus. A healthcare site build has a lot of parts I do own: the content model, the migration, the compliance setup for forms and analytics, accessibility, performance, the CMS your team will use. Those are enough. Trying to also be the brand and visual design partner would make me worse at all of it.

So on every build there are two people: a designer and me. Here's how that pairing gets made.

Do you need to bring your own designer?

You can, and if you have one who knows your brand, you probably should.

Plenty of healthcare organizations have an in-house designer, a brand agency on retainer, or a freelancer they've worked with for years. If that's you, bring them. Nobody knows your brand better, and the relationship already exists. I'll work with them directly from the start of the project: I share the content model so their designs match the site's structure, they share their work as it develops so I can flag anything that will be hard to build or hard for your editors to maintain, and all three of us stay in the same channel for the length of the build.

What I need from your designer is page designs for each content type, the components those pages are made of, and the brand foundations (type, color, spacing) in a form I can turn into code. Figma is the usual tool. If your designer works differently, that's fine; I'd rather adapt to a good designer's process than force a bad one on them.

What if you don't have a designer?

Then I pair you with one I've shipped with before.

Over the years I've worked with a small number of designers who are good at healthcare specifically. They know that a patient-facing page has to be readable by someone who is anxious and on a phone, that accessibility is a requirement and not a style, that a referring physician wants credentials rather than marketing, and that a site has to be maintainable by an editor who isn't a designer. They've been through legal review of page copy. They've designed consent banners that compliance teams approve.

When I recommend a design partner, you contract with them directly and pay them directly. I don't mark up their work or take a cut. The reason for that is simple: you should be able to keep working with them after the build if you want to, without me in the middle.

I'll make the introduction, sit in on the first conversation, and tell you honestly whether I think it's a fit. That part matters. A designer can be excellent and still be wrong for your team.

How do you choose between designers?

The questions I'd ask are the same ones I ask before I recommend someone.

Have they worked on healthcare or life-sciences sites before? Not "have they done a medical brochure," but have they designed a site that patients use to find care, with a provider directory and a form that collects health information. Someone who's done it knows what's involved and won't spend your budget rediscovering it.

Can you see the work and talk to the client? A designer should be able to show two or three relevant projects and put you in touch with at least one of those clients. If every project is under NDA and there's no one to call, be cautious.

Do they specialize? A designer who does logos, print, packaging, and websites is usually fine at all of them and excellent at none. For a site, I want someone who designs sites. If you also need a brand refresh, that's often a second specialist, and it should happen before the site design starts rather than during it.

How do they bill? I prefer fixed price for the same reason I bill fixed price: you can budget for it and it forces scope to be agreed up front. If a designer bills hourly with no estimate, ask for a scoped proposal before committing.

Do you like working with them? You'll be reviewing their work every week for three or four months. Have a real conversation before signing anything, and pay attention to how they handle being questioned.

What does Dock90 do with the design?

I build it as a design system in code, which is different from building the pages.

When the designer delivers, what they've produced is a set of components: headings, buttons, cards, forms, navigation, page layouts. I implement each of those once, in code, with the accessibility requirements built in. Then every page on the site is assembled from those components, and every page your team creates in the CMS is assembled from them too.

This is what makes the site consistent and keeps it that way. An editor adding a new service line page can't produce something off-brand, because the only building blocks available are the ones the designer specified. Two years later, when nobody remembers the original design discussions, the site still looks like it was designed on purpose.

It also means design changes are cheap. If the designer updates the button style, I change it once and it changes everywhere. If you refresh the brand in a few years, the design system is the list of things that need updating, and it's a finite list.

How do the designer and Dock90 work together during the build?

In parallel, from the same content model, with a weekly rhythm.

The first month of a build is when the content model is finalized and the designer establishes the direction. They work from the model so the designs reflect what the site actually contains: a provider has these fields, a location has these, a condition page has a patient summary and a clinical summary. The designer isn't guessing at structure and I'm not guessing at layout.

In the second month, the designer delivers page designs and I implement them as they arrive. Your team reviews both, ideally in one pass per week with notes in one document. If a design decision creates a build problem or an editorial problem, I raise it with the designer directly and the two of us bring you a recommendation rather than a dispute.

By the time the site is on staging for sign-off, the designer has seen it built and signed off on the implementation. That's part of the milestone. I don't consider a page done until the person who designed it agrees it matches.

What does this mean for you?

You get a designer who specializes in design and a developer who specializes in building healthcare sites, and a process where the two are working from the same plan.

You pay the designer directly, so the relationship is yours. You get a site where every page is built from a consistent set of components, so your team can publish without a designer and the site stays on brand. And you get someone who will tell you honestly whether a design decision will cause problems for your editors or your compliance team before it's built rather than after.

If you're planning a healthcare site and wondering where design fits, the answer is: you bring one or I introduce one, and then I build what they hand over. The details of how a build runs, including the milestones the designer and I work to, are on the services page.