Design Thinking
Frames the problem before a solution is assumed. It keeps divergent and convergent thinking explicit, so teams can compare process, platform, policy and build options with the same evidence.
Design Thinking
Design services for enterprise AI and CX
Humint Labs works with enterprise teams to diagnose journeys, design conversations, shape agentic behaviours, prototype interfaces and hand delivery teams the artefacts they need to build safely. The work starts before a platform is named, so the design can still say to fix a process, change ownership or buy nothing.
Design practice
What the design practice does
The design practice covers the services enterprise teams usually need before an AI or automation programme can be scoped responsibly. Some engagements use one service. Others combine several into a discovery, prototype or delivery-readiness phase.
01
Service blueprinting
Map the customer action, assisted channel, backstage team, policy step and system of record on one timeline, so current-state and target-state blueprints surface failure points and duplicate effort before a build starts.
02
Conversation design
Design the language, repair paths, confidence thresholds and escalation moments for chat, voice and assisted-agent experiences, including intent taxonomies and handoff payloads for human agents.
03
Agentic experience design
Shape how autonomous systems reason, request permission, explain their work and return control to a person, with defined autonomy levels, tool-use confirmation and operator views for status and audit.
04
Generative UI and interface design
Design interfaces that adapt to intent, evidence and task state without becoming unpredictable or hard to govern, including review screens for generated content or actions.
05
Journey diagnostics
Find where a customer, employee or operator journey is blocked before a team commits to a platform or build, through stakeholder interviews and constraint mapping.
06
Prototype and testing
Create testable artefacts early, then validate comprehension, trust, failure handling and operational fit before engineering scale-up.
07
Governance and handoff design
Turn design decisions into acceptance criteria, release gates and delivery handoff packs that product, engineering and operations teams can build and review against.
How Design Thinking, Human-Centred Design and Service Design work together
The methods are complementary, not competing labels. Humint Labs uses them to keep enterprise AI and CX work grounded in evidence, usable behaviour and operational reality.
Human-Centred Design
Tests whether customers, employees and operators can understand, trust and recover from the experience. It keeps real behaviour in the room, especially when AI introduces uncertainty.
Service Design
Connects channels, teams, policies, systems and handoffs. It shows whether an AI or CX change improves the whole service or simply moves work somewhere less visible.
When the work involves autonomous or semi-autonomous behaviour, the design page connects into Agentic Experience (AX) Design, which focuses specifically on control, permission, explanation and operator review for AI agents.
Where teams bring us in
Design is usually brought in when a team can see the commercial value of AI or automation, but the service risk is not yet understood. The work creates a shared brief for executives, product owners, delivery teams, risk teams and operations.
A contact centre wants AI without moving work sideways
Humint Labs maps the whole service path before designing containment, escalation and agent-assist patterns. The goal is not simply fewer calls. It is fewer avoidable contacts without creating a new backlog in email, complaints or back-office review.
A product team wants an agentic feature, but cannot define control
The design work sets what the agent may do, when it asks permission, what it explains, and how a person stops or corrects it. The output gives engineering a controllable behaviour model rather than a broad autonomy ambition.
A regulated team needs generated answers people can trust
The engagement defines answer boundaries, retrieval evidence, refusal language and review points. It turns policy and risk expectations into interface behaviour, not a late compliance checklist.
A service owner suspects the problem is not technology
Journey diagnostics separate process constraints, policy constraints, data constraints and platform constraints. If the recommendation is to buy nothing, consolidate a step or change ownership, that finding is kept in the report.
A delivery team needs handoff artefacts that survive the build
Blueprints, flows, prototype findings and acceptance criteria are written for product, engineering, risk and operations. The design work is not a presentation layer. It is the operating brief for delivery.
From ambiguity to a buildable brief
Design work turns a loose service problem into artefacts that executives, risk teams, product owners, engineers and operations can inspect before build money is committed. The same path works whether the answer is AI, automation, process redesign or doing nothing yet.
Signal
Business signal
The commercial pressure, service failure, customer effort or operational queue that makes the work worth looking at.
Diagnosis
Journey diagnosis
The current-state service path, channel evidence, decision points, ownership gaps and constraints that explain why the issue exists.
Object
Design object
The blueprint, flow, intent map, prototype or operator surface that turns ambiguity into something reviewable.
Boundary
Decision boundary
The explicit call on what to build, buy, fix, pause, escalate or govern before delivery teams commit capacity.
Handoff
Delivery artefact
The acceptance criteria, release gate, operating rule or backlog input that survives into build and service ownership.
01
Diagnose
Interview stakeholders, walk the journey, review channel evidence and locate the work that is currently hidden, duplicated or blocked.
Output: Current-state blueprint, effort map and constraint register
02
Frame
Define the customer problem, operational problem, policy boundary and commercial decision. This is where buy, build, fix or stop options are made explicit.
Output: Problem frame, opportunity brief and decision criteria
03
Design
Shape the conversation, interface, agent behaviour, handoff and governance patterns that the service needs before engineering begins.
Output: Conversation flows, intent maps, UI patterns and autonomy rules
04
Prototype and test
Build just enough of the experience to test comprehension, trust, service fit, escalation paths and operational handoff with the right users and teams.
Output: Prototype, test findings and prioritised iteration list
05
Handoff and govern
Translate design decisions into delivery artefacts, acceptance criteria, release gates and operating guidance for product, engineering, risk and operations.
Output: Delivery handoff pack, governance rules and build backlog inputs
What the work looks like
The work is made tangible through artefacts that product, risk, operations and engineering teams can review together. A service blueprint shows where work moves. A conversation flow shows what happens when language fails. An intent map shows where ownership and routing collide.
Service blueprint, cross-channel
A blueprint puts the customer's actions, the frontstage they see, the backstage nobody shows them and the systems of record on one timeline. It is the artefact that finds work happening twice, such as the identity check a customer completes in the app and then repeats to an agent minutes later. It is also the artefact that locates the bottleneck, such as a decision stage where a single approver gates every case.
- What it reveals
- Where effort, delay, policy and ownership sit across the full service path.
- Who uses it
- Service owners, product teams, operations, risk and delivery leads.
- Decision it enables
- What to fix, automate, redesign, remove or govern before a platform is chosen.
Scroll diagram horizontally
Conversation flow with error and repair paths
A conversation design is mostly the paths that are not the successful one. The decisions that matter are what happens on a low-confidence match, how many times the system may reprompt before it stops trying, how a repair prompt is worded so it does not read as an accusation, and what travels with the customer at handover. A flow that draws only the successful route is a demonstration, not a design.
- What it reveals
- Where language fails, confidence drops, customers need repair and agents need context.
- Who uses it
- Conversation designers, CX owners, contact centre teams and engineering squads.
- Decision it enables
- What the system says, refuses, escalates, retries and hands over.
Scroll diagram horizontally
Intent map
An intent map exists to find the collisions. Intents that overlap in language are the ones that misroute, and they are rarely found by reading the intent names. They are found by putting the taxonomy on one canvas and asking which pairs a real person could phrase the same way. The map also draws the boundaries between domains, which is where ownership arguments happen and where routing quietly breaks after a reorganisation.
- What it reveals
- Which intents collide, which domains own them and where routing will break.
- Who uses it
- Knowledge, data, AI, service and contact centre platform teams.
- Decision it enables
- How to group, split, route, measure and govern intents across channels.
Scroll diagram horizontally
How design reduces delivery risk
The engagement keeps diagnosis separate from prescription. It follows the real journey, names the constraints, and turns the design decisions into artefacts a delivery team can build and govern.
Platform-first decisions
A platform is named before the journey, policy boundary or operating model is understood. Design keeps the problem definition independent for long enough to test whether the proposed platform is actually the right answer.
Work moving out of sight
A visible queue improves while the work reappears in email, complaints, exceptions or manual review. Service blueprinting shows the full path, so success is measured across the service rather than one channel.
Autonomy without control
A feature is described as agentic before anyone has decided what it may do, what it must ask about, and how a person interrupts or reviews it. Agentic experience design turns those decisions into behaviour and interface rules.
The practitioner behind the practice
Design at Humint Labs is led by co-founder Krisha Patel, who also runs delivery, so the person who writes the diagnosis is accountable for the build that follows it. Krisha holds a Swinburne University of Technology research award for service design and has taught design thinking and human-centred design there, with a practice spanning UX, interface design, generative interfaces and conversation design since 2009.
That keeps research in the room through delivery instead of it getting traded away in a backlog refinement session, and sets the bar for the work itself: a blueprint should hold up to people who didn't draw it.
Design engagement FAQs
What to expect from a design engagement with Humint Labs