Design Without a Function

Most operational software companies have design without a function. There's a designer, or there was one, or there's an outsourced relationship. There is no design capability built into how the company works. The state has no clean name, so companies sit in it for years. Sometimes a decade.

I want to call this Design Without a Function, because that's what it is. Design exists. The function does not. The company has design output: screens, marks, decks. It does not have design as a built-in capability.

This is the most common condition in operational software. It is one of the most expensive ones almost nobody puts on a P&L.

You hired your first designer when the product was small enough that one person could hold everything in their head. They worked closely with engineering, the work was good, and the company grew. Eventually they left. You meant to backfill but the pipeline was thin, and meanwhile the product kept shipping, so engineering picked up what they could.

Or you outsourced brand to an agency when you raised the Series B and the marketing site needed a refresh. The agency did good work. The product was on a different track, with a different designer or no designer. Over time the marketing surfaces and the product surfaces stopped looking like the same company. The agency engagement ended, the brand guidelines sat in a shared drive, and the product kept evolving in a different direction.

Or you have one designer, hired six years ago, who is excellent. They are also one person. They cover product, brand, marketing site, sales decks, customer-success collateral, the redesign of the trailing-twelve-months dashboard, and the new internal admin tool. They do all of it competently. None of it as well as it could be done, because no single person can hold all of those surfaces in coherent tension.

In every version, design is happening. Design as a function is not. The function is a built-in capability that compounds over time, survives any one person leaving, and produces decisions you do not have to remake.

The condition gets named so rarely because it sits between two states that have names.

"We don't have design" is legible. There's no designer, the UI is whatever the engineers shipped, and everyone agrees something is missing. The conversation is about hiring.

"We have a design team" is legible. There's a head of design, a few designers, a process. People know what to ask for and what to expect. The conversation is about scaling and craft.

The middle has no name. The company has a designer, or had one, or has an outsourced relationship. The CEO can answer "do you do design?" with "yes." Internal stakeholders have someone they can email when they need a thing made. In most quarterly reviews, the state is fine.

So companies sit in it for years.

The cost shows up in five places. None of them are line items.

The brand drifts away from the product. The marketing site says one thing. The product says something else, because the product has evolved through eighteen sprints of "let's just get this shipped" and nobody was holding the seam. Customers click from the landing page into the app and feel, vaguely, that they have changed companies. They do not usually articulate this. They trust the brand a little less and renew a little slower.

Every release reopens settled questions. Without an operating model, design decisions do not compound. Each new feature is a fresh negotiation. What should the button look like, where does this live in the IA, what tone does the empty state use, should this be a modal or a drawer. The same questions get answered, slightly differently, every quarter. Engineering builds three variations of the same component because nobody owns the canonical one. Polish accumulates entropy faster than features accumulate coherence.

You are one departure away from zero. If your single designer leaves, you do not lose a designer. You lose every contextual decision that lives only in their head. The brand guidelines run six pages, the component library is a Figma file with no documentation, and the rationale for any of it is in nobody's notes. Replacement cost is not the hire's salary. It is the rebuild.

Engineering picks up the slack and resents it. This is the cost that hides best. Engineering teams will, in the short term, just do the work. They will make the call on layout and typography and IA, and the call will be reasonable, and they will ship. But this is design work being done by people who didn't sign up for it, with no compounding skill base. Over time the resentment shows up as either attrition or as the team building things in ways that are easy to engineer rather than easy to use.

The company stops being able to tell its own story. This is the deepest cost and the hardest to see. Brand and product are how a company expresses what it is. When they drift apart, the company gradually loses its own coherent identity. Not in the obvious "we need a rebrand" way. In a deeper way, where leadership can't say crisply what the company is anymore because the surfaces they look at don't agree.

Companies in this state usually try one of two things. Both make it worse.

Hire another designer. This is the obvious move. You had one designer, they were stretched thin, you'll hire another. Without an operating model, you have just doubled the surface area of the same problem. The two designers will produce twice the output, of similar quality, with the same lack of compounding. They will also have coordination overhead, divergent style judgment, and the question of who owns what. Nobody will answer that question, because nobody owns the function. Within eighteen months, designer #2 will have left, the company will be back to one designer, and the conclusion will be "design is hard to hire for."

Outsource brand to one agency and product to another. This looks responsible because it brings in specialists. Brand agency does the marketing surfaces and the identity work. Product design firm or contractor does the app. Each does competent work in their lane. Neither talks to the other in any meaningful way. Six months in, the product has evolved past the brand, the brand has evolved past the product, and the company has paid for two competent partial solutions that do not add up to a whole one. The deliverables are good. The coherence is gone.

The move is to build the function, not the headcount.

The function is an operating model. It is the set of agreements about how design happens. Where it lives in the team structure, how it integrates with engineering, who owns the canonical components, how brand and product stay in conversation, how decisions get recorded so they compound. Headcount is downstream of the model. Without the model, any new hire just adds surface area to the same problem.

In its best form, the function looks like this. Designers embedded directly in engineering teams, collaborating at the surface where the product is being built, instead of a design tower handing comps over a wall. Brand and product handled as one problem, by the same operating mind. A canonical component library that is the product's actual UI. No parallel artifact. Documentation that captures decisions and rationale so the function survives any one person leaving.

I have lived this from the inside. At CargoSense and at PowerFleet, I was the entire product design function. Not a department. A single person holding the seam between brand, product, and engineering. At PowerFleet I eventually hired Ben Mays to share the load. I know what that state costs because I spent years inside it.

I have also built the function out from the client side. After my 2014 RailsConf talk on developers and designers working better together, Sam Crigman (then Procore's Head of Engineering, current CTO) approached me. By the time the engagement started, design at Procore was effectively a person or two with a foot in product. I set the operating model. Dedicated designers embedded in every scrum team, collaborating at the surface, instead of a tower handing comps down. I helped hire the first two designers. Rather than relocate to Santa Barbara, I handed team leadership to Raffaello Colasante, who moved from running mobile into UX/Product Design and went on to head the function. The team scaled to fifteen under his leadership after the handoff. The embedded-collaboration model held.

Candidly, that's once at scale, on the client side. The pattern is well-tested as an employee. The scaled handoff is one client. I will not claim a wider pattern than that.

If you want to know whether your company is in this state, two questions.

One: if your current designer or design relationship ended tomorrow, what would you lose? If the answer is "a person and their portfolio," you have design output. Not a design function. If the answer is "the way design integrates with how engineering ships and how brand stays consistent across surfaces," you have the function.

Two: when a new feature ships, do design decisions compound, or do you make the same ten decisions over again? If the typography, button styles, and IA patterns get re-negotiated each sprint, the function does not exist. If new work fits into a coherent system that gets sharper over time, it does.

If both answers wince, you are in the state.

If this describes your company, the next move is usually not hiring another designer.

The next move is getting someone senior to build the function with your engineering team. Set the operating model. Make the first hires deliberately. Hand off when the model holds. Live with what's left. Done right, what's left is durable. Done wrong, you have the same problem in six months with two designers instead of one.

Meticulous does that work, mostly inside B2B operational software. We have done it as employees, repeatedly. We have done it for a client through to a durable function, once. The Procore case study walks through that engagement.

If that's the shape, we should talk.