Creative Website & Product Design

Information architecture is the invisible skeleton of a site or product — how content and features are grouped, labeled, and connected — and it's the single most common source of a site that looks polished but feels confusing to actually use. Before any visual design, I map the full content and feature set, group it the way users would look for it (not the way the org chart is structured internally, which is a very common and very avoidable mistake), and test that structure against real tasks: can someone find pricing in under two clicks, can they figure out which service applies to them, can they locate the one page that answers their specific question.

For content-heavy sites, this includes deciding what actually deserves its own page versus what should live as a section within a broader page — a decision that affects both usability and SEO, since search engines also rely on a site's structure to understand what it's about and how pages relate to each other. A flat structure with everything crammed onto a handful of pages is hard to navigate and hard to rank for specific search terms; an overly fragmented structure with dozens of thin pages dilutes authority and confuses visitors about where they actually are in the site.

Navigation labeling gets more attention than it might seem to deserve, because ambiguous labels are one of the most common reasons visitors give up and leave rather than dig further. "Solutions" means something different to every visitor unless the surrounding context makes it specific. I test labels against how real users describe their own problem, not against internal terminology the business is used to — a distinction that sounds small and consistently turns out to matter a great deal once real visitors are watched trying to use the resulting navigation.

Wireframes exist to separate structural decisions from visual ones, so that layout, hierarchy, and flow can be argued about and fixed before typography and color are even on the table. A wireframe stripped of visual polish forces a harder, more honest conversation: does this page actually communicate what it needs to, in the order it needs to, without the visual design distracting from whether the underlying structure works. Reviewing a fully designed comp for structural problems is much harder, because a beautiful treatment tends to mask a structural issue until real users hit it.

For anything with meaningful interaction — a multi-step flow, a dashboard, an app with real navigation logic — I build a clickable prototype before development starts, because a static wireframe can't reveal the problems that only show up when someone actually tries to move through a flow: a step that assumes information the user doesn't have yet, a dead end with no clear next action, a form that asks for something in the wrong order relative to how a person naturally thinks through the task. Catching those problems in a prototype costs an afternoon of rework; catching them after development costs a sprint.

Where the budget and timeline support it, I test prototypes with a small number of real or representative users before finalizing visual design — not a formal usability lab, just five or six people attempting a specific task while I watch where they hesitate. This consistently surfaces at least one assumption that felt obvious internally and turned out not to be obvious at all to someone encountering it fresh, which is exactly the kind of blind spot that's cheap to fix at this stage and expensive to discover after launch through declining conversion numbers nobody can immediately explain.

Prototypes also become the artifact stakeholders actually engage with meaningfully. A static comp reviewed on a screen share tends to draw comments about color and font choice, because those are the easiest things to have an opinion about at a glance. A clickable prototype, worked through as if it were the real thing, draws comments about whether the flow itself makes sense — which is the feedback that actually matters most at this stage, and the reason I push for prototype review over static-comp review whenever the project and timeline allow it.

Visual design is where structure becomes a specific, distinctive look — typography, color, spacing, imagery, motion — but the job isn't to make something merely attractive; it's to make the important thing on each screen unmistakably the important thing, and to make the whole system feel like it was designed by one coherent hand rather than assembled from a component library with no unifying logic. That starts with a clear visual hierarchy: one primary action per screen, clear grouping so related things read as related, and enough restraint that the design doesn't compete with the content it's supposed to be presenting.

Brand identity work — when a project includes it — follows the same research-first logic as everything else: a mark and a visual language that fits the actual business and its actual audience, not a trend pulled from whatever's currently popular on design inspiration sites. I push back, respectfully but directly, on requests to chase a specific aesthetic purely because a competitor or an admired brand uses it, because a visual identity borrowed wholesale from someone else's positioning rarely fits the business wearing it, and it shows.

