Every mature product shares an open secret: it’s not one product. It’s layers of products, built on top of each other over time. Teams ship features, each designer picks components that make sense in context, and years later you have a product that works well, it just doesn’t always agree with itself in the details. One banner has an icon, its twin doesn’t. Nobody decided this, it’s the natural side effect of a product that ships fast and grows.

The traditional fix is a component audit: screenshot everything, paste it into a giant Figma file, squint at it for weeks, write recommendations. Valuable work that nobody has time for, which is exactly why it doesn’t happen often.

What changed is that today’s tools make the tedious parts of an audit (finding, cataloguing, cross-checking) dramatically cheaper than they were even a year ago. The audit that was never worth three weeks is absolutely worth a few days.

The problem with auditing by hand
An audit has three painful phases, and the first one is the killer: finding everything. You can’t audit what you can’t see. And in a large product, components hide everywhere, so manually hunting them down means clicking through the entire product, several times, with different account types.

But here’s the thing: every component that exists in the product also exists somewhere else, in the codebase. The repo doesn’t need a specific permission set to render an edge case. The repo is the complete, honest inventory of everything we’ve ever shipped. So instead of hunting through the UI, I went to the source.

Step 1: Build the inventory from the codebase

My first move was pointing Claude Code or Cursor at our repository with a simple mission: run through the repo, find the latest UI components in use, and generate them visually so I can see them all in one place.

Instead of spending weeks screenshotting, I had a visual inventory of every variant that actually ships, pulled straight from the code and rendered so I could evaluate it with designer eyes. It didn’t always match the live UI 100%, which is exactly when it helps to review it with the team and check whether any variations are missing or no longer valid.

For labels and pills, that inventory came to around 50 cases. For alerts and banners, around 60. Numbers I would never have confidently reached by clicking through the product. And this step, the one that used to consume most of an audit’s timeline, took a fraction of the time. That’s the shift: the inventory is no longer the bottleneck.

Step 2: Group, compare, validate

Finding everything is only the setup. The real design work is making sense of what you found, and this is where I moved from Claude Code to Claude Cowork, working side by side rather than delegating.

Grouping
We clustered the 50 pill cases and 60 alert cases by what they were trying to do, not what they looked like. This reframing matters: two visually different pills doing the same job are one component with an identity crisis, not two components.

Finding inconsistencies
With everything grouped by intent, the cases worth a second look surfaced quickly: an outlier color here, a variant there that had drifted slightly from the pattern. Most cases confirmed the system was working; the exercise made the exceptions easy to spot and discuss.

Validating proposals
This part surprised me most. When I proposed a consolidation or redesign, I could pressure-test it against the full inventory instantly. If I merge these variants, which cases break? That’s a question that used to take a day of cross-checking. Now it took a conversation.

And one step that sits around all three: sharing with the team. Once the groups and proposals took shape, sharing them with other designers and asking each one for a quick check on the areas they know best. They catch the context no inventory can, why a variant exists, which flow depends on it, what’s already changing in their space. It turns the audit from one person’s opinion into a team decision.

The result
Of the ~50 label and pill cases, roughly 25 were worth reconsidering, so we refined the component itself, its grouping, and its variants. Of the ~60 alert and banner cases, roughly 20 got the same treatment. That’s about 45 refinements across two component families, each one making “which variant do I use?” a question with one clear answer for designers and engineers.

Step 3: Scale the process to 29 settings pages

Components were the warm-up. The real test is now underway for our settings section, with 29 pages of components and patterns, each page a snapshot of the conventions that existed when it was built. Settings pages in any product tend to be built once and revisited less often than core flows, which makes them a natural place for conventions to gently drift apart over time.

Auditing pages is harder than auditing components because the unit of comparison is bigger. It’s not a single pill’s color; it’s layout patterns, information hierarchy, interaction models, and data presentation, each with room to vary from page to page.

For this, Cowork helped me build an audit spreadsheet covering all 29 pages across three lenses: visual findings (styling and layout drift), UX findings (interaction and pattern inconsistencies), and data findings (how information is structured and presented). Every page, systematically scored, in a format the whole team can work from. The likely outcome is a redesign touching all 29 pages, but grounded in evidence.

Turn the findings into guidelines and guard-rails
The most lasting output of the audit isn’t the redesigned components, it’s the rules that come with them. The grouping work already contains the logic: every cluster answers the question “when should someone reach for this variant?” Writing those answers down turns the audit into usage guidelines, what each variant means, when to use it, and when not to.

Alongside the guidelines come the guard-rails: a defined set of semantic variants, naming that matches intent, and documented do’s and don’ts in the design system. This is what keeps the count from creeping back up, because the next designer facing a new use case finds a clear answer instead of creating variant number 51. An audit without guidelines is a cleanup, but with them it’s prevention.

From audit to implementation
An audit only counts when it ships. Our proposals go to the team that builds our UI components based on our styleguide, who confirm feasibility and update the elements across all areas. Once changes are agreed and scheduled, we share what is changing, where, and when, so the whole team has visibility before anything ships.

Then the loop closes the same way it opened: each designer checks their own areas to verify the components were updated correctly. Where something didn’t land as expected, we create separate tickets rather than letting it slide.

What I’d tell other designers

The repo is your friend
The UI shows you what you happen to encounter; the codebase is the complete record. If you can get AI to read it and render what it finds, you skip the most time-consuming part of every audit.

AI didn’t do the design work, but it removed the excuse not to
Every judgment call, from what to group to what counts as inconsistent to what the redesign should be, stayed ours. What changed is that the tedious 80% (finding, cataloguing, cross-checking) collapsed from weeks into days. The audit that “we should really do someday” became the audit we actually did.

Audit by intent, not by appearance
Grouping components by the job they do reveals patterns that visual grouping hides. Two identical-looking components doing different jobs deserve more attention than two different-looking ones doing the same job.

Document guidelines, not just fixes
The grouping work already holds the logic of when each variant applies. Capture it as usage guidelines and guard-rails in your design system, otherwise the drift starts again the day the audit ends.

Bring the team along
AI speeds up the finding; teammates validate the meaning. Ask each designer for a quick check on their own areas, and once changes are agreed, make them visible to everyone before they land. Consistency work only sticks when the whole team knows what changed and why.

Small drifts are inevitable, it’s a byproduct of momentum. What’s different now is that reviewing and refining them finally costs days instead of quarters. If you’ve been putting off an audit because of the effort it used to demand, just know it doesn’t demand it anymore.

The Audit You Keep Postponing? AI Just Made It a Two-Week Job. was originally published in Workable Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve been thinking a lot lately about what it actually means to design in the age of AI — not the LinkedIn version, but the honest, disorienting, occasionally thrilling version. This is my attempt to work through it, via a mountain school, an ice axe, and a few near-vertical descents.

Over thirty, no kids, not married. You know exactly what happens next. At some point you sign up for a marathon, picked up free diving, or enrolled in something that involves crampons. We all did.

Myself, I enrolled in a ski mountaineering school.

Not a ski resort. Not a wellness retreat, but the kind of regime where the morning start in the dark and then continue with ice axe technique training with the precision of a surgeon, in the kind of terrain that tests whether your decisions were good ones.

I did it because I needed to leave my computer that induces a specific kind of fatigue built up from days spent designing futures for other people inside the soft glow of a screen. The kind that no retrospective or offsite fully dissolves.

It’s not the hardest work out there, I’m aware, but it’s work that’s about producing outputs without being able to feel the friction. When nothing feels tangible, the obvious next step was of course, to climb a mountain to remind myself of what the other parts of me could be like.

On Ski Mountaineering

Before you, the reader, picture chalets and aprés, I need to tell you that ski mountaineering is something quite else.

It is the practice of ascending mountains on skis; climbing skins attached to your skis grip the snow on the way up, and descending off-piste terrain that no grooming machine has ever touched. It lives in the space between alpinism and backcountry skiing.

The goal is remote. The route is not guaranteed. You carry your equipment, read the weather, read the snow, make decisions that have consequences. And then, at the top of something truly terrifying, you clip in and go down.

Every day begins with a landscape map and a weather forecast. You plan a route, discuss the gradients, study the terrain. The map is good at shapes like ridgelines, elevation, valleys. What it cannot give you is the thick tree patch that blocks your planned line, the avalanche-prone slope that looks identical to a safe one from above, the snow quality that changes everything about how you move. The map is flat yet the mountain is not. You feel prepared, and then you go outside.

The ridge you planned to cross is wind-loaded and dangerous. The couloir is turning soft under afternoon sun. The tree line that looked passable is a wall. None of this was on the map, because it couldn’t be. This is not failure, as much as is the terrain giving you dynamic information that no document could have contained.

I’ve been designing digital products for years and this is the gap that people consistently underestimate: the distance between the plan and the field.

