From Sketches to Style Guide: Using Design Systems to Encode Strategic Decisions

25 Oct, 2026

1. The Premise

One of my engagements involved a global enterprise technology vendor that was planning to digitize its business processes through two enterprise applications, a customer self-management (B2C) portal and an offer management app (OMA).

The full strategy was finalized by a committee of senior executives — the heads of the product, IT, and marketing departments — in a boardroom meeting at the company’s headquarters, but the final output would be executed by an offshore team.

The portal was a hosted product that the company was planning to market to its clients, who were telecom companies, while the OMA was a full enterprise application that would run on a tablet. As with the portal, the company would create and own this product and sell it to its multinational telecom customers. The function of the OMA was simple — staff members were meant to use it to create new rate plans, bundles, and new offers quickly, which the company expected to make it easier to define product and service bundles, rates, discounts and financing options. At the outset, the company believed it had a sound UX strategy.

However, when I met the offshore development team, the full strategy hadn’t reached them; they had only been told about developing two enterprise applications, one of which would be a mobile app. The overarching strategy that I received was to enhance the user experience, and since the OMA brief was limited to creating bundles and plans, I built a persona of the end user from the client’s data and devised a tab navigation around it, which I sketched and prototyped.

The portal moved ahead without any dispute over its navigation or colour palette, but the OMA was a different story. Late in the engagement, a new member joined the management team and proposed drag and drop navigation, a touch screen model, in place of the tabs. By the time I met him at a second focus group of decision makers, his proposal had already been accepted, and I was told that I would have to follow it. Management felt the tab navigation would look outdated by comparison, and the tabs were set aside.

I did create a style guide for the client, but the navigation structure it was built around was replaced, and the guide stalled because it needed to change with it. A style guide is written after the UI has been developed, so it had little to hold on to once the structure moved. What I could have created was a design-intent guide, one that defined the roadmap and gave the client a chance to review decisions before the build rather than after.

A strategy made in one room and built in another is only as strong as what travels between them. This article is about what has to travel, and why a guide that carries intent serves distributed teams better than one that only describes the finished product.

2. How Intent Gets Lost

A major risk of distributed teams is the miscommunication and the misinterpretation of project outcomes and product details. This could delay the product lifecycle or derail it from its stated goals. The intent gets lost and teams find themselves solving more problems than before. IT projects in particular have various teams working in concert to build the architecture of the system piece by piece. Among the most important factors is user-centred design, from strategy through to a UI grounded in research and use-case scenarios.

Digital transformation initiatives are often conceived from a technological perspective rather than a user-centred one. Stakeholders tend to notice design as the user interface, but design is not just UI. Few would imagine that design strategy could change the direction of the execution and planning. Some projects acknowledge the role that design plays in merging user needs with the business objectives, whereas in others, design is made to retreat into the background while the business decisions take precedence. Somewhere down the middle, design decisions such as navigation structure, UI consistency, and corporate branding and messaging get documented, along with the principles of user-centred design, in the context of the SOW (statement of work).

Documenting these decisions does not guarantee they survive delivery, and that is where misinterpretation starts. Prototyping therefore becomes critical as a tool to iron out the differences. When the teams see the visual outcome and provide their feedback, it builds their trust in the design strategy. Conversely, that trust is eroded when design remains merely a scientific hypothesis, something that makes sense but whose validity in the context of the SOW remains unclear.

A design-intent guide addresses both problems. Created before the UI is built, it records the intent behind decisions made at the boardroom level and sets out the roadmap of the design phases, making the handoff from sketches to spec more credible. It closes the gaps and doubts that surface when design specs are drawn up during or after discussions related to the SOW.

There is a type of document that is commonly mistaken for a strategic record, the UI style guide. It is a repository of elements maintained by a design team that often works in a silo, created to make development teams aware of the design language. It differs from the design-intent guide this article is about.

In a different engagement, a large pharmacy retailer was upgrading an enterprise application from a legacy system to a next-generation portal, and the offshore developers were scrambling for answers. They were shown threadbare PowerPoint ‘prototypes’ that displayed the UI components but lacked the product description a prototype normally carries. There were also incompatibilities between certain UI components, and constraints on implementing a standard colour palette for consistency; I studied all of this, reviewed it with the stakeholders, and documented it in a style guide with pixel-level dimensions.