Restraint is consistently the harder skill to sell, because a client reviewing a design sometimes reads simplicity as "not enough was done," when in practice cutting three competing visual elements down to the one that actually needs attention is real design work, not a shortcut. I try to make the reasoning visible rather than asking for trust on faith — showing why a busier version tested worse, or why removing an element made the primary call-to-action noticeably more effective — because that reasoning is what actually earns the confidence to keep a design disciplined rather than let it slowly accumulate "just one more thing" until it's noisy again.

For any project beyond a handful of pages, I build a lightweight design system alongside the actual screens — a defined set of typography scales, color tokens, spacing rules, and reusable components (buttons, cards, form fields, navigation patterns) that get documented once and reused consistently rather than reinvented slightly differently on every new page. This isn't enterprise-scale design-system tooling for a five-page brochure site; it's a proportionate version of the same idea, sized to the actual project.

The payoff shows up later, not immediately: when a business needs a new page six months after launch, that page can be assembled from existing, tested components rather than requiring a fresh design pass and a fresh round of developer implementation. It also keeps the site visually consistent as different people touch it over time — a common source of a site that starts clean and gradually degrades into a mismatched pile of one-off styling decisions as different contributors add pages without a shared system to work from.

For product work specifically, a design system also becomes the shared language between design and engineering — a button component with defined states (default, hover, active, disabled, loading) means engineering doesn't have to guess at behavior that wasn't specified, and design doesn't have to redraw the same component from scratch for every new screen. That shared vocabulary is a large part of why design-to-development handoff on a system-based project moves faster and produces fewer "that's not quite what I meant" corrections than handoff on a project where every screen was designed in isolation.

A design system also protects against a subtler failure: a business hiring a second designer or agency for a later project who has no visibility into the original decisions and ends up quietly fighting the existing visual language instead of extending it. A documented system, even a light one, gives that next person a foundation to build on respectfully rather than a blank slate that invites a fresh, uncoordinated direction.

A design isn't finished when it looks right in a design tool — it's finished when a developer can build it accurately without needing to guess at spacing, states, breakpoints, or edge cases. That means every component gets specified with its responsive behavior, its interactive states, and how it degrades gracefully when content is longer or shorter than the ideal example shown in the mockup, because real content is rarely as tidy as the placeholder text used during design. A handoff that only shows the happy path forces a developer to make dozens of small judgment calls during implementation, and those judgment calls compound into a build that drifts from the intended design in ways that are individually minor and collectively noticeable.

Accessibility is specified at the design stage, not left for development to retrofit: color combinations checked against contrast requirements before they're locked in, focus states designed rather than left to a browser default that may or may not match the visual language, and interactive elements sized and spaced for real touch targets rather than a mouse-cursor-sized hit area that's difficult to tap accurately on a phone. Building this in during design is materially cheaper than discovering a contrast failure in a post-launch accessibility audit and having to rework a color system that's already shipped across the whole site.

Where I'm designing and building the same project myself, handoff friction mostly disappears — there's no interpretation gap between what was designed and what gets coded, because it's the same person making both sets of decisions with full context of the reasoning behind each one. Where I'm designing for another team's developers, I document decisions explicitly enough that the reasoning survives the handoff, not just the visual output — because a developer who understands why a design decision was made makes better judgment calls on the inevitable edge cases a static mockup didn't anticipate.

Not every design engagement starts from a blank page. A large share of the work I do is an audit of an existing site or product that isn't performing the way it should — conversion rate is flat, users are dropping off at a specific step, or a business simply suspects the design is holding them back but can't articulate exactly where. An audit is a structured, evidence-based review rather than a subjective opinion pass: I look at analytics where they exist, walk through the actual user journeys as a first-time visitor would experience them, check the interface against accessibility and usability heuristics, and identify the specific points where friction is most likely costing conversions or retention.

The output is a prioritized list, not a vague "this needs a refresh" verdict — specific findings tied to specific evidence, ranked by expected impact versus effort to fix, so a business can decide whether to address the top three issues with a focused update or commission a broader redesign once they understand the actual scope of the problem. I've had audits conclude that a full redesign wasn't warranted at all — that three specific, inexpensive fixes would recover most of the lost conversion — and I say that even when a full redesign would be the more lucrative outcome for me, because a client who trusts that recommendation is a client who comes back for the next project.