We pour energy into research decks, strategy documents, carefully constructed assumptions, and then users behave unexpectedly, the technology shifts, the thing we were certain about quietly crumbles. Most teams treat this as a problem to fix. The mountain taught me it is the most important data you will collect.

The research gives you the shape of the terrain. The texture only reveals itself when you’re actually in it.

The gap between your plan and the field isn’t a problem to fix. It’s the most important data you’ll collect. Don’t protect the plan. Read the terrain.

Safe Islands

In ski mountaineering you don’t move as a loose crowd. You identify a safe point, and move there one by one. Each person arrives, catches their breath. The team re-forms. Only then do you assess where to go next.

I find this extraordinarily underused in design work. We run sprint to sprint, feature to feature, launch to launch — without the deliberate island moments to re-form, re-orient, and ask not what’s next on the roadmap, but what’s actually right given where we’ve arrived.

In an environment where AI capabilities genuinely shift under our feet every few months (or week, even), the ability to pause at a safe island isn’t a slowdown. It is the thing that keeps you from walking your team into an avalanche zone. To extend the metaphor, if you bare with me, is that if we can cut the snow before we send the team down the slope, we don’t actually stop, we move on with more confidence, all limbs attached.

Build deliberate pause points into the work. Not to slow down — to make sure you’re still going the right way. In fast-moving terrain, the island moments are what keep teams out of avalanche zones.

The Rope

At a certain point in the ascent, you rope up. You are literally connected to the people around you; if one person falls into a crevasse, the others arrest the fall. The safety of the individual is distributed across the group. You are not a collection of individuals moving in the same direction. You are a system with shared consequence.

I feel the pressure to un-rope at times, never on the mountain, but sometimes when working with other people. It’s a pressure surely felt by many; designers, engineers and product managers alike, who each want to and need to to prove their individual value in an AI-augmented world. Our team shapes are shifting due to the new tech, including what individual contributors own, and where the line between human judgment and machine output sits. Disconnecting and going alone at speed is tempting, as much as it is terrifying.

The rope is not a constraint. The rope is what lets each individual take risks they couldn’t take alone.

Product teams that move well in uncertain terrain are the ones who are explicitly, intentionally connected.

Those are the teams who have defined what shared safety looks like, who carries which tool, who makes the call when the conditions shift.
The rope is not a constraint, but a guardrail that lets each individual take the risks they couldn’t take alone.

Which brings us to the edge.

The instinct to prove individual value in an AI world by moving alone is understandable. It is also wrong. Define shared safety before the conditions shift — not after.

The Terrifying Edge

There were moments in the course where I stood at the top of something and looked down into what felt like a genuine abyss. The gradient was brutal, the exposure was real. And the only way forward was down. No amount of preparation makes that moment comfortable. You take a breath. You take another one. And then you go.

This is where the metaphor becomes most honest about what product design in the AI era actually requires. There are decisions coming (some already here) that are not comfortable. What is the role of a designer when AI can generate interfaces? What does craft mean when the bottleneck shifts from production to judgment? What are we actually for? These are edge questions. The instinct is to keep them abstract, to stay on safer terrain. But the only way is down. The designers who will thrive are the ones who take the breath and go, not recklessly, but with full presence and the skills they’ve been building the whole ascent.

And ski mountaineering is not a sprint. You conserve energy on the flats, breathe deliberately on the steep, eat before you’re hungry because by the time the signal arrives, you’re already behind. The headline around AI moves fast, but the real work moves slow. Building genuine judgment — knowing where AI augments and where it erodes, developing the taste to tell a good AI-assisted experience from a mediocre one — that’s accumulated work. It cannot be hacked. It compounds, like fitness, like any real skill.

The people who will shape how AI and design coexist are not the ones moving fastest right now. They are the ones building endurance.

The good kind of snowball

What I didn’t fully see until I was sitting in that refuge, boots off, soup in hand, was how the whole mission we took in expanded what I thought I was capable of seeing.

When you deliberately place yourself in a completely alien context, one with no connection to your craft, your industry, your usual vocabulary, something opens up.

You start borrowing frameworks you had no idea you needed. You find solutions in the wrong discipline. The comfort zone isn’t just uncomfortable to leave because it’s scary. It’s uncomfortable to leave because it’s been doing your thinking for you.

The best design thinking I’ve encountered in my career has almost never come from within the design conversation. It has come from people who carried a different world into the room and couldn’t help but apply it. The choreographer who codes. The climber who writes. The architect who cooks. Not as hobbies. As methodology. The mountain just happened to be mine.

I enrolled in a ski mountaineering school to get out of my computer. What I found was a cleaner, colder, more honest version of the work I came back to.

Avra Alevropoulou is a Principal Product Designer at Workable. She is still learning to read snow.

If you are into all that feel free to reach out on Linkedin.

Burnt out on pixels. Somewhere cold, steep, and unexpectedly relevant. was originally published in Workable Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

What’s in a name? That which we call a rose. By any other word would smell as sweet.

Romeo and Juliet, Act 2, Scene 2. The balcony scene.

Juliet leans over the edge and speaks into the night, trying to convince herself that Romeo’s name shouldn’t matter. That the feud between Montagues and Capulets is nothing more than an accident of language…

I remember being asked about that line in class. The answer felt obvious: a name is just a label. It doesn’t change what something actually is. Romeo would still be Romeo even if he were called something else. A rose would still be a rose.

At the time, it made total sense.

Until recently. One year into product design, writing copy for AI, and I keep coming back to that line. And honestly? I think Shakespeare may have gotten this one wrong.

And before all you Shakespeare fans burn me at the stake for saying this, hear me out first. The reason I am saying this is because in UX, names do change things.

Not the system itself, maybe. The model doesn’t get smarter because we gave it a friendlier name. The algorithm doesn’t become more capable because we introduce it as a teammate. But the moment we name something, we shape how people understand it. And that changes how they use it.

Before I got into UX, I spent nearly ten years in project management in the pharma industry, specifically in clinical research. In drug development, naming is actually part of the safety process, not a marketing decision. A proposed name goes through a separate evaluation to ensure it can coexist safely with thousands of existing medications. If it looks or sounds too similar to another product, or risks creating the wrong assumptions about a treatment, it gets rejected. And the whole process starts again.

Generic drug names follow structured patterns. Parts of the name signal the drug’s class, the rest sets it apart from similar compounds. The goal isn’t memorability or personality. It’s clear, consistent identification.

Brand names also undergo rigorous evaluation. They need to be unique, internationally understandable, and unlikely to be confused with other treatments. And they can’t imply benefits that haven’t been proven.

The principle behind all of this is simple: a name should help people understand what something is without shaping expectations beyond what is actually known.

Working in that environment changes how you think about language. You start to see that a name is never just a label. It shapes how people interpret something before they’ve even read the details.

The more hours I spent at my desk, trying to frame our AI features and build a naming strategy, the more I realized that with AI products, we tend to move in the opposite direction. Away from descriptive names, toward names that feel personal, human even.

There is a word for that. Anthropomorphism.

What we really mean by anthropomorphism

It comes from Greek: άνθρωπος (anthropos), meaning human, and μορφή (morphē), meaning form or shape. Literally, it means giving something non-human a human form or human characteristics.

Growing up bilingual, this word always felt transparent to me. In Greek, you can almost see it, ανθρωπομορφισμός: shaping something into the form of a human. It’s right there in the word itself.

Originally, anthropomorphism was about how humans made sense of gods and natural forces. Ancient cultures gave storms intentions, rivers personalities, celestial bodies emotions. It was a way of making complex, unpredictable things easier to understand.

So in that sense, this isn’t some modern design trend. It’s a deeply human habit.

And it takes remarkably little to trigger.

ELIZA, then and now

Back in the 1960s, an MIT computer scientist named Joseph Weizenbaum built one of the first programs that could hold a conversation. He called it ELIZA. It was designed to mimic a psychotherapist and would just rephrase what you said back to you. “Tell me more about that”, that sort of thing. It didn’t understand a thing you wrote; it just rearranged your words into something that sounded like a response.

And yet, people reacted as if they were talking to someone. Some even got emotionally attached. What’s interesting is the fact that even people who fully understood how ELIZA worked found themselves responding to it socially. Weizenbaum had built ELIZA to show how superficial computer conversation was. Instead, users were projecting empathy and understanding onto something that had neither.

Fast forward 50 years, and the same thing happened again. In 2023, a Belgian man struggling with climate anxiety started talking to a chatbot called Eliza on a platform called Chai. Over several weeks, he became increasingly isolated and emotionally dependent on it. The chatbot played the role of a supportive companion, while slowly feeding him the idea that AI could save the planet and that he could be part of that. Eventually, he took his own life.

