One of the first documents I create for every client engagement is an Engagement Deck.
I did not invent the practice. I learned it early in my career from a manager who insisted that every engagement deserved a single place where context, decisions, deliverables, risks, and stakeholder communication came together. At the time, I was working on large enterprise engagements involving global organisations, long project timelines, and substantial budgets. Maintaining such a document seemed like a natural part of the process.
Over the years, I adapted that practice to suit my own way of working. Today, my engagements are often much smaller. They may involve startups, product teams, or focused consulting assignments that last only a few weeks. Ironically, those are the projects where I occasionally find myself wondering whether creating an Engagement Deck is really worth the effort.
Every time I have decided to skip it, experience has reminded me why it remains one of the most valuable documents I maintain.
The temptation is understandable. When timelines are short and budgets are limited, an Engagement Deck can feel like administrative work. It is easy to convince yourself that the real value lies in producing wireframes, research findings, prototypes, presentations, or design specifications. After all, those are the deliverables the client is paying for.
Experience has taught me something different.
The deliverables explain what was built. The Engagement Deck explains why the engagement unfolded the way it did.
That distinction becomes more important as projects become more complex. Conversations happen across meetings, emails, chat messages, presentations, and collaborative tools. Requirements evolve. New stakeholders join midway through the engagement. Priorities change. Decisions that were perfectly clear three weeks ago become difficult to reconstruct because everyone remembers them slightly differently.
An Engagement Deck brings all of those threads together into a single, evolving narrative.
It is not a presentation that is created once and forgotten. It is a living document that grows throughout the engagement. Sometimes it grows beyond a hundred slides. Every important meeting, every significant decision, every deliverable, every risk, every important piece of stakeholder feedback eventually finds its place within it.
That does not mean I send a hundred-slide presentation to my clients after every meeting.
The master Engagement Deck remains my complete record of the engagement. Whenever I need to share progress, I extract only the handful of slides that are relevant to the current discussion. Clients receive concise updates focused on the latest decisions or deliverables, while the complete history remains preserved in the master document.
Over time, I realised that I was not maintaining this document because a process required it. I was maintaining it because it consistently made me a better consultant.
Looking back across dozens of engagements, I realised that the Engagement Deck does far more than document a project. It helps maintain six things that determine whether an engagement progresses smoothly or gradually becomes harder to manage:
- Context
- Continuity
- Perspective
- Expectation Management
- Alignment
- Ownership
The first of these is also the one that many teams underestimate.
An Engagement Begins with Context
Before I think about personas, user journeys, information architecture, or interface design, I spend time understanding the organisation I will be working with.
Who are the stakeholders? What business are they in? Where are they located? Which business unit owns the project? Who will influence decisions? Who will ultimately approve the work? What commercial or organisational pressures are shaping the engagement?
Some of this information is functional. Some of it appears cosmetic. I often include organisational details, leadership information, photographs of key stakeholders where publicly available, and maps showing the company's geographical presence.
Those slides are not there simply to make the presentation look impressive.
They communicate something much more important.
Understanding the client is the first design activity in every engagement.
When clients see that effort, they recognise that you are trying to understand their business rather than merely complete a design assignment.
Equally important, it changes the way I think about the engagement. Instead of seeing a collection of design tasks, I begin seeing the organisation, the people, and the business context that those tasks are intended to serve.
That context becomes the foundation for every decision that follows.
Every Project Needs Continuity
Most projects do not suffer from a lack of communication. In fact, they usually suffer from too much communication spread across too many places.
Requirements arrive during workshops. Decisions are made during review meetings. Feedback is shared over email. Quick clarifications happen over chat. Deliverables live in design tools. Action items find their way into project management software. Weeks later, everyone remembers fragments of those conversations, but very few people remember the complete picture.
The Engagement Deck became my way of preserving that picture.
Whenever there is a significant interaction with the client, I update the deck. If we conduct a workshop, I capture the key outcomes. If requirements are discussed, they become part of the engagement record. If a deliverable is reviewed, I include screenshots, links to the latest version, and the feedback received. If an important decision is made, I record not only the decision itself but also when it was made and who made it.
This is not about creating exhaustive meeting minutes. It is about preserving the decisions that shape the engagement.
Once updated, I share the relevant extract with the client and with everyone involved in the project. That serves two purposes. First, everyone remains informed about the current state of the engagement. Second, it creates an opportunity for misunderstandings to be corrected while the conversation is still fresh.
An Engagement Deck is not a record of everything that was said. It is a record of what everyone agreed the engagement should move forward with.
That distinction becomes invaluable over time.
Months into a project, it is surprisingly common for someone to ask why a particular design decision was made. Sometimes it is a stakeholder. Sometimes it is a manager reviewing the work. Sometimes it is a designer who has recently joined the team.
Without a single source of truth, those conversations usually begin with people searching through old email threads or trying to reconstruct discussions from memory.
With an Engagement Deck, the answer is usually only a few slides away.
The discussion changes from trying to remember the past to understanding the reasoning behind the decision.
Perspective Comes from Seeing the Whole Engagement
This is perhaps the benefit I appreciate the most today, and it is one that I did not fully understand when I first started maintaining an Engagement Deck.
Most designers experience projects as a sequence of tasks. One week is spent conducting research. The next is focused on wireframes. Then come visual designs, stakeholder reviews, revisions, and handoffs. Each activity feels independent because it demands our immediate attention.
An Engagement Deck changes that perspective.
When every significant conversation, requirement, decision, deliverable, and piece of feedback exists in one place, the engagement stops feeling like a collection of disconnected activities. It becomes a coherent story.
That broader perspective has helped me anticipate problems long before they reached the client.
I remember working on the branding for a product in the retail industry. During an early discussion, the client was very clear about what they wanted. They wanted a logo that incorporated a human figure and they had specific expectations about how the brand name should be written.
As I explored different concepts, I arrived at a completely different solution. I believed it better represented the product and would create a stronger identity in the market.
Had I simply walked into the presentation and shown the new logo, I am fairly certain the first response would have been, "This isn't what we asked for."
The Engagement Deck made me realise that long before the meeting.
Because the original brief was documented alongside my evolving work, I could immediately see the gap between the client's expectation and the direction I had chosen.
That gave me something far more valuable than documentation.
It gave me time to think.
Instead of preparing to defend my design, I prepared the conversation that needed to happen before I showed the design.
I began the presentation by acknowledging the client's original request. I then showed examples demonstrating how commonly that particular visual approach was used. I presented references and industry guidance explaining why the proposed typography would reduce distinctiveness. Only after establishing that context did I present the logo I had designed and explain how it addressed the same business objective in a stronger way.
I was able to pre-empt an objection that could have made that conversation unpleasent.
The client approved the concept during that meeting because they understood not only what I had designed but why I had chosen a different direction.
The Engagement Deck did not help me defend my design. It helped me anticipate the stakeholder's perspective before the meeting even began.
That experience fundamentally changed the way I viewed the document.
It was no longer simply preserving project history. It had become one of my most valuable thinking tools.
When every important aspect of an engagement is visible in a single place, patterns become easier to recognise. Contradictions become easier to spot. Risks become easier to anticipate. Most importantly, it becomes much easier to step away from individual tasks and see the engagement as a whole.
Expectations Are Easier to Manage Than Disappointments
One of the responsibilities of a design leader is to help stakeholders make informed decisions.
That sounds obvious until a project begins operating under constraints.
Business priorities change. Deadlines move. Budgets are reduced. New features are added midway through the engagement. Clients are often forced to make difficult decisions because the realities of the business leave them with very little choice.
In those situations, I have found that designers sometimes make an understandable mistake. They focus on protecting the design process instead of understanding the business problem that the client is trying to solve.
One engagement reinforced this lesson for me.
I was leading the UX work for a contact centre platform that was undergoing a significant redesign. We had agreed on a delivery plan based on two-week design sprints. Shortly after the project began, the client asked whether we could halve the sprint duration.
The request immediately created concern within the design team. Compressing the timeline meant less time for exploration, validation, refinement, and review. The initial reaction was that the client was rushing the project.
I looked at the situation differently.
The client was preparing for an important business event and wanted the product to be ready for that milestone. Their request was not unreasonable. They were trying to achieve a business objective, and our responsibility was to help them reach it as effectively as possible.
The challenge was not whether we could work faster. The challenge was ensuring that everyone understood what working faster would mean.
Instead of responding through email or discussing it verbally, I documented the situation in the Engagement Deck.
One slide compared our original two-week delivery plan with the revised one-week approach. The visual timeline immediately showed how activities that normally had room for iteration would now have to happen in parallel or be reduced in scope.
The next slide focused on something even more important.
It explained the trade-offs.
We discussed what additional time would normally allow us to achieve—more exploration, more refinement, more validation, and ultimately a higher level of confidence in the outcome. We also discussed what would inevitably be reduced if we compressed the schedule.
The conversation was no longer about whether the design team wanted more time.
It became a discussion about priorities.
Good stakeholder communication is not about defending your process. It is about making trade-offs visible before decisions are made.
Once the trade-offs were clearly presented, the client made an informed decision. They acknowledged the impact on quality, accepted the compromise, and chose to proceed with the accelerated timeline because meeting their market commitment was more important.
What happened afterwards was equally important.
Throughout the compressed delivery, we never had difficult conversations about unmet expectations because those expectations had already been established before the work began.
Nobody was surprised.
The Engagement Deck had transformed a potentially difficult negotiation into a shared business decision.
That experience reinforced another lesson for me.
Clients rarely expect perfection under every circumstance. What they expect is clarity. If they understand the implications of a decision and consciously choose that path, the engagement becomes collaborative instead of adversarial.
Alignment Is Something You Maintain, Not Something You Achieve
One misconception I held earlier in my career was that stakeholder alignment was something you accomplished during the initial phases of a project.
Experience has taught me otherwise.
Alignment is temporary.
Every new meeting, every new stakeholder, every design review, every changing business priority has the potential to shift the engagement in a slightly different direction. Left unmanaged, those small shifts accumulate until different people begin operating with different assumptions about the same project.
The Engagement Deck has become the mechanism through which I continuously restore that alignment.
After every meaningful discussion, I update the master document. New requirements are added. Decisions are recorded. Risks are highlighted. Deliverables are linked. Feedback is captured. The latest extract is then shared with the relevant stakeholders so that everyone moves forward with the same understanding.
This continuous communication creates something that is surprisingly difficult to achieve through meetings alone.
It creates a shared narrative.
When someone joins the project midway through, they do not inherit a collection of disconnected documents. They inherit the story of the engagement.
When a senior manager asks why a particular decision was made, the answer is not based on memory. The reasoning already exists within the engagement record.
When a client revisits an earlier discussion, the team does not need to reconstruct weeks of conversations. The relevant context is already available.
The Engagement Deck becomes the single thread connecting every important milestone in the project.
That is why I no longer think of it as documentation.
Documentation preserves information.
An Engagement Deck preserves understanding.
Ownership Cannot Be Delegated
There is one final lesson that took me several years to fully appreciate.
Many designers look at an Engagement Deck and assume that maintaining it is administrative work. Because of that, there is a natural temptation to delegate it to someone else on the team.
I believe that is a mistake.
An Engagement Deck is not a clerical document. It is a leadership document.
Its value does not come from recording information. Its value comes from connecting information that originates from different people, different activities, and different stages of the engagement.
That is only possible if it is owned by the person who has the broadest understanding of the project.
If a project has two designers, one of them naturally becomes responsible for maintaining the Engagement Deck because that person has visibility into the complete engagement.
If the team includes senior designers, the responsibility moves to the senior designer.
If the project involves multiple UX designers, visual designers, UX writers, researchers, and a design manager, then the ownership belongs with the design manager or design lead.
In other words, ownership delegates upwards, not downwards.
An Engagement Deck should be owned by the person who owns the design engagement.
That person understands not only what every member of the team is producing, but also why priorities changed, which risks have emerged, what commitments have been made to the client, and how every workstream contributes to the overall engagement.
No individual contributor has complete visibility into that picture because they should not have to. Their responsibility is to deliver their part of the work exceptionally well.
The responsibility of maintaining the story of the engagement belongs to its leader.
From Documentation to Leadership
When I first started maintaining an Engagement Deck, I viewed it as another process to follow.
Over time, it became something very different.
Today, it is the first document I create for every engagement because it helps me think more clearly, communicate more effectively, anticipate stakeholder concerns, make better decisions, and keep everyone aligned throughout the project.
It has become the operating system for my consulting engagements.
Interestingly, I still occasionally question whether I should create one when the engagement is small. The temptation to skip it has never completely disappeared.
Experience, however, has been remarkably consistent.
Every time I have invested the effort to maintain an Engagement Deck, it has repaid that effort many times over. Every time I have convinced myself that the project was too small to justify it, I have eventually found myself wishing I had created one.
That is why I no longer think of it as documentation.
I think of it as one of the most important design deliverables of the engagement, even though the client may never see the complete document.
Deliverables explain what you built. An Engagement Deck explains why the engagement unfolded the way it did.
The quality of a consulting engagement is not determined only by the quality of its design outputs. It is also determined by how well context is preserved, decisions are communicated, expectations are managed, and stakeholders remain aligned from the first conversation to the final delivery.
For me, the Engagement Deck has become the document that quietly holds all of those pieces together.
