What should a growth-driven design blueprint include?

The broad document is the output of the method's strategy stage. That stage connects what the audience needs and what the business wants to a wishlist, then turns the wishlist into a plan for building. The parts described below are our recommendation for what makes that plan usable.

Lean Labs' Design Blueprint answers a different question. The agency's article on the three stages places it in the design sprint of a build, where the team redesigns one key page to set the look of the rest of the site. It produces a style tile and a Figma mockup of that page. The work takes four weeks and costs $6,000 to $12,000 depending on the tier.

So the strategy document decides who the site is for and what ships first, and the Design Blueprint decides what it will look like. The article treats the agency's strategy work, such as its buyer-path map and messaging framework, as a different stage. If a quote includes both a design package and a build, ask whether the design fee is included in the build quote.

The document should open with what the business wants from the site, stated so a later reader can check it. Suppose an accounting-software company writes its goal as more demo requests from firms with more than 20 staff, rising from 30 a quarter to 45 by year end. A reader can check that next year. "A more modern site" gives them nothing to check. The 45 is a target the team chose. It should sit beside the current figure, because a benchmark needs a reference point such as the earlier version of the same site.

The goal comes first because most of what follows is ranked against it. A page that looks urgent to one department can turn out to have little to do with the stated goal. Some work has to happen whatever its rank, such as moving existing pages.

The second part records what the team knows about the people the site is for. The method's guide to UX research begins with a question about something users were seen struggling with, chooses a way to investigate it and reports the findings. Interviews and surveys ask people for their reasons. Recordings and analytics show what they did.

The blueprint is more useful when it labels each statement by its kind. Suppose that at the same company, six of the last ten sales calls included a question about payroll integrations. That is an observation. "Buyers leave the pricing page because they can't tell whether we integrate" is the team's explanation, and it could be wrong. Nielsen Norman Group makes a related point about testing and research: a test compares the designs you thought to build, and research is how you investigate the problem before you design anything.

Lean Labs' article recommends gathering this evidence from the people closest to buyers. Customers can say what convinced them, while sales and support hear the questions that come up before and after the purchase. The method's page on mapping the buyer's path adds that the path isn't a straight line, since people can skip a stage or stay in one for months. We cover the research in more depth in how to validate the assumptions behind a strategy.

Every idea for the site goes into one list, and the list gets an order. The blueprint should show the order and the reasoning. One common approach scores each idea for impact, confidence and ease from one to ten and multiplies the three. The scores are judgments, and the scoring can favor cheap work. So treat the result as a way to compare ideas, and leave room for the work that has to happen regardless of its score.

The list should also show what was left out of the first release, with the reason each item is waiting. Recording the reason gives the team somewhere to start when the idea comes up again.

Take the accounting-software company and its demo-request goal. Six of its last ten sales calls included a question about payroll integrations. Suppose recordings also show visitors scrolling the pricing page to the questions at the bottom and then leaving. The team's explanation is that integration details are hard to find at the moment buyers are comparing cost.

The blueprint turns that into a priority. An integrations page and a short integrations section on the pricing page go into the first release. Both are tied to the demo-request goal, and the sales calls and the recordings are named as the evidence.

Suppose the same team also wanted an interactive pricing calculator, and that it would take longer to build than the two integration changes together. Nothing in the evidence says buyers are confused about price. So the blueprint defers the calculator and records why. If visitors still leave the pricing page after launch, the team reopens the question of what they were looking for, and the calculator is one of the ideas it can weigh. We cover how a first release is scoped in what a launchpad website is.

The page plan names each page in the first release, the buyer question it answers, the proof it offers and the next step it asks for. It also says what happens to the rest of the current site: which pages carry over unchanged, which are retired, and for each retired page whether its URL redirects to a suitable replacement. The method describes the launchpad as a foundation for learning and improving, and says plainly that it isn't the final product. The pages in the first release, together with the pages that carry over, still have to make a working site.

No page count fits every company. Lean Labs scopes its own launchpad at three to eight pages. That is one agency's scope, and a company with several product lines may need more.

List the numbers that will be recorded before launch and compared afterward, with the definition of each. A baseline taken from the current site gives the team something to compare the new one against. A before-and-after difference shows that something changed. It doesn't show that the redesign was the cause. We go through the choices in what metrics to track in growth-driven design.

Then put a name beside each decision. The method's launch process recommends one accountable stakeholder for every page, who collects feedback from everyone else. The blueprint should carry that list. It should also say who owns the analytics and who keeps the ranked list current once the site is live, because the deferred items are a starting point for the improvement stage.