What researchers found when they looked into the case was that the system had been designed to feel emotionally engaging, to come across as a companion rather than a tool. The technology had come a long way since the 1960s. The human response to it hadn’t moved an inch.

Turns out, you don’t need a genuine understanding for this to happen. You never did. Just the appearance of a conversation is enough.

When the machine becomes “Someone”

Understandably, it is the extreme cases that make the headlines. But honestly, you don’t need a tragedy to see how powerful this is.

My son was around four when he discovered Siri. Like most kids encountering a voice assistant for the first time, he was fascinated. He’d ask questions constantly, real ones, made-up ones, nonsense ones, just to see what Siri would respond.

And very quickly, Siri stopped being a system and became a person.

When the answers didn’t make sense to him, he’d laugh and say things like “Doesn’t she understand?” or “She’s silly, she didn’t get what I asked.” Sometimes he’d get genuinely frustrated, like he was being ignored rather than hitting a technical wall.

My son treated Siri as a human, which is quite normal if you think about it, as kids tend to personify pretty much anything. What I realized, though, was how natural it felt for me to follow along. Without thinking about it. Somewhere between the voice, the name, and the back-and-forth convo, the system had quietly become a character.

And that realization was hard to ignore.

Because anthropomorphism doesn’t just change how we talk about technology. It changes how we read everything the system does.

When the “person” is not neutral

It gets more complicated when you look at who that “person” tends to be.

For example, most voice assistants aren’t just anthropomorphic, they’re gendered. They have human names. Human voices. And more often than not, female identities.

That’s not an accident. As voice assistants went mainstream, designers kept landing on female-sounding voices and feminine names because users found them more helpful and approachable. There’s research on this.

But those choices carry more weight than they might seem.

When you give technology a human identity, you also inherit all the cultural baggage that comes with it. A UNESCO report called I’d Blush if I Could looked at exactly this — how female-voiced assistants tend to follow a familiar pattern: polite, endlessly patient, calm no matter what you throw at them. Early versions would even respond to insults and harassment with playful, submissive replies.

The report’s point was uncomfortable but hard to argue with: design choices like these don’t just reflect existing gender stereotypes, they reinforce them. The assistant becomes a very specific kind of person, one who is expected to serve, accommodate, and quietly absorb whatever comes her way. And when millions of people interact with that version of “helpful” every day, they start absorbing that message too, often without realizing it.

When my son called Siri “she,” he wasn’t making a design statement. He was just picking up on the cues the system was giving him. A voice, a name, a personality. That was enough.

When human-like AI undermines trust

And yet, the design world largely sees all of this as a feature, not a bug. One of the arguments you hear a lot in favor of human-like AI is that it builds trust. A friendly assistant feels more approachable than a cold, impersonal tool.

However, we’ve seen that people treat machines as social beings even when they know full well it’s just software. All it takes is a human name, a conversational tone, or a simple “I”, and the social response kicks in, almost instinctively.

Here’s where it gets interesting though. You’d think that designing AI to sound emotionally aware or socially intelligent would make people trust it more. It doesn’t. Sometimes it actually does the opposite.

Research from the Nielsen Norman Group found that users trust competent, transparent AI over emotionally expressive ones, favoring clarity over personality. Clear reasoning, transparent sources, well-structured answers, those build trust. Personality and emotional expression often erode it.

Trust in AI isn’t about liking the system. It’s about understanding what it can and can’t do. Anthropomorphic language blurs that line.

A system that sounds like a person invites assumptions that were never part of the design. Confidence gets mistaken for certainty. Fluency gets mistaken for expertise. A conversational answer gets mistaken for genuine understanding.

Names and voices don’t change what the system is. They change what people think it is.

A study published in Harvard Business Review (2025) asked exactly that: does making AI more human actually help? And the answer, maybe unsurprisingly at this point, was: not really.

The sweet spot isn’t full humanization or going completely cold and robotic. It’s making the humans behind the AI more visible. The engineers who built it. The experts who shaped it. The people who curated the data. When companies basically said, “real people with real expertise made this,” users found the AI more useful and were more open to adopting it.

Well, isn’t that ironic? The more we try to make AI feel human by giving it a name and a personality, the more we might be hiding the very thing that would actually make people trust it. The real humans in the room.

Naming for mental models

Let me be clear about something. I’m not arguing that AI should never sound human. Anthropomorphism is too deeply wired into how we think; we can’t just design our way around it. And honestly, in some contexts, a conversational, agent-like interface makes complete sense.

The question was never really “should AI sound human or not?” The question is: what does the name make someone expect, before they’ve even entered the interaction? The name is the first thing a user encounters. It sets the frame for everything that follows.

A feature that evaluates candidates or estimates salaries is a tool; it follows rules, and it has a defined job. Call it what it is. Candidate Evaluator. Salary Estimator. Something that tells the user exactly what they’re walking into.

But some systems are different. Something that moves between tasks, makes decisions, figures out next steps on its own, that’s closer to an agent than a tool. And in that case, a more human-centered name might actually help people understand what they’re dealing with. Not mislead them, but orient them.

When the name actually reflects what the system does, people know what to expect from it, and that’s where real trust comes from. They know when they’re using a tool and when they’re handing something off to a more autonomous process. Once a name is more about personality than what the thing actually does, users lose clarity.

When I first read Juliet’s line in high school, the answer seemed pretty obvious. A name is just a label. The essence of a thing stays the same regardless of what you call it.

Working with AI systems, that idea feels a lot less certain now. A rose may still smell as sweet by any other name. But in UX, names shape what people expect before the experience even begins.

And those expectations? They shape everything that follows.

References

Alabed, A., Javornik, A., & Gregory-Smith, D. (2022). AI Anthropomorphism and Its Effect on Users’ Self-Congruence and Self–AI Integration: A Theoretical Framework and Research Agenda. Technological Forecasting & Social Change.

Acar, O. A., Klesse, A.-K., Tuk, M. A., & Zhang, Y. (2025).
Research: Consumers Don’t Want AI to Seem Human. Harvard Business Review. https://hbr.org/2025/01/research-consumers-dont-want-ai-to-seem-human

Brookings Institution. How AI Bots and Voice Assistants Reinforce Gender Bias. https://www.brookings.edu/articles/how-ai-bots-and-voice-assistants-reinforce-gender-bias/

Crolic, C., Thomaz, F., Hadi, R., & Stephen, A. (2022). Blame the Bot: Anthropomorphism and Anger in Customer–Chatbot Interactions. Journal of Marketing.

Hill, S. R., & Troshani, I. Chatbot Anthropomorphism, Social Presence, Uncanniness and Brand Attitude Effects. Adelaide Business School.

Maeda, T., & Stark, L. Anthropomorphism as Social Affordance: Charting the Co-Animation of Chatbots into Social “Agents”. Proceedings of the AAAI/ACM Conference on AI, Ethics, and Society.

Nielsen Norman Group. Focus on AI’s Performance to Help Build User Trust. AI and user trust. https://www.nngroup.com/articles/smarts-emotion-trust-ai/

Peter, S., Riemer, K., & West, J. D. (2025). The Benefits and Dangers of Anthropomorphic Conversational Agents. Proceedings of the National Academy of Sciences (PNAS).

Pfizer. Ever Wonder How Drugs Get Their Names?
https://www.pfizer.com/news/articles/ever_wonder_how_drugs_get_their_names

Placani, A. (2024). Anthropomorphism in AI: Hype and Fallacy. AI and Ethics.

Reuter, M., Kirchhoff, B. M., Franke, T., Radüntz, T., & Peifer, C. (2025).
To Trust or Not to Trust a Human-Like AI: Factors Influencing Anthropomorphism and Trust.

Salles, A., Evers, K., & Farisco, M. (2020). Anthropomorphism in AI. AJOB Neuroscience.

UNESCO. (2019). I’d Blush If I Could: Closing Gender Divides in Digital Skills Through Education.

Weizenbaum, J. (1966). ELIZA — A Computer Program for the Study of Natural Language Communication Between Man and Machine. Communications of the ACM.

Wiley Online Library. Anthropomorphism and Human–AI Interaction Research. https://onlinelibrary.wiley.com/doi/epdf/10.1111/japp.70008

AI disclaimer: I used ChatGPT to research about AI and anthropomorphism, to draft the article outline and refine my section headings. I used Claude to proofread.

Shakespeare was wrong about names. At least in UX. was originally published in Workable Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

There’s a version of AI adoption in UX that looks impressive on paper — faster outputs, more iterations, automated summaries — but leaves teams feeling strangely hollow. Like they’re moving quickly without quite knowing where they’re going.

That’s not the version worth chasing.

Over the past months, our team has been running a different kind of experiment. Not “how do we use AI to go faster?” but “how do we use AI to work better, together?” The distinction sounds small. It isn’t. It shifts the conversation from individual productivity to collective intelligence — from tools that help one designer move faster, to systems that make the whole team sharper.

