Agree what may be shared
Get permission for the client name, screenshots, quotations and any business data before drafting. Clarify restrictions on confidential systems or customer information. If a project must remain anonymous, describe the context accurately without implying a larger engagement. A concept study should remain labelled as a concept, even when its visual presentation resembles finished client work.
Explain the starting problem and scope
Describe what was happening before the project and what your team was asked to change. Separate your contribution from work done by the client or other suppliers. Include constraints that explain the decisions, such as a fixed platform or a migration requirement. This makes the case study useful beyond a gallery of polished screens.
Qualify outcome measurements
Use only figures supported by records and permission. State the measurement period, baseline and important limitations. If several changes occurred together, avoid claiming your work alone caused the result. Where no reliable business metric exists, describe verified delivery outcomes, such as a completed migration or an agreed workflow, without inventing a percentage improvement.
Make the lessons reusable
Explain one or two decisions another business could learn from. Show the relevant service and invite a conversation about a similar problem. Ask the client to approve the final version and record that approval. Revisit the page if the project changes or a permission is withdrawn; publication rights and accuracy need continuing attention.
Your practical checklist
- Record publication permissions
- Define the problem and your actual contribution
- Support metrics with dates and evidence
- Approve the final version and review ownership
Working through a similar question?
We’re happy to help you find a practical starting point.
Talk to AMGK