Here the style guide solved a real problem, giving the offshore team a precise, pixel-accurate specification to build from. It answered what the interface should look like, but not why it was designed that way, and that is the gap a design-intent guide is meant to fill. As a result, the developers could reproduce the interface exactly, but without knowing which decisions it embodied. A specification can be followed perfectly and still lose the strategy it was meant to serve.

3. Decisions, Not Styles

A strategy is at the heart of a successful user experience in enterprise application systems, but it could be lost if compromised for time or any other constraints. In that same pharmacy engagement, my objective was to review and declutter the UI prototypes, which had been made by business analysts whose expertise was pharmacy operations, not prototyping. I reviewed the 20 to 30 screens by walking through the journey a store-level user would take. The company had also decided to disable pointer devices and rely solely on keyboard shortcuts, and it was certain that the business users could memorize them. At first impression, it appeared that the business leaders had traded quality of experience for crammed screens carrying content and action items in an effort to save time per prescription transaction.

However, I could see a concern with elderly users who would be left confused by the ‘innovative’ keyboard-only interaction. Cramming information on a single screen was another challenge that I raised at the appropriate level. I proposed redesigning one complete user journey from one of the use cases, separating the crammed screen elements from one screen and organizing them logically into three screens; the journey was now longer, but the content was comprehensible. After I presented it to the business leaders, they rejected it because of the longer interaction. The other reason mentioned to me was the tight schedule and lack of budget to rework the previously approved screens, although they acknowledged the soundness of the design, which applied usability principles fully.

The style guide described earlier was built on the basis of the approved screens, but the decision that prevented the redesign of the screens was never recorded, and the developers were not shown the redesigned interaction. They received a style guide with specifications for the previously approved screens.

The style guide did its job, since it made the output consistent, but what it could not make consistent was the judgment. Behind every visible element sits a decision, whether a constraint on what the product may become, a choice about the language it speaks, or a principle about how it is organized. A style guide records where the decision ended up, but it says nothing about the decision itself.

In consulting engagements where time is at a premium and schedules are held within strict budget margins, cutting features or compromising the user experience is not an anomaly. Business leaders acknowledge the value of following usability and UX principles when I show them innovative functions; however, they become anxious when I mention that the timeline or budget would be exceeded if they decided to approve it. Does the refusal to extend the timeline or budget denote the idea was irrelevant? Just like the style guide that records the specifications of the final output, there must be a place to record the intent behind each feature, because without a documented record of the intent, the team knows what each feature does, not what it is for. When time runs short, someone decides what to cut, and the only question is whether they know what the product is for. The people deciding what to cut, and the team inheriting the result, both need the intent.

A design-intent guide would have recorded the redesign, the concern about elderly users, the reason it was set aside, and the condition under which it should be reconsidered. The idea would have been deferred, not dismissed, and years later a team facing the same screens could see what was proposed, understand why it was shelved, and judge whether those constraints still apply, without my needing to be in the room. To be usable under pressure, the guide also has to say which decisions are non-negotiable and which are flexible. For a short, stable project, a style guide may be enough, but a design-intent guide earns its place when teams are distributed, the project is long-lived, or requirements are likely to change.

The difference between the two documents is easiest to see side by side.

Without a design-intent guide, a style guide records the outcome of decisions nobody can see. The style guide implements what the design-intent guide decides.

4. What a Design-Intent Guide Contains

At the outset, a design-intent guide doesn’t need to be long; it needs to be readable. The document must answer questions about the strategic design decisions that were approved, put on hold, or dismissed outright in business meetings, and approved decisions move on to further deliberation or implementation.