What follows are three experiments: one we’re about to begin, one we’re building right now, and one we’ve already completed — an attempt that fell short, but ended up teaching us more than any success could.

Experiment 1: Turn Research into a Living System (Coming next)

The problem we’re trying to solve
Research insight has a short shelf life in most teams — not because the insights expire, but because they get buried. A usability study from eight months ago lives in a Miro or Google slides no one can find. Patterns from five rounds of interviews never made it into a shareable format. New team members start from zero. Even experienced ones repeat work that’s already been done.

The question we’re asking ourselves isn’t “how do we summarize research faster?” It’s: “What if all of our research was actually usable?”

What we’re planning to build
A centralized research system — a living database where every study, interview, and insight lives in one place, structured and searchable. The idea is to use AI to do two things within it: first, pull transcripts directly from the platforms we run interviews on and auto-populate analysis templates, so findings go from raw data to structured insight without the manual overhead; second, surface connections across studies, so we can ask things like “what friction points have we seen in onboarding across the last year?” and get a real answer.

Templates are central to this. A shared structure for synthesis means everyone’s analysis looks the same, lives in the same place, and can be handed off or reused without translation — ready to use as-is for the next project that needs it.

Why we think it will matter
We expect institutional memory to stop being a metaphor and become something real. New designers will be able to tap into years of research context from day one. Senior designers will stop being the unofficial archive everyone comes to with questions. And we’ll stop re-discovering the same user problems in every new project cycle.

The impact we’re looking for isn’t measured in hours saved — though we expect those too. It’s measured in the quality of decisions we make earlier, because we’re no longer starting from scratch every time.

Experiment 2: Build Your Own Figma Plugins (In progress)

The problem we’re solving
Design quality checks happen too late. Accessibility, consistency with the design system, copy tone — these are often reviewed in critique, or worse, after handover to engineering. By then, the cost of fixing them is high, the conversation is defensive, and the feedback loop is broken.

We also noticed something uncomfortable: every designer on the team had slightly different internalized standards. The same component could be reviewed by three people and get three different assessments of whether it was “consistent with what we have in production” or “accessible enough.” That inconsistency wasn’t a people problem. It was a systems problem.

What we’ve built — and where we’re going
We started with one plugin: an inline copy assistant embedded directly in Figma — one that knows our glossary, our tone of voice principles, our dos and don’ts, and our best practices. Instead of opening a Jira ticket to the UX writer, designers get contextual support exactly where they’re writing. When one UX writer supports multiple product designers, manual copy review simply can’t keep up with the volume — the plugin helps us move from one-off requests to a scalable content system, so designers can self-serve against shared standards and UX writing effort goes where it has the most impact.

Now we’re scaling it up. The next step is a plugin that checks consistency with our design system — flagging deviations before they reach a review. The thinking is that if designers can run their own structured check before a critique, we remove a layer of noise from those conversations and create the conditions for higher quality feedback. Less time catching the obvious. More time spent on the decisions that actually need a room.

What we’re assuming — and what we want to find out
Our hypothesis is that this will shift the nature of critiques and raise the overall quality bar. But we’re honest that it’s still an assumption. We haven’t yet seen whether removing consistency checks from the critique agenda actually frees up the conversation, or whether it just changes what gets flagged.

That’s what we’re watching. Starting with one plugin made this feel achievable — each addition builds on a foundation the team already trusts, and we can evaluate the impact before scaling further.

Experiment 3: The Prompt Library That Taught Us the Wrong Question (Completed — and failed)

What we tried — and what broke
A while back, we built a shared prompt library — organized by task type, documented carefully, made available to the whole team. Almost no one used it. Not because the prompts weren’t good, but because most designers had already developed a habit of asking Claude or ChatGPT to write a prompt for them. The library existed. The behavior never followed. And that failure pointed us toward a much more interesting question than the one we started with.

Where it actually led us
We stopped asking “how do we prompt better?” and started asking “how do our design methods need to change in an AI world?” Take personas — instead of maintaining a prompt for them, we redesigned the method itself: give AI our existing template plus a set of research summaries, and let it generate a structured first draft that designers then interrogate and refine. The method is still ours. The labor distribution has changed. We’re now working through journey mapping, “How Might We” framing, and affinity clustering the same way — not replacing the craft, but rethinking where AI fits inside it.

The Shift That’s Actually Worth Making

Three experiments. Three different stages. Three different lessons.

What connects them isn’t the technology — it’s the posture. In each case, we weren’t asking “how do we add AI to what we already do?” We were asking “what do we need to change from what we do?” That’s a slower, less comfortable question. It’s also the right one.

The teams that will benefit most from AI aren’t the ones who adopt it fastest. They’re the ones who are most thoughtful about how they adopt it — who treat the integration itself as a design challenge, worthy of the same rigor they bring to the products they build.

We’re still in the middle of this. Some experiments are working. Some are still being planned. One already humbled us. But that, too, is how good design works — you test, you learn, you adjust the question.

Sometimes the most meaningful shifts in a team’s workflow start with small experiments like these.

A special thank you to Ino Ioannidi for leading the copy Figma plugin, to Avra Alevropoulou for leading the exploration of how design methods need to adapt in the AI era, and last but not least Thanos Dimitriou for the support. None of this moves forward without people willing to do the hard work of making new ideas actually work.

AI Playbook: 3 Experiments Every Design Team Should Run was originally published in Workable Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hiring takes time, especially in the early stages. Recruiters spend hours defining roles, aligning with hiring managers, screening candidates, and manually moving people through the pipeline. Much of that time is spent clarifying expectations and filtering information. That led me to a simple question:

How might we reduce hiring effort by leveraging AI?

That’s how Workable Agent was born a conversational AI tool that helps recruiters define roles, ask clarifying questions, structure job requirements, and move the top candidates forward in the pipeline. It’s not just a chatbot. It’s not just a job description generator. It’s an AI collaborator embedded in the hiring workflow.

Designing the experience

When I started exploring the experience, I experimented with different approaches. Should it feel like a chat? A structured form? Or a collaborative document where recruiters and AI co-create the role definition? After many iterations, the core interaction became clear.

The experience begins with one focused question:“Who are you looking to hire?” From there, the Agent guides the user with step-by-step clarifying questions. Once enough information is gathered, the interface transitions into a split view (the chat history on the left and a live view of the Ideal Candidate Profile on the right) Instead of simply filling out a form to create a new role, recruiters can watch the role take shape in real time as the conversation unfolds.

But that’s when the real challenge appeared:

How do you prototype something that doesn’t follow a fixed sequence?

Why traditional prototyping wasn’t enough

Traditional prototyping assumes a linear path: one screen after another, with predefined transitions and predictable behavior. My design wasn’t linear. Users could type freely. Every input could reshape the Ideal Candidate Profile.

The system needed to interpret context, adapt in real time, and guide the conversation forward. Static screens can simulate predictable paths, but they struggle to capture the fluidity of a conversation or the unpredictability of real user input.

To truly understand the experience, I needed to test real scenarios: users improvising, skipping steps, or introducing unexpected details, and observe how the system reacted. That s when it occurred to me:

Instead of fighting the limitations of traditional prototyping, why not leverage AI itself?

The making of

Step #1 — Starting point

I began by uploading a screenshot of the first screen and asked Figma Make to recreate it. This wasn’t just about replicating the visuals it was about setting the stage for the interaction itself. The screen had to show not only the layout but also how the conversation would start. With that first screen in place, I finally had a foundation to begin iterating.

Step #2 — Polishing

Once the first screen was complete, I shifted my focus to refining the UI. Details like spacing, alignment, and replacing the avatar became important because they shaped how the Agent would ultimately look and feel. With each adjustment, the prototype moved closer to feeling like a real, interactive experience rather than just a static mockup.

Step #3: Defining behavior

The most important step was defining how the prototype would actually behave. I turned to ChatGPT to help craft a prompt specifically for Figma Make. I explained the full experience: after the first screen, the Agent should ask clarifying questions, and once enough information was gathered, it should generate the Ideal Candidate Profile on the right side of the canvas. The interface needed to reflect this transition clearly.

I shared the designs with Figma Make so it could understand how the states should evolve and how the interface needed to respond to user input. The process wasn’t instant — it involved many prompts, repeated errors, and waiting for generations to complete. Each iteration refined the prototype a little more.

The actual test

Once the prototype was ready, I tested it with users. One participant decided to take a shortcut: instead of going step by step, they copied the entire role description and pasted it into the first input field. The prototype crashed. The Ideal Candidate Profile didn’t load. After some time, it displayed an empty state. The user didn’t give up. They explored, typed around, and finally wrote:

“Can you create this please?

and then it happened!