Where the audit does recommend a broader redesign, it becomes the brief for that project instead of starting research from zero — the findings already establish what's not working and why, which shortens the discovery phase considerably. This is one of the more underused entry points into working together: a business doesn't have to commit to a full redesign to get a professional, evidence-based read on what's actually wrong with their current site, and that smaller first engagement is often what builds the confidence to commission the larger project later, once the working relationship has already proven itself on something lower-stakes.

Design that's aware of business goals and design that manipulates visitors into a decision they wouldn't otherwise make are two very different things, and I draw that line deliberately. Conversion-aware design means removing unnecessary friction from a genuine decision — a form that only asks for information actually needed at that step, a pricing page that answers the objections a real buyer has instead of hiding them, a checkout flow with a visible, honest sense of progress instead of a scarcity countdown timer that resets on refresh. None of that requires deception; it requires understanding what a real visitor needs to know and removing the obstacles between them and a decision they were already inclined to make.

Dark patterns — a subscription that's deliberately hard to cancel, a pre-checked box that adds an unwanted item, a fake urgency banner — sometimes lift short-term conversion numbers and reliably cost a business more in the long run: chargebacks, refund requests, damaged trust, and increasingly, regulatory risk in markets that have started legislating against specific manipulative patterns. I won't design them, and I say that plainly to prospective clients who ask for them, because a design decision that only works while the visitor hasn't noticed the manipulation is not a durable business strategy.

What actually moves conversion sustainably is usually less exciting than a manipulative pattern and more effective over time: clear, honest value communication above the fold, social proof that's real rather than fabricated, a pricing structure that's easy to compare rather than deliberately confusing, and a checkout or contact flow with the fewest steps that still capture what's genuinely needed. I test and iterate on these levers with real data wherever a client has enough traffic to make that meaningful, rather than treating conversion optimization as a one-time design pass that's finished the day the site launches.

The most common failure point in typical design-then-development handoffs is that the design assumes a level of polish or a specific interaction that turns out to be significantly more expensive to build than anyone realized during the design phase — and the disconnect isn't discovered until development is already underway and a change is now expensive. When I'm designing and building the same project, that gap mostly disappears, because every design decision is made with real awareness of what it costs to implement, and every technical constraint is factored into the design rather than discovered as an unpleasant surprise partway through the build.

In practice this means some design decisions get made a little differently than they would in a pure-design engagement — not dumbed down, but informed. A complex custom animation might get simplified to something that achieves ninety percent of the intended effect at a fraction of the engineering cost, freeing up budget for something that matters more to the actual user experience. A layout that would require an unusual, fragile CSS workaround gets adjusted slightly to something equally polished that's also robust across browsers and screen sizes, rather than shipping something that looks perfect in the design tool and breaks on half of real devices.

This also means design doesn't fully stop once development starts. Real content, real data, and real device testing during the build regularly surface small refinements — a spacing adjustment once actual paragraph lengths are in place, a color tweak once a component is seen against real photography instead of a placeholder. Because the same person is making both sets of decisions, those refinements happen continuously and cheaply throughout the build rather than requiring a formal change-request process and a wait for a separate design team's availability.

Design work happens in Figma for almost every project I take on, because it's become close to a universal standard — clients, developers, and other designers who might work on the project later can all open the same file without a licensing barrier, and the commenting and version history make review and iteration straightforward without a separate feedback tool bolted on. For projects that need it, I'll also produce brand guideline documents, icon sets, and any supporting assets a marketing team needs downstream, but I try not to over-produce deliverables the client doesn't actually need just to pad out a proposal — a design system that will genuinely get used is worth more than a glossy but ignored brand book.

Ownership is unambiguous and stated in writing before a project starts: the client owns every design file, every asset, and every deliverable produced, full stop, with editable source files handed over rather than flattened exports. This matters more than it might initially seem, because a business locked out of its own design files is functionally dependent on the original designer indefinitely for even minor future changes — a dependency I don't think is fair to build into a client relationship, however much repeat business it might generate for the designer holding the files hostage.