The design-intent guide is a record of the decisions that affect system functionality or what users can do. For instance, in the first engagement, a new member of the management team proposed drag and drop navigation to replace the tabs structure. I advised against it, because the staff would be working on a tablet in a very busy environment, where a new style of navigation would add confusion and motor control would matter most. I raised the concern with a manager at the client organization, then with the client’s project manager onsite, and then set it out in an email to the senior people on the project. His proposal had already been accepted by the time I met him at a second focus group of decision makers, and the tabs structure was set aside as outdated. Another example, discussed earlier in this article, was breaking the interaction into three screens in the pharmacy engagement to declutter the content, which would have given users more room to focus on the task without distraction; however, it was discussed and set aside in favour of saving time per prescription. Both decisions came from business leaders weighing real pressures, and in the context of the transactions the enterprise systems handled, those pressures carried weight. The success of both engagements rested on user-centred design, which is why my consulting services were needed. From that perspective, each decision had to be weighed against the users’ mental models, the value of the feature in relation to the system objectives, and the users’ demographics. Nonetheless, both decisions were worth documenting in the design-intent guide for future deliberation by management and development teams. A deferred decision could be implemented in the next redesign phase, and any of them could serve as a strategic design resource for internal teams.

Principles of User-Centred Design

The design-intent guide has to be clear on the principles of user-centred design that apply to the design work at hand. The principles get documented for a few reasons. They show that a decision was not driven by aesthetics alone but rooted in user research, to provide interaction value to the end user, and they let the team learn about the types of users and the end objectives of a specific journey. Together, the user journeys make up an interaction model for the enterprise system. In short, when a journey is divided into several routes and each is reviewed for the task it allows users to accomplish, some may be approved, put on hold, or dismissed for reasons that are purely circumstantial to the business requirements, and all of these are recorded in the design-intent guide for posterity.

Decision-making

What prompted the business leaders to approve, suspend, or dismiss a user journey? What was the intent behind that strategic call? Was it related to aesthetics alone, or was it a compelling business decision? In making a decision, were the leaders made aware of the user demographics, the application objectives, the ecosystem (platforms, networks, and third-party apps), and the implications of their decision for the final product? The answers to these questions should be recorded in the design-intent guide to steer teams toward a fruitful conversation.

Priority Decisions

The business decisions taken in deliberations with stakeholders on the enterprise system are listed in a draft design-intent guide, together with their corresponding design principles (UX or usability) and the proposed decisions. What remains is to assign a priority level to each, since not every feature is worth implementing given time, resource, and budget constraints. Decisions fall into two groups, negotiable and non-negotiable. A negotiable decision can be discussed further to achieve a goal, while a non-negotiable decision cannot be changed without a formal review. Priority and status are separate; status records where a decision stands, such as approved, deferred, or dismissed, while priority records how firmly it must be held. The development team gains clarity about how critical the features they will soon be programming are, along with insight into the reasoning behind each decision.

Links to the Style Guide

This is the section where the design-intent guide connects each intended pattern and component to the decision behind it, before the user interface is designed. Components and patterns are the building blocks of the UI model. Once the design-intent guide is complete, it links the components and patterns to the decisions taken by the business leaders, and the priority assigned to each component is carried into the style guide after the UI has been designed. The style guide becomes a companion to the design-intent guide, and each component a user might interact with is accounted for and approved by an appropriate authority.

Usage and Misuse Example

In the pharmacy engagement, the teams were working with crammed screens that left little room for the eye to move. The screens were approved at the appropriate levels, and the offshore teams had begun programming. Meanwhile, the onsite team, based where the business leaders approved or deferred decisions, kept adding more elements to the screen. The offshore team had nobody to ask why the screen had been crammed with components covering 10 to 15 tasks.

Consider the offshore team in that engagement. They worked remotely, disconnected from the decision-making at the onsite location, and had no view of the three-screen split of the content. Had they been given a design-intent guide to cross-reference, it would have explained the decisions behind the screens that were approved and those that were deferred or rejected.

A single entry in the guide would look like this.

• Principle: Where users must read before acting, dense content is split across steps so that each screen supports one task.

• Decision: A three-screen journey was proposed to allow an easier, more efficient flow of information. It would have reduced cognitive load, and users would not have been overwhelmed by the amount of information on one screen. The business leaders took a different view of the prototype and weighed the project schedule and budget more heavily.

• Status: Deferred. The business leaders were focused on the delivery schedule and keeping the project on track for the launch.

• Revisit: After the launch, in the next redesign phase, when a decision can be made on the three-screen journey. I proposed keeping it deferred until that decision could be made.

