How I Work — Kamala Espig

Process

Design that holds up
under scrutiny.

My work focuses on systems thinking, tradeoffs, and risk mitigation — not just shipping screens, but shaping how products evolve responsibly. I'm most effective in ambiguous, high-stakes environments where clarity, judgment, and collaboration are the actual deliverable.

See the work →

Design process — working through a problem

Context

Where I do my best work

The common thread across every engagement where I've done meaningful work: the work needs to be right. Not just shipped — right.

→ The problems are complex and consequential — interfaces where a misread visualization or unclear AI output has real downstream cost

→ Design is treated as a strategic partner, not a production service — brought in before requirements are locked, not after

→ Collaboration across product, engineering, and domain experts is essential — I work best when everyone has real context and real stakes

→ Decisions need to hold up under scrutiny, not just ship quickly — I care about the reasoning as much as the output

→ The outcome matters more than the deliverable — I'm not here to produce artifacts; I'm here to make the product better

My Process

Consistent rhythm.
Flexible execution.

Every project is different. My process follows a consistent rhythm regardless — understand before you shape, map tradeoffs before you commit, document decisions so the team can build on them.

Discover

Understand the system

Map the technical constraints, user context, and business stakes before shaping anything. Ask the questions no one else is asking — especially the ones about failure modes.

Define

Clarify the problem

Identify mental models, surface assumptions, and align the team around what we're actually solving — not just what was requested. The brief is a starting point, not a constraint.

Explore

Map tradeoffs

Generate options that reflect real constraints. Weigh them. Pressure-test them. Don't fall in love with the first elegant solution — find the one that holds under edge cases.

Deliver

Design for real use

Build for the edge cases, the power user, the analyst at 2am who's been looking at the same dashboard for six hours. Not the ideal state — the messy, real-world one.

Evolve

Document decisions

What was decided, why, and what was ruled out — so the team can build on it and revisit it intelligently when things change. Good documentation is future design work that doesn't have to happen twice.

Working Style

How I show up

I think of myself as a design strategist embedded in a product team — not a service bureau. I push back when I see the wrong problem being solved. I raise usability concerns before they become launch problems. I write documentation so design decisions don't disappear between sprints.

I own the design function at a 30-person company — which means no design team to hand things to, and engineering, product, threat intelligence, content, and customer success in every decision. Most of my week is spent working with people who aren't designers. Engineers route interaction decisions to me on work I'm not assigned to. That's the part that isn't in the job description.

Collaboration

Daily pairing with engineers, embedded in sprints, present for engineering reviews — design as a team sport, not a handoff

Communication

Decision documentation in tickets, design rationale in PRs, async-first with sync when the complexity requires it

Feedback

Direct, specific, actionable — I give it and I want it. Vague feedback is a bottleneck

Speed

Fast enough to keep the team moving, slow enough to catch what causes rework at launch — those aren't the same speed

Research

Enterprise customer validation, research synthesis, heuristic analysis, domain expert partnerships — evidence before opinions

Leverage

Design systems, written implementation references, AI tooling — work that outlives the hours I can personally put in

AI-Assisted Design

AI as a thinking partner,
not a shortcut.

AI is part of how I work now — for prototyping, ideation, content scaffolding, research synthesis, and pressure-testing my own assumptions. I don't treat AI-generated output as finished work. I treat it as a fast path to the right conversation.

Being the only designer on a 30-person team means output has to scale past what one person can draw. I wrote my team's guide to AI-assisted concepting — prompt templates, design system guidance, and a hard rule: no real customer data near a generative tool in a security product. In this domain, that last part isn't a footnote. It's the whole question.

How I use it

Claude

Content architecture, decision documentation, research synthesis, critique partner — thinking out loud with a fast memory

ChatGPT

Workflow automation, connected-source research, prompt scaffolding — integrated with Jira, Confluence, Slack, GitHub

Cursor · Claude Code

React and HTML/CSS prototyping, production front-end work, rapid interactive mockups

Figma Make

Early concepting and prototype generation — governed by documented prompt templates and fictional-data guardrails

Midjourney

Visual direction exploration, moodboarding, concept validation

Currently

Working on the systems layer of a complex enterprise product — the kind of work that raises quality across a team and scales well beyond any single screen or sprint.

The goal is always to make the next designer's job easier, not just to ship the thing in front of me.

Design that holds upunder scrutiny.

Where I do my best work

Consistent rhythm.Flexible execution.

How I show up

AI as a thinking partner,not a shortcut.

Let's talk aboutwhat you're building.

Design that holds up
under scrutiny.

Consistent rhythm.
Flexible execution.

AI as a thinking partner,
not a shortcut.

Let's talk about
what you're building.