I’ve worked for digital design agencies for most of my career, and all of our projects generally have the same shape. We start out learning about our clients’ business and their needs, form hypotheses, make proposals, eventually align on a solution, and then we go build it. This is so standard, it has a (semi) famous diagram about it:

If you’re at all involved in designing digital tools, especially if you work at an agency, doing work for clients, you’ve seen this. It’s ubiquitous enough to get spoofed on the TV show Silicon Valley with the “Conjoined Triangles of Success.”

What I am going to tell you right now, is that you probably don’t need to keep doing projects like this. This is because this project shape assumes that we do not know what we’re doing, which we very much do.

Ok, with that thesis out of the way, why do projects look like this? There are reasons! The most obvious is that this model assumes that the people doing the work are coming into a new project for a business they don’t understand. This used to be the case. Back when I was starting out designing websites (we didn’t have “apps” yet), we genuinely didn’t know what we were doing. It didn’t, so much, matter, because NO ONE knew what they were doing, even the people who hired us. “One website, please!” with not-a-lot of sense why, aside from you needed to have one. (This is not dissimilar to the situation with AI right now.) We were making it up as we went along, and the projects were pretty simple, with simple goals, so everyone was fairly happy to have a website that had some brochure content on it and looked pretty nice.

As time went on, our work moved up the value chain, from awareness to more core business stuff. We could make sales, or offer a service online. Eventually, there were businesses that were online only, and getting it right, objectively doing something measurably useful, became really important. Along with this budgets, timelines, and numbers of stakeholders increased. Now, we needed to do two things: 1) since we were designers parachuting into a new business, we needed to learn all we could about their assets, problems, and goals, very quickly, and 2) we needed to convince our clients that we understand all that stuff, and now we’ve come up with a good solution to their needs.

This is the point where the double diamond shape really developed. Both of these goals were fulfilled by that left-side diamond. Over time, both contracts and agency teams took on a shape to match the diagram. The work had two phases. Design split into more specific disciplines and some designers became UX designers, became Researchers, became Strategists. Other disciplines got more specific too, and sometimes you’d have whole separate teams dedicated to the discover and define steps. They’d hand things off to an executional team to do the right side of the diagram to build things, while the strategic team moved on to the next new project.

It made sense, because we really were learning new businesses, new audiences, and new ways of behaving online all the time. One month I would be selling sunglasses. Another, I’d be working on an interactive digital pet cat. Or designing software for a digital sign in Times Square. This two phase approach of making sure you knew what you’re doing (“Build the right thing” in our lingo) and then building it (“Build the thing right”) worked pretty well for us.

Note that the diamond part of the diagram has its own significance that I’m not going to get into here. For right now, we just need to understand that there are two parts:

Businesses liked this model. There was plenty of time for the agency team and the client team to get to know each other, and to make sure everyone was on the same page. Another lingo thing: we call this “alignment.” Plenty of time to get aligned. And you could prove you were getting aligned, and making progress towards getting to “Build the thing” with lots of presentations and documents and spreadsheets (“deliverables”). Clients like deliverables because they’re proof of work, and easy to plan around. We can say, “Let’s spend 10 hours planning stakeholder interviews, 10 hours doing them, 10 hours preparing a presentation, 1 hour presenting, and 4 hours on revisions. This will take two calendar weeks.” That’s a list of items that fits really well into a contract and a checklist. You can plan this out a year in advance, no worries. Everyone can track progress and agree when it’s all done. Little risk, and little possibility anyone gets yelled at. Agencies like this because creating all of this proof of work takes a lot of billable hours.

EXCEPT! This is a schedule, list, and definition-of-done anchored to a bunch of things that are not actually directly related to the success of the final outcome of the project. We assume that if we do these tasks, in this order, over this time frame, we will get something valuable out of it — important knowledge alongside alignment about its accuracy and relevance to our work — but we don’t actually KNOW this. The work exists at a level of abstraction from its actual usefulness. As the saying goes “what gets measured gets managed,” and over time, this process and these deliverables became the primary point of the activity, regardless of where they were actually helping with the quality of the end result. Sometimes, a lot of the time if you’re not careful, all of that work gets done and then goes into a file folder, never to be referenced or seen again.

