Design that ships as real code, not a picture we hand over a wall
UX design, interface and visual design, and the graphics around them, for U.S. businesses. Because the same studio designs and builds your site, the design is not a mockup someone else has to rebuild. The type scale, the color tokens, the spacing, and the states carry straight through into accessible, fast production code. No broken handoff, nothing lost in translation.
# the design tokens, also the code
:root { --text-primary: #1c1a17; --surface: #faf6ef; --action: #1E3A66; --contrast: "AA, 4.5:1"; --owned-by: "you"; }
We are design and build, not just code
It is easy to find a studio that writes good code and treats design as something someone else hands over. We do both. Design here is not decoration applied at the end. It is the work of deciding how the site is structured, how a person moves through it, how it looks and reads, and how every piece holds together, and then carrying all of that faithfully into the thing that actually goes live.
The reason this matters is the handoff. In the usual arrangement a designer produces a polished file, a developer rebuilds it from scratch, and the version that ships is a rough copy of the mockup with the spacing slightly off, a few states missing, and the accessibility quietly dropped. When one studio designs and builds, there is no wall to throw the work over. The design becomes the real coded interface, with the color, type, spacing, and interaction states carried through intact.
This page covers three layers of that work. UX design, which is how the thing works. UI and visual design, which is how it looks and feels. And graphics, which is the supporting visual material, the logo and brand basics, the website graphics, the icons and favicons. On a build we handle all three, so the result reads as one coherent product rather than three teams stitched together at the seams.
And because we also write the code, accessibility and performance are design constraints from the first decision, not a cleanup pass after launch. A design that cannot meet contrast requirements, or that would force a slow, heavy page, is a design problem we catch on the canvas, not a surprise the developer inherits.
// the drawing and the build are the same hand
What sets this apart
- One studio designs and builds, so nothing is lost in the handoff
- WCAG 2.2 AA accessibility designed in, not remediated later
- The design system is the same tokens running in the live code
- Performance treated as a design constraint from the start
- You own the source files, the graphics, and the system
Three layers of design, handled by one studio
UX, UI, and graphics are three parts of the same job. Here is what each covers on a typical build, and they ship together so the finished site reads as one coherent thing.
UX design · how it works
- Research-lite: analytics review, competitor flows, journey mapping
- User flows for the paths that matter, like quote or checkout
- Information architecture and a sitemap you sign off
- Low-fidelity wireframes to settle layout before any visuals
- Interactive prototypes for the flows worth testing
- Usability review, with formal testing scoped when it earns its keep
UI & visual design · how it looks
- A design system of color, type, and spacing tokens
- A component library reused across every page
- Accessible color and type meeting WCAG 2.2 AA contrast
- Every interaction state designed: hover, focus, active, disabled, error
- High-fidelity mockups in the views that matter, desktop and phone
- Tokens handed to the build as the values the code runs on
Graphics · the visual layer
- A logo, or a cleanup of the one you have, with the lockups a site needs
- Brand basics: a color, type, and spacing system tied to the build
- Custom hero and section graphics in one coordinated style
- An icon set drawn to match, not pulled from three libraries
- Favicons and app icons sized for every surface
- All source files handed over with the rest of the project
Design the structure and the flow before the surface
UX is the part most sites skip, and it is the part that decides whether the site works. Before a single color is chosen, we settle what each page is for, how someone gets from where they land to what you want them to do, and where the friction sits in that path. A beautiful page that does not know its job will not convert, so we map the job first.
For most small and mid-size businesses this is research-lite by design. We read what your analytics and current site already tell us, look at how competitors handle the same flows, and map the few journeys that genuinely matter rather than running a research program a five-page site does not need. Then we work from low-fidelity wireframes in grayscale, which keep everyone arguing about structure and content instead of getting distracted by color, and only raise the fidelity once the layout is right.
When a flow is important enough to justify it, we prototype it and test it. The research is consistent here: testing with about five people per round surfaces the large majority of usability problems, and several small rounds beat one big study, because you fix what you find and test again. We scope formal testing when a checkout or a portal flow earns it, and we are honest when a project does not.
The UX deliverables
- A short, honest research read, not a research project
- User flows for the journeys that decide the outcome
- Information architecture and an approved sitemap
- Grayscale wireframes that settle layout first
- Clickable prototypes for the flows worth testing
- Usability findings written in plain language you can act on
A design system, not a pile of one-off screens
Visual design here means building a system, not decorating pages one at a time. The foundation is a set of design tokens, the named, reusable values for color, type, and spacing that every component draws from. We work the way mature design systems do, with a layer of raw primitive values underneath and a layer of semantic tokens on top, naming colors by their job, like text-primary or action, rather than by their hue. That sounds like a detail, and it is the detail that keeps a site consistent and lets you restyle it later without hunting through a hundred screens.
Accessibility lives in those tokens. We choose color and type to meet WCAG 2.2 AA contrast from the start, 4.5 to 1 for normal text and 3 to 1 for large text and interface elements, so a non-compliant combination is something the system makes hard to create rather than something an audit catches after launch. Designing accessibility in is far cheaper than remediating it, and it is one of the clearest advantages of a studio that designs and builds in one place.
On top of the tokens sits a component library, the buttons, cards, forms, navigation, and accordions reused across the site, each with every state designed: the hover, the focus ring, the active, the disabled, the error. We deliver high-fidelity mockups in the two views that actually matter, desktop and a mid-size phone, with real copy beside the design so the headings and buttons are judged together. Then those same tokens and components become the code, which is the next layer.
The system we build
- Primitive and semantic design tokens, named by purpose
- A color and type scale that meets WCAG 2.2 AA contrast
- A reusable component library, every state designed
- Mobile-first layouts tested at real breakpoints
- High-fidelity mockups with real copy, desktop and phone
- The tokens documented as the values the live code uses
The visual layer that makes a site look finished
A site built well but dressed half-finished still loses people, so we handle the visual layer for the projects we build. This is the work that used to live under brand and visuals, now folded into design: the logo, the brand basics, the website graphics, the icons, and the favicons, all drawn from one set of color, type, and spacing tokens so every page reads as the same company.
If you already have a brand system, we work inside it. If you have a partial one, a logo but no real rules, we tighten it into something a site can use. If you have nothing, we set up a working system for the build and write it down so you can reuse it later. Either way the graphics are coordinated rather than collected, the icons drawn to match instead of pulled from three different libraries, and the section art built in one style rather than stitched from stock.
This is a supporting part of the web work, enough that your site launches looking like it belongs to you and no one else. It is not a full standalone brand identity engagement, and when a project genuinely needs that larger scope we will tell you plainly where our part ends.
What is included
- A logo, or a cleanup, with the lockups and exports a site needs
- Brand basics: color, type, and spacing tied to the build
- Custom hero and section graphics in one coordinated style
- An icon set drawn to match the rest of the design
- Favicons and app icons sized for every surface
- Source files handed over with the rest of the project
Structure, then surface, then the same hand builds it
The design moves in the same order every time, lowest fidelity first, and the build is not a separate phase thrown to another team. The hand that drew it inscribes it.
// no wall, no rebuild, no drift
- Understand and mapWe read your analytics and your current site, look at how competitors solve the same flows, and map the user journeys that decide the outcome. The deliverable is a plain brief on what each page is for and who it is for, agreed before any design begins.
- Wireframe in grayscaleLow-fidelity, no styling, so the conversation stays on structure and content instead of color. This is where duplicate pages get cut, missing ones get added, and the layout is settled before a single visual decision is made.
- Build the system, then the screensWe define the design tokens and the component library first, color, type, spacing, and every interaction state, with WCAG 2.2 AA contrast baked in. Then the high-fidelity mockups assemble from that system rather than being drawn one off at a time.
- Prototype and checkFor the flows that warrant it we build a clickable prototype and put it in front of real people, a handful per round, fixing what we find and testing again. We scope formal usability testing where it earns its keep and say so when a project does not need it.
- Inscribe it as codeThe same studio turns the design into the live, accessible, performant site. The tokens become CSS custom properties, the components become real markup, and the states ship as designed. Nothing is rebuilt from a picture, so nothing drifts from the design.
Design questions, answered plainly
The rest of the Web Development tablet
Design is one part of the build. These are the other Web Development services it sits beside, and the hub that ties them together.
Want design that survives the handoff because there is no handoff?
Tell us about the site you are planning or the one that is not working. You will hear back from the senior person who would design and build it, with a straight read on what it needs and what it does not.