The guide would have helped the offshore development team voice their judgment. Imagine the team has an overcrowded screen and has been asked to add more components to it. The team consults the design-intent guide and finds the principles and the decision to defer the redesign beyond the launch phase. They raise their objections and ask for clarity before adding further content. Without the guide, the screen would have been built as asked, and the deferred redesign would have been forgotten.

The same guide can be misused. A team might read “deferred” as “rejected” and drop the idea from the roadmap, or nobody might review the guide after launch, so it keeps recording conditions that no longer hold.

5. What the First Guide Could Have Carried

In the first engagement, the ideas were captured, the information architecture (IA) was mapped, and the UI for the OMA was designed as planned. A style guide was then created to manage the development phase, but the plan was derailed when management changed the navigation, which in turn changed the journeys and the IA. The effect cascaded, and the style guide stalled and was eventually made obsolete.

The tab navigation was at the heart of the OMA. It kept the dashboard static on an always-open tab while the user continued to multitask in the other tabs, which suited the staff who would use the app on a tablet in a very busy environment. The structure was based on a month of research and data analysis, including interviews with members of the application development team and with management, and the customer’s data, from which I built a persona depicting the end user’s mental model, demographics, and journeys. It became the foundation for the remaining user journeys, and the style guide was built and maintained on those journeys.

Committing to the tab navigation was not an easy decision for management. The company was not confident that it would work seamlessly and wanted more options, which pushed the deadline back and would have affected the underlying content architecture and the IA. Despite hours of prototyping, ideating, negotiating, and planning the next phase of the engagement, I was on the verge of getting the prototypes approved when the plan changed.

The client reviews raised difficult questions about the tab navigation. They stated that the norms of enterprise system UIs were not followed, whereas UI principles are applied case by case, depending on the context of the system and the users’ mode of thinking. In my assessment, the tab navigation fit the IA structure well and violated no usability principle.

Near the end of the engagement, a new member joined the management team and proposed drag and drop navigation. He was not part of the first onsite focus group, which was called to understand the roadmap and review the tab navigation I had prepared. When I met him at a second focus group, I was told that his proposal had already been accepted and that I would have to follow it. I advised against it, because the staff would be working on a tablet in a very busy environment, where a new style of navigation would add confusion and motor control would matter most. I raised this with a manager at the client organization, then with the client’s project manager onsite, and then set it out in an email to the senior people on the project. Management, committed to the tablet experience, felt the tab navigation would look outdated by comparison, so it was set aside, and my team designed and delivered a mockup of the drag and drop navigation, an initial design on screen without the functionality.

A change to a structure that fundamental does not stay in one place, since it spread from the navigation to the content architecture, the IA, and the journeys, and from there to the style guide, which had been built on those journeys and was now obsolete.

A design-intent guide would have kept the evidence at hand. The research, from which the persona and the usability reasoning were derived, would have been available when the validity of the structure was questioned, so the answer would have come from a record and not from an individual’s statement. The guide would also have recorded my concern about drag and drop in a busy tablet environment, which otherwise lived only in conversations and an email, and it would have shown the decision-makers the cost of the change before approval. If it had recorded what depended on the tab navigation, management could have seen that a change touched the journeys and the style guide too.

A design-intent guide would not have prevented the change, and it should not have, since management was entitled to choose a different direction. What the guide would have done is let the proposal be weighed against the recorded evidence and the recorded concern, and let a late arrival read what the structure was based on before replacing it. The change might still have happened, but it would have been made knowingly, which raises the question of how a guide stays useful as plans change, and that is the subject of the next section.

6. Keeping the Guide Alive

Why Guides Die

In the first engagement, the style guide stalled because the structure changed and nothing told it what needed to be updated. A design-intent guide is updated as new information arrives in each phase of the UI design. It is tangible and workable for the programmers, and the corporate team can review progress through it. Decisions are recorded in the guide as they are remodelled, to ensure that the design strategy remains consistent and coherent across teams and enhances the overall user experience. When a guide has no clear owner to decide how it is updated, it dies a slow death. Eventually it loses the confidence of decision-makers and survives only as a PDF.