This two phase approach can also create disjunctions. Even if the deliverables are useful, when team Right Thing rolls off, and team Thing Right rolls in, there’s an opportunity to lose things. And shifting people and modes takes time. And now that you’ve got team Thing Right in the room, and team Thing Right is off doing something else, if you have a question, to ask about behavior or strategy or competitors or whatever, you don’t have the right people there to answer it. There’s inefficiency baked into this process. If you’ve got a lot of resources to throw at the problem, that’s not that big a deal, but what if you don’t?

This approach solidified during a period when there was, just, honestly, a lot of money to throw at things, and time to let it all play out. There’s a documentary about the band Steely Dan where one of the guitar players is talking about the luxury of making a rock album in the 70s, and he says something like, “It used to take me six weeks to find a comfortable chair at $900 per day.” I think about this a lot, because, during the early 2000s, when all of this was evolving, that was very much the vibe. Around 2005 or thereabouts, I was flown 500 miles, and put up in a pretty nice hotel, to spend four days making one powerpoint slide. I don’t recall how comfortable the chair was. Although I do still use a version of that slide. Hopefully whoever was paying for it knows how much I appreciate their contribution to my future success!

Tempus fugit, and today everyone is paying much closer attention to time and budget. When people are looking for efficiency, the big, mutli-month project where you’re not actually building anything yet is a prime candidate for the chopping block. This is OK! Really. This is fine, and not in a dog-drinking-coffee-with-the-room-on-fire kind of way.

The reason it’s fine is that we do, in the year 2026, know what we’re doing, and it’s not necessary to pretend otherwise. It’s actually a detriment to our work to pretend otherwise.

What do I mean when I say that we know what we’re doing? I mean that after many years of talking to people, solving problems, testing, and looking at the performance of our solutions in the real world, we have a very detailed picture of how people go about solving problems and getting their needs met using digital tools. Many, MANY, of the basic tasks people perform online have relevance across a whole range of online activities regardless of industry or user type. Demographics don’t matter for usability nearly as much as we’d assumed back in the day, and we have a good grasp of where the real differences are and how they affect things. We have basic interactive patterns for many common things that users do that are so familiar that it would be ridiculous to tinker with them too much.

Even very specific use cases are well researched and documented. We know a lot about how people use ratings and reviews online to find goods and services. We also know a lot, specifically, about how people use ratings and reviews online to buy books, buy cars, hire a plumber, a financial advisor, or find a primary care physician. I can tell you specific differences in how a person on Medicaid who’s making a doctor’s appointment looks for care depending on whether they’re in the US southeast or northeast. We’ve… I’VE talked to, observed, and surveyed thousands of people. And we’ve got experience with specific approaches to designing tools for all of those situations. We’ve done it, tested it, observed the results, rinse, repeat, over and over again. These are, at a high level, at least, solved problems.

But the standard project model, the one that everyone sees in their heads, still, when they think about this stuff, still assumes we’re looking for basic answers, and that every new client business is sui generis, and agency teams are starting from scratch with each engagement. Agencies are happy to pretend we need to do the whole song and dance because there are a bunch of billable hours in there. But it really undermines our authority as experts to do this. And clients can feel how unnecessary it all is, which undermines us further. As an old job, we had some principles, and two of them were “Be Consultative” and “Build Strong Relationships.” It is hard to do those things when you’re pretending to learn things you already know, reading them bck to clients who definitely already know them, and billing 400 hours to do it.

So! Let’s just cut it?

No!

Well kind of yes. For probably 90% of projects, way more than you’d think, the way we’ve done this to date isn’t doing what we need it to do anymore, but the WAY it gets pared down is really important.