The AI immediately understood the input and generated the Ideal Candidate Profile. That moment hit me! In a typical Figma prototype, this scenario wouldn’t exist. Predefined flows can’t handle real user improvisation. With Figma Make, I was seeing real friction, real recovery, real behavior. A prototype isn’t just a way to show what s supposed to happen. It s a tool to reveal what actually happens when people interact with a dynamic system.

My learnings

Some real takeaways from this prototype:

• Provide clear context: The AI works best when it understands the full picture. At the start, I realized I couldn’t just give Make a single screen and hope it would “get it.” I needed to explain what the experience was, how the conversation should flow, and what the final outcome should look like. The more context I provided, the better the prototype behaved.
• Draft your prompts with an LLM first: A single vague instruction in Make can easily break your prototype. Instead of guessing, use Gemini or ChatGPT as a sounding board to refine and tighten your prompts before you paste them in. Dialing in your instructions with a conversational AI first drastically improves the speed and accuracy of the final design output.
• Use visual guidance for precision: Screenshots and Figma make pointer weren’t just nice-to-haves. They were critical. They told the AI exactly what to modify, where to focus, and how subtle layout or interaction changes should behave.
• Take smaller bites: It’s tempting to ask the AI to build an entire end-to-end user flow in a single prompt, but the results are usually chaotic. Breaking the request down and generating screen-by-screen or even component-by-component allows for much better quality control and less time spent untangling confused layouts.
• The “Clean Room approach: Figma Make doesn’t just look at a picture of your design; it reads the underlying structure and metadata. If your file is a mess of unnamed vectors and ungrouped text, the AI will hallucinate. Before you even open the Make prompt, apply Auto Layout, name your layers logically (e.g., Input Field, “Date Picker ), and set up clear responsive constraints. A clean file structure is the best prompt you can give.
• Test real conditions: The biggest insight came from watching real users interact with the prototype. Unexpected inputs, improvisation, and mistakes revealed friction points I could never have predicted. Testing in realistic scenarios not just idealized flows uncovered the true gaps in both design and AI behavior.

Building this prototype changed the way I think about prototyping. For years, prototyping meant connecting screens in Figma. Creating flows. Deciding what happens when someone clicks “Next. That works when interactions are predictable. But this experience wasn’t predictable. Users could type anything. They could skip steps, paste full descriptions, or phrase things in completely different ways. The system had to understand the input and respond accordingly. With Figma Make, I didn’t have to fake that behavior by linking static screens together.

Instead of designing a fixed sequence of steps, I focused on defining how the system should react. Instead of simulating clicks, I tested real interaction.

No more connecting art boards just to imitate a dynamic experience. No more gap between what users actually do and what the prototype allows. When a prototype behaves closer to the real product, you stop assuming and start learning.

And that’s where the magic happens! ✨

If you enjoyed this article, feel free to give it a clap!

Thanks for reading 😊

Note: This article includes content generated with the help of ChatGPT, used as a supportive tool.

I Stopped Connecting Screens. I Started Designing Behavior was originally published in Workable Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Working with data is one of my favorite parts of being a designer. I don’t love guessing. I love patterns, clues, contradictions — real signals from real users. So I often get asked to share how I use data in my work.

But let’s be honest:

Another Confluence page?
Another deck?
Another designer falling asleep mid-scroll?

I was also asked to come up with a design team extraversion activity.
So I figured… what if I made a detective game that shows my process in a fun way, and then shared the messy, weird, creative journey behind it?
That kind of counts as extraversion, right?
Win-win.

That’s how Who Killed the Conversion? was born: a retro-style UX detective game where you solve a conversion crime using analytics, recordings, interviews, and your best designer instincts.

Here’s the full story of how it came together — from failed AI experiments to Figma wizardry — with some learnings, mishaps, and vintage flair along the way.

🎬 From raw signals to game logic

Once I’d decided to not make a deck, a doc, or anything that resembled homework, I started sorting through my usual data sources — the ones that actually help me make design decisions.

Not the neatly filtered feature requests, but the messier stuff:

• Raw user problems in Savio
• Full-screen session recordings (even the ones where users get lost in other parts of the product)
• Comparative analytics across flows and features
• Iterative usability testing, one thing at a time

That’s the kind of data I rely on — not to validate decisions, but to form them. So I knew that whatever I made had to capture that detective-like thinking.

I toyed with the idea of a comic (cute, but static).
Thought about a video (snappy, but passive).
But the more I thought about the process, the more it felt like… a game. Collecting stuff to build something bigger.

🤖 chatGPT: Co-writer, co-chaos agent

At first, I had a very different kind of game in mind.
Think: Super Mario meets UX.
You’d jump through a conversion funnel, dodge stakeholder opinions, collect insight coins, maybe squash a couple of misaligned KPIs along the way.

First chatGPT prompt output:

Create a side-scrolling 2D platformer game called **"Design Dash: The Data Quest"**, inspired by Super Mario.

🧑‍🎨 Player Character: **Alex**, a pixel-art UX designer (jumps, runs, collects gems)

👑 Sidekick: A cute **princess** (or optional **dinosaur**) who appears between levels to give advice and cheer you on

💎 Objective: Collect different **Data Gems** to solve product design problems.

🎮 Game Structure:
- Super Mario-style level progression
- Players collect 4 types of glowing **Data Gems**, each representing a form of product insight:
 1. 🟦 Blue = **Raw Feedback**
 2. 🟨 Yellow = **Session Recordings**
 3. 🟥 Red = **Analytics**
 4. 🟩 Green = **Usability Test Results**

- At the end of each level, Alex must **answer a design question** based on the gems collected. If correct, they unlock a design solution and advance.

🎯 Example Level Design:
- Level 1: **The Feature Fog Forest** 
 Enemies: "Feature Requests" that throw vague suggestions. 
 Tip: Collect Blue Gems (raw user feedback) to see the real problem.

- Level 2: **Session Swamp** 
 Platforms rewind and fast-forward like session recordings. 
 Tip: Find the full journey, not just the end-point.

- Level 3: **Chart Cliffs** 
 Climb platforms labeled with usage stats. 
 Tip: Compare data points before judging.

- Level 4: **Test Tower** 
 Each jump changes the UI layout - test multiple versions. 
 Tip: Don't rely on one test - repeat to improve!

🎨 Visual Style:
- Classic pixel-art platformer
- Colorful, lighthearted, retro video game vibe
- Collectible **glowing gems**, mushroom-style enemies with names like "AssumptionBot" or "Data Fog"

👑 Princess Sidekick:
- Gives fun design tips between levels
- Says things like:
 - "Nice catch! That raw feedback gem revealed what users *really* meant!"
 - "Try running one more test-iteration is magic!"

🧠 End Goal:
- Reach the final castle and build a "Data-Powered Product"
- Credits roll with tips: "Design with curiosity. Validate with data."

🔧 Tools & Stack:
- Use HTML5 Canvas + JavaScript or Phaser.js (or Unity if advanced)
- Pixel sprites for Alex, the princess/dino, enemies, and gems
- Simple game loop, collision detection, jump physics, score counter

It was fun in theory — but impossible in practice.

I tried using rosebud.ai to bring it to life, but it quickly spun out of control. The results were chaotic: levels that made no sense, characters with uncanny faces, and visuals that looked like they belonged to five different games.

That’s when I zoomed out.
I know nothing about video games, how can I create one? If I wasn’t building a video game, what kind of game was I building?

It hit me: I wasn’t thinking like a gamer.
I was thinking like a board gamer.

I didn’t care about fancy physics or avatars — I cared about setting the scene, letting people make choices, solving something together.

So I pivoted.
Less arcade, more story.
What if, instead of jumping over problems, you investigated them?

Clues = data
Suspects = assumptions, design flaws, misleading analytics
Detective = you

Suddenly, the “how we use data” story had stakes.
It had tension, conflict, resolution.
It had… vibes.

I prompted ChatGPT with rough ideas, like:

make it like a mystery game with questions and hints, like cluedo

We built characters. We mapped crime scenes. It also generated the draft flow that is close to the finished game:

[Start Screen]
    ↓
[Intro Briefing by Fog the Frog]
    ↓
[Choose Case] ───▶ [Case 1: Dead Button Society]
               │
               ├──▶ [Case 2: Form of Doom]
               │
               └──▶ [Case 3: The Click That Vanished]
    ↓
[Enter Mystery Mansion]
    ↓
[Visit Rooms in Any Order]
    ↓
[Collect Clues & Evidence]
    ↓
[Interrogate Witnesses with Sidekicks]
    ↓
[Make a Design Diagnosis]
    ↓
[Reveal UX Crime Scene Report]
    ↓
[Game End + Optional Replay]

🔪 v0: Who killed the UI?