Ownership

Whenever a user interface is involved, whether in an enterprise project, a brand strategy, or a consulting engagement, the design-intent guide has to be maintained and updated. This requires collaboration between the design, development, and project teams. Therefore, any governance model should ensure that design documentation such as the design-intent guide is owned by a designated person, commonly a design lead or design strategist. However, there also needs to be an oversight authority that signs off on changes before they reach the style guide. The approver reviews the proposed updates against the decisions recorded in the guide, and decides whether they can be passed on to the style guide.

The approver, separate from the owner, could be a product owner or an executive sponsor. This person signs off on changes in the design lifecycle, such as UI screens, user journeys, and navigation models. The more senior the approver, the faster the offshore, onsite, and consulting teams can resolve questions.

Change Rules

As noted in Section 4, a non-negotiable decision cannot be changed without a formal review. Each change records what is changing, the evidence for it, what depends on it, who approved it, and the date. A superseded decision is marked, not deleted, so a future team can still see what was tried and why it was replaced.

As Section 5 describes, the tab navigation was replaced late in the engagement. Under these rules, the proposal would have gone to a formal review, with the evidence and the dependent journeys in front of management, and the cost to the style guide would have been visible before approval, including its likely effect on the budget and the launch date.

Review Points

When should a team review the guide? A review is held before each build phase to understand what is getting built, deferred, or eliminated before it gets documented. Once the product is launched and user studies are conducted, the deferred decisions are revisited to understand whether they fit the journey today. Take the three-screen journey in the pharmacy engagement. The decision not to approve it was justified on the grounds of saving time and budget, and unfortunately, the screens were never saved as a reference for future teams to study. When a new decision-maker joins, they can read what the system’s structure rests on before proposing to replace it. Apart from this, when a new decision is recorded, the guide gives a clear indication of the component or journey it affects.

Keeping It Usable

Having said that, the details shouldn’t overwhelm the reader with unnecessary content. The entries should be short, a page or less, and in the four-field format from Section 4. Every entry must have a date, with its status showing as approved, deferred, dismissed, or superseded. The guide should live where the team already works; a PDF can be exported for portability, but it should not be the working copy. Each style guide component has to be linked to the specific design-intent guide entry that points to the decision behind it. That means a change to a decision points to the components it affects, and all the teams working on the system are apprised of the decision-making process. Because the guide sits upstream, a change to a decision tells the style guide exactly what to update, and in the first engagement, that is what was missing. The offshore teams had no view of the decision-making process. Lastly, governance costs time, and teams under pressure will skip it unless it is light. A short guide with a clear owner will outlast a thorough one that nobody maintains.

7. The Diagnostic Questions

Let me reiterate that a strategy made in one room is only as strong as what reaches the room where it is built. The team that was deciding the next level of the experience left the people who were going to develop it in limbo.

If your team relies on a style guide, these questions will show what it carries and what it leaves behind.

• Does your guide record why a decision was made, or only what was decided?
• Could a developer who was not in the room find the reason behind a design choice?
• Is the guide self-explanatory, or does it need the owner or the approver in the room every time?
• Are deferred and dismissed decisions recorded with their reasons?
• Is there a named owner for the guide, and a separate approver for changes?
• If a late change were proposed tomorrow, would anyone see what depends on it before approving?
• Where does the guide live, and when was it last reviewed?
• Can the onsite and offshore teams reach the guide without difficulty?

In RACE terms (Research, Advisory, Conceptualize, Educate, the framework behind my practice), the design-intent guide is started early, during the Advisory and Conceptualize phases, and handed over in the Educate phase, when the engagement closes with the sharing of knowledge with the client teams and decisions pass to the people who are expected to carry them forward. It is one of the design documents that pass to the designated client team.

A style guide records what was built, but a design-intent guide preserves why, and for a distributed team, the why is what has to travel.

Let's talk about a complex problem.

If you're navigating a transformation, enterprise design challenge, or organisational problem where the answer isn't obvious, let's explore it together.

Get in touch →
Connect on LinkedIn →

#UX #apps #case-study #consulting #design-systems #enterprise #information-architecture #strategic-design