We know what we’re doing, but, unless we’ve worked with a client before, and have trust built up, they don’t know that we know what we’re doing. And we still need alignment on project goals, and the specific application of what we know to the problem at hand. If you just chop out the “right thing” phase, and don’t make any changes to the “thing right” phase, you might not, in fact, be building the right thing OR the thing right.

Even with all this knowledge, these things aren’t really one-size-fits-all. There’s always something specific to a need, audience, client, or project that benefits from custom tailoring to get to the right solution. Lots of places will sell a template, but even with something off the shelf, you’ve still got to make the solution fit inside the container. At best, that works kind of OK, at worst it’s a Procrustean bed situation, and in all cases, there’s work involved.

I’ve seen “just use AI” proposed as a solution, but that doesn’t really solve anything. AI is a pretty efficient way to aggregate knowledge on a particular topic, but it’s not very good at applying a specific solution to a specific problem. It IS pretty good at appearing to do this, but you end up with general recommendations dressed up in specific language, a kind of platitude-in-expert-clothing. Sometimes the idea is that the product owner will do discovery, and then just tell the executional team what they need to know. But that creates all the problems of a disjointed two phase process, with the added problem of having no one to prod and stress test the product owner’s findings. This kind of work goes better when it’s collaborative, so the project can’t over index on anyone’s personal idiosyncrasies or strategic myopathy. Besides, whatever you do to set up the work, new questions always arise during the executional phase anyway.

The high level solution should be pretty obvious: hire experienced people who know what they’re doing. You can keep the pre-work to a minimum, focused on alignment rather than discovery, have a team that can answer strategic questions around when those questions arise, from beginning to end, and dramatically shrink the timeline of delivery.

To actually do this, we need a mental shift: collaboration over presentation, recommendation over observation, problem solving over deliverables. Instead of anchoring to presentations and deliverables, we need to think about collaboration and answering questions. If both clients and their consultants know most of the basics, and a lot of the specifics, you can focus on filling in the gaps in knowledge and crafting a truly bespoke solution. Instead of doing 10 hours of interviews over three weeks, then spending another week pulling together a presentation, get everyone together for a three hour workshop. You don’t need to present the findings, because everyone participated in finding them! Instead of trying to game out all possible questions ahead of time, address them when they arise. Focus on what you need to move forward. For a consultant with experience and depth, a couple hours of prep and an hour-long working session with key stakeholders is often enough to get unstuck. No need to hold up execution! And if you’re working together to solve problems, everyone has a lot more trust and ownership of the solutions you come up with.

As a practical matter, you need to do some things. First, you want a stable team over the whole life of the project. And they need to be experts in whatever they’re doing. Second, you need client and consultant teams to work together, collaboratively, to identify and fill gaps while aligning on project goals as quickly as possible. Push as much of this as possible back into the scoping work that happens before a contract is even signed! And speaking of contracts, we shouldn’t commit to specific deliverables that aren’t directly tied to project delivery. For the vast majority of projects, we do not need a formal competitive review, personas, or journey maps. Work of that sort should be conducted only as-needed, be based on prior knowledge, and worked into the ongoing delivery schedule. Projects still need milestones but those should be tied to actual feature design (or development, depending on how agile you’re being). Do what you need to get done to move forward, then measure project momentum by progress made towards completion.

I’ve been pushing this approach for a few years, and the difference is dramatic. Fivish years ago, for a redesign and replatforming of a health system website, I used a two phase approach that took about a year. Three years ago, the same basic project took half that amount of time. Last year, I worked on a very similar project for a legal client, and the timeline was about the same, but the team was half the size. In each case, the quality of the work increased with the total number of hours spent shrank. I don’t think we’ve reached the end of this evolution, especially as AI use gets out of its silly/stunt era and starts delivering real efficiency. I have no idea where it ends. And there are hard questions about how you develop junior talent when a small, senior team is ideal. But right now, it’s irresponsible to keep doing things the way we have been for the past 20 years.

Let’s All Stop Pretending We’ve Never Done This Before

Why Cheaping Out on Content Is a Terrible Idea