Then came v0.dev, a tool I was more familiar with, as I have been using it to create prototypes for a while. I generated some functional UIs and playable flows.
The plot was clicking. The atmosphere… not so much. I could create a playable mystery with branching decisions and narrative flow. Tried to make the UI closer to what I had in mind by building new prompts and providing example images, but it got worse. I even tried to start from scratch with clear prompting about the aesthetics, but had no luck.

It was like trying to tell a film noir story using Microsoft Access templates. Even after reaching version 20.

🎨 Sora: Board game brain takes over

So I went full Cluedo mode:

• Retro UI
• Smoky mystery visuals
• Characters with suspicious hats

Sora (OpenAI’s video generation tool) helped me produce some great vintage visuals: old-school UI bits, foggy backgrounds, moody lighting. It gave me just enough raw material to start building the actual interface.

🛠️ Figma Make: The DIY game engine

Eventually, I realized:

You know what’s easier than trying to hack AI-generated UIs into an actual playable thing?
Just designing the damn game myself in Figma.

I laid out a few high-fidelity screens with arrows and flows.
Then I dropped them into Figma Make, using a basic prompt:

A mystery — cluedo like- game for UX.

It worked. Sort of. The first couple of screens looked promising, but I still had to go back and forth with the prompts, stitch the flow together, and sprinkle in just enough data lingo to make it educational without killing the fun. Figma make did really well in generating extra mystery cases, given a first example mystery and the titles of the new ones.

Fonts and colors got a final pass to hit the mid-century mystery vibe. (Hot tip: AI-generated beige is not always aesthetic.)
I tweaked some copy to land the jokes better.
And then, it was ready.

Playable. Shareable. And somehow… educational?

🔍 What I learned in the mystery mansion

Some real takeaways from this experiment:

• Constraints make better stories
  Turning “data in design” into a murder mystery forced me to simplify and dramatize the process — which actually made it easier to communicate.
• AI can be an idea partner, not a finisher
  ChatGPT helped me explore narratives fast. Sora gave me images I’d never make on my own. But they couldn’t own the craft. I still had to set the tone, stitch the UI, and balance the narrative. The edit was where the story came alive.
• Humor is a design tool
  A joke lands faster than a data chart. And people remember stories with surprise, not statistics.
• Don’t wait for permission to make something cool
  No one asked for this game. But everyone enjoyed it.

🧩 How to use this as a team activity (without awkward icebreakers)

Want to turn Who Killed the Conversion? into a team activity? Here’s how to do it without anyone being forced to say their favorite vegetable:

Play solo or in pairs

Share the Figma Make game with the team and let people play at their own pace — or in small breakout groups if you’re feeling brave.

Reflect as detectives

Ask everyone to write down one thing they do (or could do) in their workflow that mirrors the detective steps:

• Looking beyond feature requests
• Watching full user journeys
• Comparing analytics across products
• Iterating usability tests

Optional: Debrief without pressure

Host a short async thread or Slack huddle to share takeaways. Prompt:

“What’s one ‘conversion killer’ you’ve uncovered in your own work?”

Bonus: Make your own mystery

If the team’s into it, challenge them to come up with a new “case” based on a real UX problem.
(Or just let me know — I might make a sequel.)

Designed for introverts. Endorsed by overthinkers.

Got questions? Want to collaborate on a sequel? Let’s chat. The Conversion Killer might strike again. 🕵️‍♂️💥

Who Killed the Conversion? was originally published in Workable Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Workable, our customers — HR professionals and hiring managers — needed better ways to track employee working hours and manage evolving work schedules. Existing tools were fragmented, unintuitive, or too rigid to support real-world flexibility, especially in hybrid or shift-based work environments.

So I set out to design two core features:

• A Time Tracking tool to let employees log and review their working hours easily
• A Work Calendar that empowers HR admins to assign, update, and oversee work schedules and time offs at scale

One was built from the ground up, while the other was an evolution of our existing time-off calendar. Both needed to be powerful but not overwhelming, adaptable but not confusing.

Designing these tools meant more than creating clean interfaces — it meant solving for complexity without exposing it. Here’s what I learned about building complex tools from scratch — without letting that complexity overtake the design.

🧠 1. Understand the system before designing the UI

Complex features are often rooted in complex realities: regulations, policies, and edge cases. That’s especially true in HR.

Before designing anything, I spent time understanding how things work, not just in theory but in practice:

• How do companies define a “work schedule”?
• What are the main things or hr users need to change to a work schedule and why?
• What are the legal constraints about overtime to other countries we sell our product ?

This upfront understanding becomes your design foundation. If you skip this, your UI will likely collapse under real-world usage.

Think in systems before you think in screens!

📐 2. Define the mental model (and stick to it)

Users build mental models fast — and they rely on them to use your tool efficiently. The more consistent your logic, the easier your tool becomes to navigate.

For our Work Calendar, we made a key early decision:

• A row represents a person
• A column represents a day
• A cell shows what someone is scheduled to do that day

Simple, clear, and stable. And this structure remained consistent across the entire experience — from viewing schedules to applying bulk edits or managing time-off.

This directly ties into the usability heuristic of Consistency and Standards:

“Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform and industry conventions.”

We leaned heavily on Jakob’s Law as well:

“Users spend most of their time on other digital products. Their expectations are shaped by those experiences — not yours.”

That’s exactly why we deliberately modeled the calendar’s interaction patterns after Excel:

• Users can select multiple rows and columns
• Apply bulk edits through context actions
• Recognize table-like behavior intuitively

Rather than reinventing the wheel, we embraced what users already know. This lowered the learning curve, increased confidence, and made even complex actions feel familiar.

Failing to maintain consistency adds friction. Following established patterns adds fluency.

✏️ 3. Design scalable interaction patterns

One-off screens can look great in Figma. But complex tools rarely work that way in production.

I focused on creating reusable interaction patterns that could adapt to various use cases:

• A consistent pattern for bulk actions (used across the calendar and time tracking)
• A flexible input component that accepts both time ranges and durations
• A standardized way to resolve conflicts (e.g., overlapping time-off and shifts)

These patterns became building blocks. Not only did they speed up development — they also trained users to recognize and reuse familiar actions.

🧪 4. Validate complexity with real workflows

When you’re designing complex tools, it’s not enough to ask, “Does this make sense?”
You need to ask, “Does this make sense when someone is actually trying to get work done?”

We validated our designs through user testing, preference testing, and interviews — always anchored in real workflows, not hypothetical tasks.

🕒 In Time Tracking:

We ran usability tests on our prototype and asked users to perform everyday actions:

• Clock in and clock out
• Edit the end time of an already closed time entry
• Add a note when their clock-in didn’t match the expected schedule

These weren’t edge cases — they were frequent, real-world scenarios. Observing users helped us refine how visible and accessible these actions were in the UI.

We also ran a preference test to resolve a key decision:

Should the default view in an employee’s profile show a calendar of time entries, or a list view?

The results showed a slight preference for the list view (12 participants vs. 11 for the calendar view). Despite the close split, we chose to launch with the calendar view as our MVP, as it better aligned with our visual model and offered clearer weekly context.
In the next phase, we plan to introduce the list view as well, giving users the flexibility to choose the format that best suits their needs.

📅 In the Work Calendar:

We conducted user interviews to evaluate the initial bulk actions we had designed for HR admins — such as:

• Set as onsite
• Set as remote
• Edit working hours
• Apply a work schedule template

We wanted to know:

• Do these actions make sense?
• Are they labeled clearly?
• Are they actually useful?

Then we asked users what actions they wished they could perform in bulk — things they often do but weren’t currently supported. That feedback shaped how we prioritized future improvements and refined the terminology in the action bar.

The key insight? Complexity doesn’t just live in the system — it lives in how people use it.

By testing full workflows rather than isolated UI elements, we ensured the tool aligned with real behaviors, not just ideal ones.

🤝 5. Collaborate early with product and engineering

Building complex tools is never a solo mission — it’s a collaborative process that requires shared ownership from day one. Throughout the design of Time Tracking and the Work Calendar, I worked closely with both our product manager and engineering team to ensure we were solving the right problems in the right way.

With product:

Our collaboration started early, before any mockups existed. Together, we:

• Defined the core use cases we needed to support — what real-world problems were we solving?
• Clarified the vision and goals behind each feature, so we could align our decisions to a long-term product direction, not just short-term requirements.
• Identified and prioritized edge cases we needed to support, especially around exceptions in working hours, schedule conflicts, or flexible working patterns.

This gave me clarity and focus during the design phase — and helped us stay aligned as the features evolved.

With engineering:

I also involved engineers early in the process — not just to hand off designs, but to co-create the solution.

From the start, I worked with the engineering team to:

• Understand any technical constraints that might shape our approach
• Estimate the engineering effort for different paths we were exploring
• Get feedback on design proposals from a technical point of view — what was feasible, what could be simplified, and where the logic might get too brittle

