Co-create with AI
Partner with AI to accelerate the design process, enhance creativity, and improve operational efficiency.
Tools
Concept card
The concept card is a translation tool that bridges the gap between the User Perspective (UX) and the Data Perspective (System Logic).
Scope & Details
The Concept Card is a translation tool that bridges the gap between the User Perspective (UX) and the Data Perspective (System Logic). While a Service Blueprint maps the flow, the Concept Card defines the objects within that flow. It forces the team to explicitly define what a "Customer," "Order," or "Project" actually is inside a system. By capturing the specific attributes, ownership, and definitions of each concept early, you prevent the common disconnect where the design team imagines a feature that the data structure cannot support.
Suggested time
1–2 hours per concept
Level of Difficulty
Intermediate – Advanced
Design Phase
Design & Development
Prerequisites
Journey map, service blueprint
Materials Needed
Concept Card template (digital or printed), user research insights, data flow documentation, organisational requirements
Participants
Service designers, product owners, system architects, policy designers, and subject-matter experts
How to do it
-
Start from the User Perspective
Describe the concept through the eyes of the user. Begin with a simple statement such as: “As a [user type], I want to [goal] so that I can [achieve desired outcome].” This ensures the concept remains user-centered and purpose-driven.
-
Define the Concept Functionally
Clarify what the concept is in terms of functionality or system logic (e.g., user account, application process, feedback module). Specify how it operates within the broader service ecosystem.
-
Identify Ownership and Accountability
Indicate which entity, department, or system owns the data or function. This promotes clarity and accountability during implementation.
-
Map Onstage Actions:
List the essential data points or information elements related to the concept — for example, name, ID, contact details, or usage records. Keep these attributes focused on what is necessary for the function to operate efficiently and ethically.
-
Align with Platform Standards
If the service connects with legacy or shared platforms (e.g., national databases or government registries), describe how this concept relates to existing definitions or standards. This step ensures interoperability.
-
Validate with Stakeholders
Review the completed card with both organisational and technical representatives to ensure shared understanding and alignment across perspectives.
-
API & Component Check
Before building, check: Does a service component (e.g. login, payment, feedback) or API already exist for this function? List the reusable assets here.
AI Enhancements
Data Attribute Generation: Feed a user story to an AI (e.g., "As a user, I want to share my design with my team") and ask: "To support this user need, what specific data attributes must the 'Design' object contain? (e.g., Share List, Permissions, Status)."
Gap Analysis: Upload a filled Concept Card and your Service Blueprint text to an AI and ask: "Does the 'Order' concept defined here contain all the necessary data fields to support the 'Verification' step in the blueprint?"
Tips
Keep it human and technical
Always balance user language with precise system definitions.
Avoid duplication
Check if a similar concept already exists within another department or platform.
Link to the Service Blueprints
Use the Concept Card to inform touchpoints and data flows within the blueprint.
Use the real data examples
Populate fields with realistic data samples to ensure clarity.
The "Proactive Child Allowance" Scenario: A team is designing a service to support new parents.
The User Perspective (The Need):
"As a new father, I want to receive the financial support I am entitled to automatically, so I can focus on my newborn without filling out applications."
The Organisation Logic (The Function):
Function: Proactive Disbursement Trigger. (Not an "Application Form").
Logic: If Birth_Registry_Event = New_Entry AND Parent_Nationality = Local, THEN Trigger_Payment.
The Technical Structure (The Data):
Data Source Owner: Health Authority (Birth Registry).
Data Consumer: Social Authority (Finance System).
Required Attributes: Parent Emirates ID, Child DOB, Bank IBAN (retrieved via Central Bank API).
Without this card, the design team was sketching a "New Application Website" (a form). The technical team, seeing the Concept Card, pointed out that building a website was wasteful. The card aligned everyone on a different technical structure: an Event-Based Architecture (API integration) that connects the Hospital system directly to the Finance system. The "Concept" moved from being a website to being a background process, saving development time and fulfilling the "Zero-Touch" user need.
Related Service principles
Our service principles that relate to concept card.
Previous
Service blueprint
Next
Test card