Discover more from The·By·Product
Introducing Context-Driven Design
A better, faster, cheaper way to create digital things
Unless you are content with a Shopify template, it takes too much time, money, and resources to create a truly world-class digital experience. It is rare for anything good to launch in less than six months, and large websites or apps, especially from big companies, can easily take a year.
While recent technologies and tools have brought us new levels of simplicity, power, and collaboration to the creation process (just a few examples: think how much simpler it is to deploy solutions thanks to AWS, how much more functionality sites have thanks to React, or how much more collaborative the process is thanks to Figma), what has not substantially changed is the process by which we've been designing and building experiences. The industry's best practitioners are still doing the same user-centric design and agile-ish development that has been done for the last decade, even though we've collectively learned so much more about how people use digital and the kinds of experiences they expect.
There’s a better, faster, cheaper approach to design, which I call Context-Driven Design. It is anchored on a key insight: the web is mature, and so proven design constructs, anchored by established sets of user behaviors, exists for virtually every reason people use a digital experience. There is no need to reinvent the wheel. We can embrace best-practices design for any given use case, and rapidly innovate and launch within that framework, instead of developing a new context entirely.
In fact, not only is there no need to reinvent the wheel, it is desirable not to reinvent the wheel, because we don't want to confuse our audience.
For example: everyone on this planet has spent countless hours shopping and buying on Amazon. What happens when people now go to a different ecommerce site? They're not confused, since this other site generally works the same way that Amazon does. They can apply their learnings from Amazon to immediately understand and navigate the new site. So a first-time visitor to WalMart.com can successfully find, shop, and buy. If WalMart.com decided to be radical and present a website that worked in a way that is entirely different from how consumers have been trained by Amazon, WalMart.com would fail: nobody would know how to buy anything! Likewise, if a new streaming site looked like the Google home page they'd be similarly befuddled, because the world has been trained that streaming services function like Netflix.
Which means: great design today is an innovative user experience within the context of how users expect a particular kind of site to work. It's not about inventing an entirely new experience that is a whole new way for how people do things online. Those days are over; we've spent the better part of twenty years figuring out the best way for people to do things digitally. Let's leverage those learnings for what we design today.
The good news is that existing design patterns make most websites quite simple and fast to design. Take the design construct that exists; tailor it to a particular brand and messaging; launch, and then evolve based on real usage data. That's the essence of Context-Driven Design. Understand the context users are visiting the site, and design based on how users expect the site to function.
The corollary to this line of thinking: most up-front research and analysis—the kind of "strategy" work performed by user experience strategists—is often unnecessary.
For example, if I am designing a shopping site, I don't need reams of research and analysis about personas, user journeys and all the other trappings of user experience research. That's because we collectively have a strong understanding of how users approach the task of shopping. This approach differs based on the kind of shopping: replenishment shopping for items like groceries, for example, is very different from an impulse purchase of a cute blouse found on instagram, which is turn is different from researching a big-ticket item like a car. But within each category of shopping, user behavior is very defined and clear. So once we understand the context, site execution is straight forward; no custom research is required, unless we need to understand an audience’s particular, unique mindset, or the jobs to be done are niche.
By dramatically compressing up-front research and the level of effort required for design, engineering has less requirements to implement for initial the release. And, the more likely the design users established patterns, the more likely libraries and other code exists to implement the solution, resulting in more engineering time saved. By designing and building faster, we can launch faster, giving us more time to test and optimize the solution.
With this approach, for example, I worked with a large financial services company to launch a website selling a new financial product in eight weeks. One week was spent in up-front research and planning; design concepts were shared in week 2; development and detailed design began in week 3; and parts of the experience launched as a test in week 5, with the bulk of the experience launching in week 8. This let everyone start testing and optimizing designs in week 5, and refining the full solution starting in week 9. No more waiting for a significantly longer development and launch cycle to see if something is working.
Building a website with Context-Driven Design requires four steps: Context, Core Design, Implementation, Testing.
Step 1: Context
The first step in Context-Driven Design is an extremely short research and planning phase—typically one week—where the goal is to define the context in which we're designing.
Context definition dispenses with burdensome discovery phases. Instead, we mostly formulate clear answers to three questions:
What is the one solution we are providing to solve one problem for one target audience? It can be tempting to think of a digital experience as complicated, targeting many different audiences and constituencies, all of whom use the product for different reasons. That could be the case over time, but not right away. The best products do one thing very well; only once products are mature and successful products do they expand to address other audiences and use cases. It's hard enough to do one thing really well, no less many things. So for the initial release of any digital experience, let's focus and really nail it. Which means: we must have the discipline to define who is our most important audience; what's the main problem they are looking to have solved; and how we solve it.
Why should our solution be used? Next, we must clearly define the reason why people should use our solution over all the other options out there or why use our solution versus no solution at all. The purpose is to communicate this in a succinct manner. This is the elevator pitch we're going to use to make a sale; no rambling books.
How are we measuring success? No initiative is a success if we cannot measure it; measurement gives us focus so the design can guide users to the desired outcome. It is tempting to define many KPIs and ways to measure success. This should be avoided; instead we want to define the one clear metric we care about. Is it total sales online? Daily visitors? Leads? When we know what we are aiming for, everything else follows.
If these three questions cannot be answered with confidence, the project lacks the focus required to be a success. In this case, Context-Driven Design is not the right solution, and a more conventional research and strategy may be needed so that a consensus can be reached on the above questions. This lack of alignment does happen: for example, I recently worked with a provider of an online service that did not have a clear idea of who subscribed to the service or why. In this case, primary audience research was commissioned to deliver the above answers. Once those answers were resolved, design was able to begin in earnest.
With answers to the three questions in place, we have the landscape defined: we know who our audience is, what we're trying to get them to do, and why. Now we just have to decide what design construct is appropriate for the experience we are creating, and then execute the construct in a manner that addresses the defined positioning and value proposition.
The process of selecting a construct is simply matching the problem the user has, with the general design framework they expect to see when visiting a digital experience to solve it. For example, if I'm looking to buy for sneakers for my children, I expect an ecommerce experience similar to Zappos: a home page promoting different shoes and deals, and all leading to a category page, where a grid of shoes can be filtered by type of shoe, price, size, and brand. Conversely, if I want to learn more about a new car, or a new phone, or any other big-ticket item, I want to go to the brand's website visit the product in question and see a beautiful page showcasing the product and its features, where I can revel in both its beauty and all the small details that make the product great (there's a reason why the design of the page showcasing the iPhone 14 Pro and Tesla Model S are quite similar).
I’ve identified 14 digital contexts—although I may have missed a few. Each category follows very similar design rules and principles, and have an established manner in which users expect to interact with the experience:
Multi-product ecommerce: Websites, like Amazon, that sell large numbers of products.
Single or limited SKU commerce: Websites that sell one, or a handful of items.
High-consideration product: Websites, like Apple.com or Telsa.com, that sell a small number of products that require significant research before purchasing. In some cases, the transaction cannot be completed on this site.
Service product: Websites that sell a service, such as a subscription to a broadband internet, a subscription to online service like Dropbox, or one-time transactional service, such a mortgage or insurance.
Corporate: A site that provides an overview of a company and the product and services it provides-common for B2B businesses.
Feed: A website organized around a stream of information, organized chronologically or an algorithmic measure of importance. Facebook, Twitter, even email services are examples of a feed interface.
Editorial: A content site like NYTimes.com or CNN.com.
Video: A service that provides streamlining video content, such as Netflix, Twitch, or YouTube.
Search: A website where search, and search results, are central to the experience. Google, Wikipedia, and Zillow are examples.
Workspace: A digital experience that is an application, whether it is Google Docs, Notion, or Figma.
Dashboard: An experience where people access personalized information that they're monitoring. Account management pages for mobile service or a bank account are common examples.
Game: An interface used to play a game, whether it is a first-person shooter or a mobile puzzle.
Mobile-Centric Interfaces: A set of interfaces primarily geared to devices. This includes chat and messaging, camera, and maps.
Personal: A website that's a personal presence of an individual, which could include a resume, portfolio, or profile.
The designer must, based on the problem the product in question promises to solve, select the appropriate design context. This becomes the basis for the next phase of work, the core design.
Step 2: Core Design
Next, we begin to design. We prioritize the most important part of the experience: the main page. The goal is to produce a page that fits within the constraints of the appropriate context, while ensuring that the value proposition and message we defined in the previous phase is clearly communicated, even to the most casual of visitors.
Most people will visit a new site and look at the first page they see for a few seconds. During this brief period of time, the user must get oriented, understand what is being offered, the problem being solved, and if they want to further engage. If any of this is confusing or not clear, the user will leave the site. For this reason it is critical we begin our work completely focused on the most important task of any experience: getting a new visitor to quickly understand the experience, its purpose, and messaging.
Understanding is the first step; the second half to the design is engagement. Here, our goal is to quickly translate understanding into action. This is where KPI definition fits in.
In the first phase of Context-Driven Design, a key item to define was the experience's KPI: the concrete goal for the site. Now, our job as a designer is to directly translate the understanding they have about the experience and offering into an action that directly matches the site's goal.
If our goal is to get the user to buy a subscription offering, let's buy a big "buy now" or "get started" button in places on the page they arrive at once they understand what's available for purchase. If our goal is site traffic because it is an editorial site, let's make sure links to highly appealing content are prominent and enticing. If our goal is to facilitate the research of a big-ticket item, let's get them to the product details page right away. Every digital experience has a goal; let's get them to take the next step so the user is one step closer to accomplishing the desired task.
In combination, the successful main page has three critical components:
The user immediately understands how the site works, since it is designed within a recognizable context.
The user immediately understands the value proposition of what is being offered.
The user is driven to take the next step, and that next step is consistent with the business goal of the experience.
For example: let's say we are producing a web site for WidgetCo, which manufactures Widgets, a key component in the production of Gadgets. WidgetCo's Widgets are better than other options because they're less expensive and more durable than alternatives. Widgets are sold in bulk through a sales team, which must work with the Gadget manufacturer to make sure the specifications are correct.
All this means:
WidgetCo's core value proposition is making it possible for procurement officers to get the most reliable and least expensive Widgets for their Gadget assembly line. The business goal is to generate leads for the sales team.
The design context is a corporate site--WidgetCo's website needs are no different than any other B2B company.
The designer must produce the WidgetCo home page in a manner that functions and behaves like a corporate site. It has hero messaging around the durability and affordability of its Widgets; it is clear from the visuals that Widgets are used to make Gadgets; and there are clear call-to-actions around contacting sales for a quote.
Done correctly, every Gadget procurement executive can visit WidgetCo's site and clearly understand the site is for them, WidgetCo is a great place to get Widgets, and it is easy to start a relationship. The core mission of the site is accomplished.
Let's not forget that we live in a mobile-first world. All designs should be designed first and foremost with mobile in mind, and secondarily as desktop. The design should be responsive, so it dynamically adjusts based on the size of the user's screen.
None of this suggests that a single page should be produced and that's it. The designer should be encouraged to explore many different creative approaches for this page, all within the confines of the design context, with clear messaging and call-to-action. Ideally, design candidates are quickly tested with real users to validate the page is as understandable as intended. In this manner we can arrive at the right design solution for the core experience.
The only catch to developing the main page is that for many websites, especially content sites, the "home page" or "main page" is not the most commonly-visited site, especially when users visit content pages directly from search and social. That's ok; that's how the web works! We still want to design the main page of the experience first, so we can be confident in the overall design approach and messaging. Once that is clear, we can extrapolate the design structure and messaging internal pages. In this manner we can ensure the messaging, site purpose, and construct is clear no matter what page is visited first.
Step 3: Implementation
One page is enough for business personnel to understand the new site and how it should function, and for engineering to begin to get an idea of the full requirements for the site, including for pages that don't yet exist.
This general direction allows us to begin an implementation phase where the technology team can build the main page, and design and engineering work in tandem to design and develop the remainder of the experience.
The remainder of the experience can be very big or be very small. Since our goal is to launch something as fast as possible to maximize time for optimization against live traffic, we must err towards small when thinking about the rest of the experience.
In fact, the remainder of the experience should be as small as possible to achieve our KPI. And since that's the only goal we care about, anything in the experience that does not directly contribute to achieving the goal can be discarded.
With this orientation in mind, we begin the implementation phase by mapping out the minimum number of pages required to have a launchable experience that achieves the goal, requirements for each page are developed, and finally, weekly design cycles. This allows a high frequency of work to be handed off to the engineering team, so development can occur while design is still in progress. Efforts should be made to minimize engineering requirements by relying on manual work for initial release. For example: is a complex implementation required for initial launch, or could the website save data it collects in a simple table, and manually hand off leads or orders for launch? By making these kind of decisions, we can get to market faster and test the viability of our offering sooner. The more complicated implementation work can happen later, once it is clear the experience is working as intended.
Newly popular Generative AI tools can significantly speed up the implementation process. Content creation, and to a lesser degree code creation and design creation, can take a fraction of the cost and time than human-driven creation models. And, AI models are more likely to generate usable and relevant content since there are many examples of each context.
Step 4: Testing
In Context-Driven Design parlance, the "testing" phase is what other processes would call launch. In this phase, the experience is brought to market, available for real people to use. But we avoid the temptation to launch and move on, never touching the experience again. Instead, we treat the launch as a test, with resources available to design more and develop more.
These allocated resources serve two purposes:
First, the experience is intended to drive a specific KPI. Resources should be utilized to revise the site based on real-world results. There's always an opportunity to refine the existing experience and test new approaches or messaging to drive our primary business objective.
Second, corners were cut to quickly launch the experience. The site likely should have certain pieces of content or functionality that was removed in the interest of launching fast. And, more complicated technical implementations, such as integrating with systems the site should interact with, were likely removed from scope in the interest of delivering a fast launch. Now is the time to add to the experience these features, functionality, and integration points.
Done correctly, the test phase lasts several months, ideally longer than the time it took to get the original experience live. This time is used to optimize and make what's live truly great and harden it so it has the level of integration and features that are needed to truly scale.
Context-Driven Design is a work in progress, and the approach is still being refined. But what we've learned so far is that the process is liberating for everyone involved: business owners, designers, and developers.
It's liberating because Context-Driven Design is really about two general principles: (1) think less and design morel and (2) launch less and test more. This ethos strips out all the unnecessary steps so teams can be lean and productive. Let's quickly decide what's really needed and design for that. Let's avoid reinventing the wheel and design what users expect. And let's build the minimum we need to launch, saving all the messy stuff for later. And most importantly, let's treat what we launch as a work in progress, something that's constantly tested and refined over time, steadily evolving to become something great.