For ongoing relationships, I'll often keep a working copy of the Figma file to make future updates faster, but the client always has their own full copy with edit access, not just a locked read-only link. If a client wants to bring a different designer or developer onto a future phase of the project, they can hand that person the complete, editable source material without needing anything further from me — which is exactly how it should work, and exactly how I'd want it to work if the roles were reversed.

A design is not finished the moment it's approved and built — it's finished when it demonstrably does the job it was designed to do, and that verdict comes from evidence, not from how proud either of us is of the visual output. Where analytics exist, I look at the metrics the project brief defined as success up front: conversion rate on a specific flow, time to complete a specific task, drop-off at a specific step, bounce rate on key landing pages. Comparing before-and-after numbers on the metrics that were actually agreed to matter is the honest way to know whether a redesign delivered, rather than relying on subjective impressions of whether the new version "feels" better.

For projects without meaningful existing traffic to compare against — a brand-new product, a pre-launch site — I lean more heavily on structured usability testing before launch: watching a handful of representative users attempt the core tasks the design is meant to support, and treating any hesitation, wrong click, or moment of confusion as a real signal rather than dismissing it as one user's quirk. Patterns across even five or six test sessions are usually enough to catch the problems that would otherwise only surface at scale, after launch, when they're harder and more expensive to trace back to a specific design decision.

I also build in a light post-launch check where it's practical — heatmaps or session recordings for the first few weeks, a look at whether the primary call-to-action is getting the engagement it was designed for, a check on whether any page is producing an unexpectedly high bounce rate that wasn't visible in a controlled usability test. Design isn't a one-time output; treating the first few weeks after launch as an extension of the design process, rather than the finish line, is what actually closes the loop between an intended outcome and a measured one.

The most frequent one is designing for the client instead of the user — a site that pleases the person approving invoices but confuses the person actually trying to buy something, because internal stakeholders naturally see the product through months or years of familiarity that a first-time visitor does not have. I push back, respectfully, when a requested change is clearly driven by internal preference rather than user benefit, and I ask for the reasoning behind every request so we can evaluate it against the actual goal rather than against whose opinion carries more weight in the room.

The second is treating mobile as an afterthought — designing the desktop experience first in detail and then compressing it down to a phone screen late in the process, which reliably produces a mobile experience that technically works but was never actually designed, just shrunk. The majority of traffic to most business sites now arrives on a phone, so I design core flows mobile-first or at minimum in close parallel with desktop, checking early and often that the experience holds up at the width most visitors will actually see.

The third is inconsistency introduced by well-meaning incremental changes after launch — a new page added by someone without access to the original design file, using a slightly different button style or spacing scale because the system was never documented or was documented and then ignored. This is exactly what a design system is meant to prevent, and part of what I hand over at the end of a project is not just the files but a clear, short reference for whoever adds to the site next, so the site still looks like one coherent product a year later instead of a visible timeline of who touched it and when.

For a new site or product with no existing users, design should lead development by at least a few days at every stage — wireframes approved before layout code is written, visual design approved before final styling is implemented, so development is always building against a validated decision rather than a moving target. Building ahead of an unapproved design invites expensive rework the moment feedback arrives, because code written against a screen that then changes has to be partly or fully rewritten, not just visually adjusted.

For an existing product with established patterns, design and development can run closer together, because new screens are often assembled from an existing design system rather than invented from scratch — the design decisions with the highest risk of rework were already made and validated when that system was built. In that situation, a new feature's design and its implementation can proceed almost in parallel, with design staying a short lead ahead just enough to catch structural issues before code is written against them.

I flag this distinction explicitly at the start of a project because clients sometimes expect the second, faster mode by default, not realizing that a brand-new product genuinely needs the slower, more sequential first mode to avoid expensive rework later. Setting that expectation honestly at the proposal stage, rather than letting a client discover the actual pace partway through, is part of running a project that finishes on the timeline it was actually quoted for.