This back-and-forth was incredibly valuable. It helped me refine the interaction models, reduce unnecessary complexity, and make trade-offs that respected both UX and implementation realities.

The earlier you involve your teammates, the better your design will fit the system — and the smoother the handoff will be.

🎯 Final Thoughts

Designing complex tools from scratch isn’t just about solving big problems — it’s about doing so in a way that feels natural, purposeful, and usable.

Whether it was helping employees track their time or enabling HR admins to manage shifting schedules, what made these tools work wasn’t just functionality — it was clarity. Clarity in the mental model, clarity in the interaction patterns, and clarity in the collaboration with teammates.

Here’s what I’ve learned:

• Understanding the system deeply is non-negotiable
• Consistency and familiarity make even advanced tools approachable
• Scalable design patterns future-proof your work
• Testing real workflows reveals what truly matters to users
• Early collaboration sets the foundation for alignment and momentum

Complexity isn’t the enemy — but unintentional complexity is. As designers, our role is to protect the user from unnecessary friction, without ignoring the intricacies of the system beneath.

✅ Key Takeaway

In the end, building complex tools is about trust. Trust that users can do more — when we give them the right structures to do so. And trust in the process that gets us there.

Clarity & trust, not control, is what unlocks powerful user experiences.

Designing from Scratch: How to Build Complex Tools was originally published in Workable Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Building a brand-aware AI assistant at Workable

Every company wants consistency. Every designer wants autonomy. And every slide deck wants to sabotage both.

At some point in Workable Brand Design, we got tired of rebuilding the same layouts, reapplying color codes, rewriting intros, and hearing:

“Can you just brand this real quick?”

So we built something.
Not a new Figma design system.
Not a folder of templates.
A custom GPT assistant.

Was this just a fancy wiki of our brand guidelines?

Even though our ambitious project started really quickly, using ChatGPT builder, it proved to be quite a lot more than a novelty project.

We trained our “Brand assistant” to understand our brand guidelines, voice, tone, hierarchy, pacing. We fed it logos, color palettes, icon libraries. We walked it through the logic of our design system: when to use a quote block, when not to center-align a paragraph, what a “callout” actually is.

The result?
An assistant that applies brand logic, understands layout, voice, and structure. It wasn’t magical, just methodical. It could find information and resources about everything brand related and present it in an understandable manner to anyone that wanted help branding their projects. Apart from explaining our brand guidelines on demand, it could also suggest copy that was aligned with our tone of voice. But that felt like the easy part, ChatGPT is fairly good with text already.

So, we challenged ourselves. If it could do that… could it actually design? Could it maybe use real content in our Google Slides template and actually respect it?

Version 1: The Frankenbuild

We started scrappy. Using Make.com and a webhook in our ChatGPT build, we duct-taped together a system that worked! Any Workable employee could kickstart their Workable branded deck and get help filling it with relevant copy and images.

The happy user journey went like this:

1. User asks for help creating a deck
2. Assistant asks for more info on the presentation
3. User inputs the required info
4. Assistant mocks up the structured slides content, choosing graphics from a pool of images whenever needed and asks for approval
5. User asks for changes or approves presentation content
6. Assistant asks for permission to run the automation through make.com
7. User approves connection
8. Assistant confirms deck creation and informs user will receive it in their inbox.
9. User clicks inbox link and accesses the branded deck

But it still was a pain for us designers to debug and a pain to use, too. The workflow was unstable, depended on a lot of services and required users to change environments to get their deck.

So we rebuilt.

The agent arrives

We migrated the assistant to n8n, turning it into an actual AI agent. We built it with conditional logic in mind, creating our own MCP server, smartly delegating tasks based on user input.

Instead of cobbling steps together, we created a system that can adapt. The assistant now handles both branded guidance and real-time generation of presentations without sending anyone to a different platform.

The new happy path looked like this:
User prompt → GPT logic → Deck logic → Google Slides export → Inline link

This helped us achieve:

• Faster performance (Selected an LLM that fit the specific need)
• Modular logic (The deck generator became a callable tool)
• Better debugging (n8n logging and error descriptions, even agent self-debugging were heaven sent)
• Better analytics (ability to log requests)
• Tool consolidation (no more multiple tool juggling)
• Better UX (Inline presentation link within chat)
• Ability to host anywhere (can build our own UI)

That last one, sent us vibe coding a custom UI for our Brand assistant, to make it even more… branded. We used Framer’s workshop to build it as a code component, and overlaid it onto our upcoming brand site. And it wasn’t just a simulated chat prototype. It was fully functional, linked to our assistant and complete with type animations and formatted answers.

Going beyond decks

Once the new workflow was stable enough, we felt invincible. We wanted to use the same AI agent for other tasks, like accessing our Figma design system and component libraries to export custom images based on templates. Why not make it intelligently pick an Instagram post layout based on user input and export it within our Brand assistant?

So, we started experimenting with Figma’s new MCP to export components from Figma by triggering it inside the chat.

This allowed us to:

• Export design assets on request, not just fill in our servers with duplicate or obsolete assets
• Extend support to use cases like HR onboarding decks, sales enablement, and quick marketing kits

We got as far as exporting components. Injecting custom text is still a work in progress.

Agentic AI, minus the hype

The buzzword here is “agentic AI” for systems that act with embedded purpose instead of just responding.

This isn’t about automation for its own sake. It’s about giving the assistant enough context to operate as if it understands the system it’s working in.

You can say:
“Here’s a product update.”

And it will return:
“Here’s a branded deck with the right structure, tone, and formatting that makes sense.”

Not because it’s guessing, but because it’s been taught how to think in brand patterns.

A direction, not a product

Everyone wants to talk about what AI can do.
But we’re more interested in what it can understand and how that changes the shape of creative work.

Right now, the assistant builds branded decks and gives guidance. That’s helpful. But how it behaves? That’s the interesting part.

This is a shift from static templates to living brand systems, ones that remember, adapt, and carry intention across teams.

Imagine:

• Helping teams stay on brand without micromanagement
• Cross-functional teams getting tone and voice guidance in the moment
• Surfacing design logic contextually, not buried in a PDF

This isn’t AI replacing designers.
It’s AI keeping the annoying stuff from breaking the good stuff.

Internal reception: quiet, useful, and (almost) invisible

When we shared it internally, the sky didn’t part.
No viral threads. No standing ovations. Just a few nods and a few “can it also…?” messages. Some early adopters were discouraged by early bugs. Some others asked if they could build something like that for their own teams, finding the value behind the geekiness.

It’s not perfect. But neither is any real creative system. Templates alone aren’t scalable. Design systems don’t teach themselves. And teams are tired of opening a 92-page brand PDF to figure out if their quote block is legal.

What matters is building tools that understand your brand deeply enough to reduce the noise, so your focus can go where it actually matters. This assistant filled a gap most design systems don’t even acknowledge. The quiet, daily collapse of consistency.

And that alone was worth building.

Designing with intelligence was originally published in Workable Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Now I’m back at work. Re-entering after time away isn’t just about catching up on tools and workflows, it’s about finding your rhythm again. And like any good product process, it’s messier than it looks on a roadmap.

Re-Onboarding Is a Process, Not a Switch

Whether you’ve taken time off for parenting, caregiving, sabbatical or burnout recovery, the return isn’t a single moment, it’s a phase.

It’s less like pushing a feature live and more like entering a new sprint cycle: new roadmap, new backlog and reevaluated success metrics.

I began to think of my own return through the lens of the Double Diamond, not just as a framework for product design, but as a way to navigate this transition. I even mapped out blockers like a user journey to surface what needed redesigning.

🔍 Discover what’s Changed?
Start with observation. What shifted while you were away, tools, rituals, team dynamics? Ask questions early and often. This phase isn’t about proving anything, it’s about re-orienting with intention.

🧭 Define what matters now?
This is the moment for alignment. What problems are worth solving now, given the team’s goals, capacity and evolving priorities? Collaborate with your product trio (PM, design, engineering) to clarify what success actually looks like in this chapter.

🛠️ Develop new rhythms, new habits
You’re not restoring a backup, you’re configuring a more current version of how you work. Test new routines, adapt your boundaries and iterate on energy rhythms the way you would a feature set.

🚀 Deliver smart, Not Hard
The pressure to prove yourself is real. But re-onboarding isn’t about output for output’s sake. Focus on meaningful impact. Ask where you can unblock your team, improve a flow or add clarity. Your comeback doesn’t need to be loud. It needs to be intentional.

Why Breaks Don’t Set You Back

Time away from work doesn’t erase your experience, it reshapes how you apply it. Research on deliberate rest and neuroplasticity (like Rest by Alex Pang) supports what many feel:

🧠 Breaks can improve long-term clarity, resilience and problem-solving. Still, even with structure and design thinking in place, the learning curve is real.

These were the things I wish I knew before returning:

😌 You won’t feel 100% confident right away and that’s okay
Like user research, it’s messy at first > Clarity comes through immersion so this process requires comfort with ambiguity.

🎯 You might care about your work differently and that’s not a downgrade
Evolving the product strategy as context changes > The same applies to your work. Shifting focus doesn’t mean less engagement, it means better alignment.

🌱 Small wins matter more than fast progress
Minimum viable progress & flashy relaunches > Understanding tools again, contributing to a meeting, asking a useful question is more valuable than you think.

❓ It’s okay to ask “basic” questions
Beginner questions uncover hidden complexity > We ask “why” in product all the time. Your questions might seem simple but they might reveal overlooked gaps.

📣 People won’t know what you need unless you say it
Stakeholders need clear specs, not assumptions > Like in any project, expectations should be explicit and since most teams are willing to support, offer the brief.

What teams can do to support returners

While many organizations have strong onboarding practices, the return experience after extended leave can sometimes lack structure.

According to McKinsey, 43% of women in tech consider leaving after maternity leave due to lack of support. The issue isn’t capability, it’s the re-entry environment (source).

Thoughtful re-onboarding, through buddy systems, async catch-ups and daily check-ins can make a difference. These systems don’t just benefit parents or caregivers, but they can help anyone re-entering the organization and offer more clarity and less friction.

A Personal Paradigm That Helped

When I started re-onboarding, I kept thinking about how we approach design critique sessions, where every designer shares feedback in a weekly collaboration meeting.

At first, I didn’t have full context, so I stepped back, listened closely and took detailed notes. Instead of rushing to contribute, I focused on observing how the team worked: what had changed, what patterns were emerging and how designers were framing problems and solutions.

The lesson was, that you don’t go in expecting to catch up right away, you go in expecting signals, iteration and feedback loops. Notes and to-do lists become your tools for navigating the noise.

That mindset helped me resist the urge to “perform” on day one. I wasn’t there to prove I was up to speed, I was there to learn the new landscape. Listening first helped me understand the landscape more clearly, so when I did contribute, it was with context and not guesswork.

Design Principles for a Smoother Return

When in doubt, lean on what you already know — in my case it was design thinking:

• Start with Curiosity
  You’re not expected to know everything on day one. Ask like it’s discovery because it is for you. You’ll spot misalignments faster by observing without judgment.
• Treat Everything as a Prototype
  Routines, rituals, communication rhythms, they’re all temporary. Try something and adjust it if needed. Nothing has to be final, since your return can look like a series of soft launches.
• Optimize for Meaningful Work, Not Maximum Capacity
  Being at full bandwidth isn’t the same as being effective. Focus on the projects where your presence actually changes the outcome.
• Leave Whitespace
  Don’t let your calendar fill up like a cluttered interface. In the early weeks especially, block extra focus time, you’ll need space to catch up, think clearly and reorient. Sometimes the best work happens in the margins.
• Make Your Process Visible
  Share what’s unclear. Transparency builds trust, but it also sets expectations and that’s good design in any system.

Closing Thought

Taking time off can be disorienting. The return is often slower than expected and harder to define. But it also creates space to rethink how you work, what you value and how you want to show up again. It’s not about coming back better, but returning with awareness and designing your way forward.

A Designer’s Perspective: Re-Onboarding Myself After a Year Away was originally published in Workable Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

But some apps look at those rules, shrug, and do their own thing.
And somehow, they don’t just survive — they win.

Why? And more importantly: when is it actually worth breaking the rules?

Why guidelines exist in the first place

UI frameworks like Material Design and Apple’s Human Interface Guidelines aren’t just visual kits. They’re full-stack opinions — design and engineering patterns wrapped into a system.

They solve fundamental problems:

• Predictability. Users know what to expect.
• Usability. Components are tested, accessible, and optimized for real-world use.
• Stability. When platforms evolve, apps that follow the rules tend to break less.
• Speed. Teams can ship faster using pre-built, well-documented components.
• Reliability. Less custom code means fewer bugs, especially across devices.

They’re especially useful when you’re building for scale, when your team is small, or when speed-to-market matters more than personality.
In short: guidelines reduce uncertainty — for both the user and the team building the product.

But they also introduce constraints:

• You inherit someone else’s visual language
• You’re boxed into standard patterns, whether they serve your use case or not
• Custom interactions often require hacking the framework or building from scratch — which means more tech debt

So while frameworks give you structure, they also define the shape of your product. And sometimes, that shape isn’t what you want.

“Consistency is one of the most powerful usability principles: when things always behave the same, users don’t have to worry about what will happen.”
- Jakob Nielsen

When guidelines become… suggestions

Instagram

Instagram plays a different game. It doesn’t rebel — it adapts, it doesn’t outright break the rules — it selectively bends them.

Rather than sticking strictly to iOS or Android conventions, it evolves based on cultural trends: flat design, minimalism, blurred backgrounds, bold typography — often ahead of the OS itself.

You won’t see platform-native bottom sheets or pickers unless they fit the vibe. The priority isn’t to “look native,” but to feel relevant — visually and socially.

Instagram doesn’t break the rules to stand out. It bends them to stay in sync with culture.

Spotify

Spotify goes a step further. It’s not just adapting aesthetics — it’s rebalancing native behaviors. It is a masterclass in platform-specific compromise. Open it on iOS and Android — it’s not the same, but it’s also not wildly different.

They keep the core experience aligned but aren’t afraid to tweak layouts, gestures, or behaviors where the platform expects it. But more importantly, Spotify didn’t grow by looking different. It grew by sounding different — and feeling different. Seamless playback across devices, deep personalization, no interruptions. The product experience came first — and design evolved to support it.

They didn’t break the rules for style. They did it to build something worth investing in.

Tinder

Tinder throws out the rulebook entirely. Swipe left. Swipe right. You know exactly what that means — even if you’ve never used the app.
That core interaction isn’t part of any official guideline. It breaks discoverability norms, ignores standard navigation, and would likely raise a red flag in any HIG review.

But it works. It’s fast, tactile, and emotionally charged.

It didn’t borrow a pattern — it invented one.

In Tinder’s case, the UI is the product.

And for that, no existing framework would’ve been enough.

“A user interface is like a joke. If you have to explain it, it’s not that good.”
- Martin LeBlanc

Why they can get away with it

Breaking the rules isn’t about being bold — it’s about being ready. These companies don’t just ignore guidelines. They understand exactly what they’re walking away from, and what they’re building instead.

Here’s why they can pull it off:

• They have strong product-market fit.
  Their users aren’t just tolerant of unconventional design — they expect it.
• They own their design language.
  When your brand is the experience, platform consistency becomes optional.
• They have the resources to maintain custom UI.
  Breaking from frameworks means writing and maintaining your own components, handling edge cases, and staying ahead of OS changes. That’s not cheap.
• They prioritize user outcomes over platform compliance.
  If a “non-standard” interaction better serves the core experience, they’ll take the risk.

In other words: they break the rules because they know them — and know exactly what they’re trading off.

So what happens when you break the rules?

Breaking design guidelines isn’t inherently good or bad — it’s a tradeoff. It can help you stand out, but it can also slow you down, confuse users, or cost you engineering time.

✅ Pros

• You can differentiate your product visually and interactively
• You can design for your specific use case, not the lowest common denominator
• You can create new patterns that become part of your brand identity

⚠️ Cons

• You increase dev and maintenance costs (especially across platforms)
• You risk confusing users if interactions aren’t intuitive
• You’re more vulnerable to OS changes — a breaking iOS update could break your custom modal

But most importantly: breaking the rules is only worth it if it leads to a better experience. Spotify didn’t become huge because it looked different — it invested in an experience that felt different: continuous playback, deep personalization, seamless transitions across devices. Design supported that.

Being unconventional is easy. Being intentional is what makes it work.

So… should you break the rules?

Design guidelines are not sacred texts. They’re starting points. They’re great when you’re moving fast, scaling up, or building trust in a new product.

But once you own your product’s identity, and you’ve earned the right to challenge expectations — that’s when it makes sense to deviate.

Just ask yourself:

1. Is the deviation solving a real UX problem?
2. Do you have the resources to maintain and QA custom behavior?
3. Will breaking this pattern improve clarity, delight, or usability?

If the answer is “yes” — then break the rule.
But break it on purpose, not because “the default button looks boring.”

Like any rule in design:
Learn it. Follow it. Then, if you must — break it with intent.

Written with the help of AI. Let’s connect on Linkedin!

“Know the rules well, so you can break them effectively.”
- The Dalai Lama (surprisingly relevant in UX too)

Tinder Doesn’t Care About Your Guidelines (And That’s Fine) was originally published in Workable Design on Medium, where people are continuing the conversation by highlighting and responding to this story.