You know that thing in Season 2 of Stranger Things where Will keeps seeing the Shadow Monster? At first it’s just flickers. A dark shape in the sky over Hawkins. Something deeply wrong that he can’t quite explain. He tries to tell Joyce, to tell the others, and they believe him, sort of, but nobody really understands the scale of what he’s seeing. Each vision gets worse. The thing in the sky gets bigger, closer, more unavoidable. By the time the rest of the group finally grasps what they’re dealing with, it’s already taken hold.

That’s feature bloat. Not the kind that shows up overnight. The kind that grows a little bigger after every sprint while the people building the product keep saying “it’s fine, we’ve got it under control.” They’re not wrong about any individual decision. They just can’t see the shape of the thing they’ve built.

I’ve seen this happen at every company I’ve worked at. A sales team needs something to close an account. Customer success needs a workflow to keep a client from churning. The CEO goes to a conference and comes back fired up about some capability a competitor showed off. Each ask lands on the roadmap for a perfectly good reason. Nobody’s making a bad call in isolation.

But zoom out two years, and the product has quietly become a sprawling messy monster. It does a lot of things adequately and nothing memorably. Users can’t find what they came for because it’s buried under stuff that was built for reasons they’ll never know about.

So what happened? No single bad decision. Just a long series of reasonable ones that nobody ever stepped back to evaluate together.

The “Yes” Machine

Think about the last time someone in a roadmap meeting said “we shouldn’t build that” and the room actually listened.

If you’re struggling to remember, you’re not alone. Product organizations are basically engineered to say yes. Requests show up attached to revenue, or a competitive threat, or a frustrated customer, or someone with enough authority that pushing back is a career risk. And I mean that literally. If the person asking can promote you or fire you, saying “I don’t think we should build that” stops being a design decision and starts being a political one.

The person pushing the request always has a story. “We’ll lose this account.” “Our competitor already has this.” “The board is asking about it.” Those stories are specific and urgent, and they’re hard to argue with even when you have the standing to try.

Arguing for restraint means defending something abstract. You’re essentially saying “the product will be better in six months if we don’t do this,” and good luck getting anyone excited about that.

There’s a great study from 2021 by Gabrielle Adams and her team at UVA, published in Nature, that helps explain why this keeps happening. They ran eight experiments where people were asked to improve things, everything from Lego structures to miniature golf courses, and found that people almost always reach for adding rather than subtracting. Even when removing something would have worked better. They called it “additive bias,” and it got worse when people were under time pressure or cognitive load.

That was a lab setting, not a roadmap meeting. But think about it: a product team under deadline pressure, juggling competing stakeholder demands, trying to make decisions with incomplete information about what users actually need? That’s cognitive overload as a lifestyle. If additive bias shows up when someone’s solving a puzzle under a time crunch, of course it shows up when your team is planning the next quarter.

And AI has removed what little friction was left. When building a feature used to take multiple engineers, designers and a sprint, the cost alone forced some evaluation. Now an AI coding tool can spit out a working version in a day. The barrier between “someone asked for this” and “it’s in the product” is thinner than it’s ever been. The yes machine didn’t just get louder. It got faster.

Adding features isn’t the problem by itself. Sometimes aggressive addition is exactly the right move. Slack, Notion, Figma, all of these products went through periods where they were shipping fast and it was smart. When you’re chasing competitive parity or figuring out product-market fit, restraint can actually hurt you. The problem starts when addition becomes the default and nobody’s asking what all those features are doing to the product. You can ship a lot and stay focused. You just have to actually look at the whole picture once in a while, and most teams don’t.

You Can Spot It

I can usually tell when a product’s been run on autopilot for a while. There are a ton of features and none of them feel finished. Half of it was built to close a specific deal or because a competitor had it. The rest was somebody’s passion project. And none of it was designed as a coherent whole, which you can feel the second you start poking around. The navigation has ballooned. New users land in the product and face a wall of options with no clear path to the one thing they actually need. The structure isn’t organized around what users need. It’s organized around when things got added.

Users are dropping off during onboarding because features that shipped fast to meet a deadline keep confusing people. And the design team is stuck maintaining the mess instead of improving anything meaningful. Nobody planned for the product to end up like this. Every team contributed a little, one reasonable decision at a time.

You’ve probably already seen the newest version of this too, features that exist because AI made them easy to build, not because anyone asked for them. An AI-powered summary, a smart suggestion panel, a copilot bolted onto a workflow that was working fine without one. These ship under the banner of “AI-first” strategy, and they’re usually driven less by user need than by leadership wanting to signal that the product is keeping up with the moment. It’s the same pattern wearing a new outfit. The features arrive for reasons that sound strategic, and nobody stops to ask what they’re doing to the product.

Learning to Make the Unpopular Argument

So if the system is set up to keep saying yes, what can a designer actually do about it?

The most valuable thing you can bring to a product team is the willingness to say “I don’t think we should build that.” Call me naive, but I think that’s a real superpower when it’s done right. The tricky part is that doing it right requires skills not many people have, but it can be learned. You need organizational awareness, the ability to read a room, and enough spine to hold a position when people push back. And they will push back, because you’re standing between them and the thing they want.

How hard it is depends on who’s asking. Telling a sales lead that a feature request might not be worth building is one thing. Telling the CEO their conference-inspired idea doesn’t fit the product strategy? That’s a whole different conversation. And pushing back on your own engineering partners when they’re excited about a technical challenge is tricky too, because those are the people you collaborate with every day and you don’t want to be the person who’s always killing momentum.

Nobody teaches you how to navigate this stuff.

And that CEO scenario? When the person asking outranks you by three levels, you probably aren’t going to win a head-on argument, and trying might cost you more than the feature is worth. What you can do is build the case quietly. Get your PM on your side first. Frame your concerns as questions rather than objections: “How do we make sure this doesn’t complicate onboarding?” or “Can we scope this so it doesn’t touch the core workflow?” Sometimes you redirect the energy into a smaller, less damaging version. And sometimes, honestly, you document your concerns, let it ship, and make sure the data is there to tell the story six months later when the team revisits it. Not every battle is one you fight in real time.

And it’s gotten even harder now that everyone’s role is bleeding into everyone else’s. When PMs are mocking up screens in Figma, engineers are making UX calls, and everyone has access to AI tools that can generate “good enough” design work, who exactly is supposed to be the one saying “we shouldn’t build this”? If nobody clearly owns that job, nobody does it. And the product keeps growing. That’s also the opportunity, though. The designer who steps into that gap, who says “I’ll be the one watching the whole experience,” becomes one of the most valuable people on the team.

Let the Data Make the Argument

In my experience, data makes the argument for you. Gut instinct and design principles won’t carry you very far when someone’s waving a revenue target. But usage metrics, session drop-off rates, time-on-task numbers, etc? Those change the temperature. If you want to be the person who can say no effectively, start by becoming the person who knows the numbers.

I can already hear some of you thinking: “Great, but I don’t even have access to that data.” Fair. In a lot of organizations, designers don’t have dashboard access. They don’t know SQL. They aren’t invited to the meetings where metrics get reviewed. If that’s you, getting access is step one, and it’s worth treating as a real project rather than a thing you’ll get around to. Ask your PM to add you to the analytics tool. Sit in on a metrics review and just listen. Ask engineering to pull a report for you and study it until you can ask for the next one in specific terms. You can’t argue with numbers you don’t have, so getting the numbers is the job before the job.

Of course, sometimes the designer is wrong. The feature that feels like clutter to you might be solving a real problem for users you haven’t spent enough time with. Saying no well means doing your homework first, researching before you react. The goal is to be the person who asks the right questions before the team commits, not the person who blocks everything.

Some Practical Ways to Get Started

If you’re reading this and thinking “okay, but what do I actually do on Monday,” here are some things that have worked for me and for teams I’ve been part of.

Before building, ask what happens if you don’t. But don’t just silently sit on the request for two weeks and hope it goes away, because that will get you labeled as a blocker fast. Instead, name the delay out loud. Go to your PM or the stakeholder and say something like “I want to make sure we’re building the right version of this. Can we give it two weeks to validate the assumption before we commit engineering time?” You’re framing it as diligence, which it is. Align with your PM first if you can, so you’re not the lone voice pushing back.

You’ll be surprised how often, in those two weeks, the deal closes anyway, the competitive urgency fades, or the person who was fired up about it moves on to something else. Two weeks of breathing room can save you months of maintenance on a feature nobody ends up using.

Do a feature audit on one section of your product. Just one. If you try to audit the whole thing at once you’ll lose a week and your will to live. Pull whatever usage data you can get your hands on, even basic analytics will do. Look at which features people actually use and which ones are sitting there confusing people.

But be careful with how you interpret what you find. A feature with low usage isn’t automatically dead weight. It might be buried in the nav and nobody can find it. It might be used by a small percentage of users who happen to be your highest-value accounts. You’re not building a kill list. You’re looking for patterns, features that are rarely used and generate confusion, features that overlap with each other, features where the maintenance cost clearly outweighs the value.

When you propose removing something, lead with what the team gets back. “If we sunset this feature, that frees up two sprints this quarter. Here’s what we could build instead.” People who get nervous about taking things away respond much better when they see what they gain in return.

And if you can swing it, get your team to dedicate even 10% of each sprint to simplification. When simplification has a budget, it becomes real work instead of something everyone agrees is important and never gets around to doing.

Your PM Wants Your Help

You might be thinking “isn’t this the product manager’s job?” And yeah, in theory, ruthless prioritization is exactly what PMs are supposed to do.

In practice, it depends on where you work. If you’re at a sales-led or enterprise-driven company, your PM is probably under enormous pressure to ship whatever closes deals. They’re measured on throughput. They’re caught between sales, customer success, and leadership, and saying no to any of those groups has real career consequences. If you’re at a product-led growth company where PMs are measured on retention, activation, etc, it’s a different story. Your PM might already be doing this. But even in those orgs, having a design partner who shows up with experience data is valuable.

The best PMs I’ve worked with, and I mean the ones where the collaboration actually felt like a partnership, were grateful when I showed up with a clear picture of what the product experience actually felt like for users. It gave them cover to make calls they already wanted to make but couldn’t justify on their own.

You’re not replacing your PM or telling them how to do their job. You’re just showing up with something they don’t have time to build themselves: a clear picture of what all those accumulated features are doing to the people who use the product every day. When you can walk into a prioritization meeting and say “here’s what our product feels like to a new user right now, and here’s what adding this will do to that experience,” it shifts the whole conversation.

Nobody’s going to throw a launch party for the feature you killed.

Remember Will trying to warn everyone about the Shadow Monster? He could see the threat growing when nobody else could. That’s you. You’re the one who can see the shape of the thing when everyone else is focused on individual decisions. Except instead of visions of the Upside Down, you’ve got usage data and onboarding funnels. Which, honestly, are more convincing in a roadmap meeting.

Once you get the team to see what you’re seeing, they can actually do something about it. And the product that comes out the other side? That’s the one people stick with.

Summary: Craft gets you hired, but influence gets you heard. James Hsu's talk on designer impact breaks down how to frame your work in business terms, build trust across functions, and make sure your design recommendations don't get ignored.

I recently hosted a talk by James Hsu, a design leader who has built his career across places like Disney and Live Nation. The talk was called “Being Good at Design Isn’t Enough,” and if you’ve been in this industry for more than a few years, that title probably gets you.

One of his slides was about how to talk to stakeholders so they actually listen. Something on that slide stuck with me.

Most new designers aren’t prepared for what James said next. You can be an exceptional designer and still get completely ignored. You can deliver pixel-perfect work, and still watch your recommendations get overruled by someone who barely knows what Figma is. Not because your work was bad. Because you never learned how to make people care about it.

The Craft Ceiling

Early in your career, craft is everything. It should be. You need to learn the fundamentals: typography, layout, hierarchy, research methods, prototyping, visual storytelling, etc. Those skills earn you your first job, maybe your second. They’re the price of admission.

But somewhere around year three or four, something shifts. You start noticing that the designers who get promoted aren’t always the ones with the tightest UI. The people who shape product direction aren’t necessarily the best visual thinkers in the room. The people who get pulled into strategy meetings early? They speak a different language than the rest of the design team.

They’ve figured out something that took me years to learn: influence is a skill, and it’s separate from design skill. You can have one without the other, but you need both if you want your work to actually matter.

James put it plainly, your design skills have a ceiling if you can’t also build influence, earn trust across the business, and show that you understand what the your organization is trying to accomplish. That’s not a knock on craft. It’s a recognition that craft needs a vehicle to travel in, and that vehicle is your ability to communicate, persuade, and connect your work to what the organization actually cares about.

Learning to Speak Business

So what does this look like in practice? First, it’s worth understanding why framing your work in business terms matters so much. You’re not dumbing it down. You’re making it possible for non-designers to advocate for your work in rooms you’re not in. Your PM can’t go to their boss and say “we nailed the micro-interactions.” But they can say “this redesign should cut churn by 15%.” Speaking business means your work can travel without you.

James outlined four ways to measure the value of what you’re doing.

It makes money. Maybe your redesign improves conversion. Maybe it opens up a new revenue stream. If you can tie your work to dollars, people listen.

It saves time. A streamlined workflow, fewer steps in a process, less back-and-forth with support. Time is money, and everyone in the room understands that.

It prevents something bad from happening. Risk reduction is value. A well-designed flow that keeps users from getting confused and filing support tickets saves real money.

It makes us look good. Brand perception matters. A polished, well-considered experience builds trust with customers and gives the company a competitive edge.

If you can’t connect your design work to at least one of those four, you’re going to have a hard time convincing anyone outside of your design team that what you’re proposing matters.

Think about how most designers present their work. They explain their rationale in design terms. Consistency, usability, delight. All good things. All important things. But none of them land the way “this will reduce support tickets by 30%” does. None of them resonate like “this checkout flow redesign could recover $2 million in abandoned carts.”

The shift isn’t about ditching design language. It’s about becoming bilingual. You still think in design. But when you walk into a room with product managers, engineers, and executives, you translate your thinking into their language. You start with their goals, not your Figma.

How to Build Influence

Building influence doesn’t mean becoming a corporate schmoozer. It means developing a set of complementary skills that help your design work ship. Here’s what I’ve seen work, both in my own career and in watching designers grow through the programs I lead.

Mirror their language. This was another standout point from James’s talk. When your PM talks about conversion rates, you talk about conversion rates. When your engineering lead is worried about implementation complexity, you acknowledge that before jumping into your ideal solution. People trust people who seem to understand their world. If you only ever speak in design jargon, you’re building a wall between yourself and the people who need to say yes to your ideas.

Frame your work as a business case, not a design case. Before your next design review, ask yourself: which of those four value lenses does this work connect to? Does this redesign make us money? Save the team time? Prevent a bad experience that’s costing us customers? Make the brand look sharper in a competitive market? If you can answer that question clearly, you’ve already separated yourself from most designers in the room.

Ask smart questions early. One of the fastest ways to build credibility with cross-functional partners is to ask questions that show you understand the bigger picture. Instead of waiting for a brief and then designing to spec, try asking things like “What does success look like for this feature from a business perspective?” or “What are we most worried about with this launch?” These questions show that you’re thinking beyond the screen.

Plant seeds early. This was the last tip from James’s stakeholder communication framework, and it’s one that early-career designers almost never do. Don’t wait for the big reveal to share your thinking. Socialize your ideas informally. Drop hints in Slack. Share rough sketches over coffee. By the time you present the polished version, the key decision-makers should already feel a sense of ownership over the direction. If the first time your stakeholders see your work is in a formal review, you’ve already lost half the battle.

The Hardest Part

The hardest part of all this isn’t learning the skills. It’s accepting that you need them.

A lot of designers, especially early in their careers, feel like the work should speak for itself. And I get it. You got into design because you love making things. You love solving problems visually. You love the craft. The idea that you also need to be a negotiator and a translator can feel like a betrayal of why you chose this field in the first place.

But think about the designers you admire most. The ones leading teams at the companies you want to work for. The ones shaping products that millions of people use. They didn’t get there by being the best person in Figma. Well, they might be really effing good. But they got there by combining strong craft with the ability to influence decisions, build trust, and articulate why design matters in terms that resonate beyond the design team.

Start Small

You don’t need to overhaul your entire approach overnight. Pick one meeting where you consciously translate your design rationale into business impact. The next time you present work, lead with the problem you’re solving for the business, not the screen you’re showing. Ask one question in your next cross-functional meeting that shows you’re thinking about more than pixels.

These are small moves, but they compound. And over time, they change how people perceive you. Not just as a talented designer, but as someone who understands what the team is trying to accomplish and can help get them there.

James Hsu’s talk was a reminder I needed to hear, and one I think a lot of designers need. The best designers aren’t just good at design. They’re good at making design matter to the people around them. That’s not a compromise. That’s the whole job.

Summary: Every 2026 design trend report says the same thing: AI output looks generic, and the answer is craft, texture, imperfection. The diagnosis is right. But the explanation underneath it is incomplete. AI doesn't look the same because it's too polished. It looks the same because the models converge on narrow defaults and we're drowning in the volume. And the craft response, when it skips the intentionality, is just a different kind of shortcut.

I've been reading a ton of 2026 design trend reports. After a while, they all start to feel like everybody got the same memo.

Creative Bloq says this year is defined by "the deliberate rejection of AI's hyper-polished aesthetic." (Creative Bloq, December 2025) Kittl's trend report talks about designers using imperfection "to inject soul into the algorithm." (Kittl, January 2026) Graham Sykes at Landor coined "Anti-AI Crafting." The consensus is everywhere, and the diagnosis isn't wrong. AI output really does have a particular aesthetic problem. But I think the conversation keeps getting stuck on the surface when the interesting part is happening underneath.

Right About the What. Wrong About the Why.

AI-generated visuals have a recognizable sameness. That smooth, glossy, odd quality. You scroll through a feed and everything blurs together. Not necessarily ugly. Just... generic. Hyper-polished in a way that feels empty. Nick Foster, who’s explored the future for Apple, Google, Nokia, and Dyson, told Dezeen he’s tired of design’s “homogenous gloss” where everything is “neat, tidy, polite and free from anything gritty, confrontational or different.” (Dezeen, January 2026)

Most of us feel that. But the trend reports frame it as AI being “too polished” or “too perfect,” and the solution as embracing human imperfection.

AI doesn’t default to that sterile aesthetic because it’s too good. It defaults there because of how the models are trained. They converge on overlapping data, average out the edges, and land on a narrow range of visual defaults. The sameness isn’t a sign of quality. It’s a sign of statistical tendency. Combine that with the massive volume of AI output flooding every visual platform, and you get a landscape where everything feels like it came from the same place. Because… it did.

And that changes what the answer looks like. If you think the problem is that AI is “too polished,” the answer is to make things rougher. If you understand that the problem is narrow aesthetic defaults and volume, the answer is to bring stronger creative direction to the process, whether that means handcraft, AI-assisted work, or anything in between.

The Beauty Mark Problem

The instinct behind Anti-AI Crafting is good. Designers reaching for texture, physical materials, hand-built work, visible process marks? I’m into that. Burberry’s Cross-Stitch Knight Life campaign merged craftsmanship with fashion in a way that felt intentional. Madalena Studio cultivated bacteria on a cork logo for the brand Crucible and documented its organic growth. (Creative Bloq, December 2025) That kind of work resonates with me because every decision in it was deliberate.

But Elizabeth Goodspeed, writing for (It’s Nice That), raised a great follow-up question. Most designers don’t have the time, tools, or support to do fully analogue work. The infrastructure isn’t there. So what happens instead is strategic mimicry: the market wants “handmade” cues, and designers simulate them digitally. She compared it to penciling in a beauty mark. An intentional imperfection designed to signal authenticity, not the result of an actual process.

Think about what that means. Slapping a rough texture on a design to signal “not AI” and generating a hyper-polished image without thinking about it are two sides of the same coin. Both skip the creative decision-making that actually makes design meaningful. The aesthetic is different, but the thoughtlessness is the same.

It Was Never About the Tools

The designers getting the best results right now, whether they’re working with their hands or with AI, are the ones bringing strong intentionality to the process. The medium isn't what matters. The thinking behind it is.

We had sameness before generative AI. Template culture, stock photo dependency, Dribbble-driven homogeneity. The tools change. The underlying problem doesn’t: when we optimize for speed and volume without creative direction, EVERYTHING converges.

AI just made the convergence faster and more visible. Which means the opportunity is also more visible. If you’re willing to push past the defaults, to treat AI output as raw material instead of finished product, or to invest the time in craft, the gap between intentional work and everything else has never been wider.

The sameness problem is real. But the solution isn’t as simple as making things rougher. It's about being more deliberate.

“You need to think more about the business.”

Your manager just said those words in your performance review. Or maybe it was “be more strategic” or “develop more product thinking.” You nod, scribble it down in your notes, and walk out feeling... what exactly? Motivated? Confused? A little of both? You update your development goals: “Become more business-minded.” Check. Goal set. Growth mindset activated.

Three months later, you’re sitting at your desk wondering if you’ve actually done it. Are you more strategic now? You think so? Maybe? You attended a few more meetings. You asked some questions about the roadmap. Does that count?

Spoiler alert: your manager is wondering the same thing.

I talk to designers at every stage of their career, from fresh grads to seasoned design leaders, and they’re all wrestling with the same ghost. They tell me they’re “working on being more strategic” or “developing their leadership presence” or “getting more business-minded” or “building stronger product sense.” These goals sound great when you say them in a 1:1. They look professional written down in your development plan.

They’re completely useless. Not because the aspiration is wrong, but because nobody can tell if you’ve succeeded. Not you. Not your manager. Not the people deciding your fate six months from now.

Vague goals aren’t just unhelpful. They’re actively harmful to your career growth. They let you spin your wheels feeling productive while making zero measurable progress. They give managers an excuse to deny your promotion because “you’re not quite there yet” without ever defining what “there” actually looks like. And worst of all, they rob you of the satisfaction of knowing you’ve legitimately leveled up.

Let’s fix that.

The Vagueness Trap

When I'm having these career conversations and someone tells me their goal is to "be more strategic", "build product sense", or "become a stronger design leader," I like to ask a simple question: "If I followed you around with a camera for three months, what specific behaviors would I see that would prove you'd achieved this goal?"

The silence that follows is telling.

Here’s what makes goals like “be more strategic” so insidious: they’re aspirations masquerading as actions. You’re describing who you want to be, not what you’ll actually do. And the human brain is terrible at turning abstracts into concrete behaviors without explicit translation.

Think about it this way. If your doctor told you to “be healthier,” you’d probably feel motivated for about 48 hours before reverting to your usual habits. But if they said “walk 30 minutes five days a week and eat three servings of vegetables daily,” you’d know exactly whether you did it or not. You could track it. You could prove it. You could adjust when it’s not working.

Your career goals deserve the same clarity.

The Real Goal Crime Scenes

Let me show you what I mean with actual examples from career conversations I've had. In each case, we took a vague goal and turned it into specific, observable actions.

Crime Scene #1: The Strategic Thinking Trap

Before: “I want to develop strategic thinking skills so I can contribute to product direction.”

When I asked the designer what this actually meant, they gave me a word salad about “seeing the big picture” and “thinking beyond the pixels” and “having a seat at the table.” Noble! But meaningless.

After (what we worked out together):

• Attend and actively contribute to 2 quarterly roadmap planning sessions with at least one recommendation that gets incorporated into the plan

• Schedule monthly 1:1s with product managers to understand their strategic priorities and constraints

• Present a 10-minute “competitive landscape analysis” to the design team once per quarter, highlighting 3 strategic implications for our product

Notice the difference? Every single item is observable (someone could watch you do it), countable (you know if you did it or not), and time-bound (you know when you’ve hit the mark). More importantly, these behaviors will actually make you more strategic because you’re forcing yourself into the contexts where strategic thinking happens.

Crime Scene #2: The Leadership Mirage

Before:

• “Grow my leadership skills and mentor junior designers”

Again, sounds great on paper. But what does “mentorship” actually look like? Is it occasional Slack advice? Is it grabbing coffee once? Is it a structured apprenticeship?

After:

• Establish a formal mentorship relationship with one junior designer, meeting weekly for 30-minute sessions with a shared agenda

• Lead 2 design critiques per month where I facilitate discussion (not just present my own work)

• Document and share my design decision-making process in at least 4 detailed case studies this year

• Shadow 3 senior designers or design leaders in their stakeholder meetings and 1:1s (with permission) and synthesize what I learned in a reflection document

Now we’re talking. These aren’t just things to check off. They’re developmental experiences that will actually build your leadership muscle. And at the end of the year, you can point to concrete evidence: “I mentored Sarah, who shipped her first feature. I led 24 design critiques. Here are my case studies. Here’s what I learned from shadowing Jane, Michael, and Alex.”

Crime Scene #3: The Business Acumen Black Hole

Before:

• “Better understand the business side of design”

This one kills me because it’s SOOO common, and SOOOO vague. What business side? Finance? Marketing? Sales? Strategy? All of it?

After:

• Complete a business fundamentals course (specific: “Business Strategy” on “insert your platform here”, 6-week commitment)

• Interview 5 people from different business functions (PM, Sales, Marketing, Engineering, Customer Success) using a standard set of questions about how they measure success

• Request access to our quarterly business reviews and attend at least 3, taking notes on which metrics drive decisions

• Calculate the business impact of 2 of my design projects using revenue, conversion, or cost-savings metrics, and present findings to my team

Not only are these actions observable, but they also create artifacts. You’ll have course completion certificates, interview notes, business review insights, and impact calculations.

The Observable Behavior Framework

So how do you transform your own vague goals into something actually useful? I use what I call the OTT Framework: Observable, Time-bound, Trackable.

If you've heard of SMART goals, think of OTT as the streamlined version - focused specifically on making your career development visible and verifiable.

Observable: Can someone see you doing it?

The test here is simple: could you film yourself doing this behavior? If not, it’s too abstract.

• ❌ “Think more strategically” (nobody can see you thinking)

• ✅ “Present at strategy meetings” (clearly observable)

• ❌ “Be a better collaborator” (too subjective)

• ✅ “Initiate cross-functional working sessions with engineering bi-weekly” (you either did it or didn’t)

Time-bound: When will you know you’ve done it?

Vague goals have no deadline, which means they’re never really done. Observable goals have built-in timeframes.

• ❌ “Improve my presentation skills” (when? by when? how much?)

• ✅ “Deliver 6 presentations to audiences of 20+ people in the next 6 months” (specific count and timeline)

Trackable: Can you count it or measure it?

This is where most people stumble. They want credit for “effort” or “growth” without defining what that actually means.

• ❌ “Work on my design system skills” (how much work? for how long?)

• ✅ “Contribute 12 components to the design system and document them in Storybook” (specific deliverable)

When you combine all three, an OTT goal isn’t just a todo item. It’s a behavioral change you can prove happened.

Converting Your Goals Right Now

If you’re reading this thinking “oh crap, all my goals are vague,” don’t worry. You’re in good company. Here’s how to fix them:

Step 1: Write down your current vague goal

Example: “Become a better designer”

Step 2: Ask yourself: “What would I actually be DOING differently if I achieved this?”

• Reading design books regularly

• Getting more feedback on my work

• Studying other products more deeply

• Practicing new design skills

Step 3: Convert each behavior into OTT format

• Read and write reflections on 12 design books this year (1 per month)

• Share work-in-progress designs for feedback in team critique at least twice per month

• Conduct and document 24 product teardowns (2 per month) analyzing interaction patterns, information architecture, and visual hierarchy

• Complete 4 skill-building exercises from “Daily UI” and post before/after examples

Step 4: Add accountability and evidence

• Keep a Notion database of books + key takeaways

• Track critique participation in a spreadsheet

• Build a “teardown library” that becomes portfolio content

• Create a “skills practice” case study showing your progression

See how much more actionable that is than “become a better designer”? By doing these specific behaviors, you actually will become a better designer. But now you can prove it.

The Career Payoff

When your goals are observable, time-bound, and trackable, your performance reviews transform from vague vibes to evidence-based discussions.

Imagine walking into your year-end review with this:

Manager: “So, how do you think you did on becoming more strategic?”

You: “Well, I set a goal to contribute to roadmap planning. I attended both quarterly planning sessions and got two recommendations into the roadmap (the mobile-first redesign priority in Q2 and the accessibility audit timeline in Q4). I also met monthly with Jordan and Sam from product to understand their constraints, which helped me propose solutions that actually fit our technical roadmap. And I presented competitive analysis to the design team four times. Here are the decks, which helped us identify three feature gaps we’re now addressing.”

That’s not spin. That’s documentation. Your manager doesn’t have to rely on their subjective impression of whether you “seem” more strategic.

You’ve got receipts.

And when you’re interviewing for your next role or making the case for a promotion, this same approach works. You’re not just claiming growth. You’re showing the work with actual artifacts: the presentations, the recommendations that shipped, the outcomes.

Compare that to saying “I developed my strategic thinking skills” with zero evidence. Which story is more convincing? Which designer gets the promotion?

The one who can show their work.

Every. Single. Time.

Your Move

If you take nothing else from this article, take this: vague goals are career potato chips. They feel good when you write them down, but they don’t actually nourish your growth.

The designers who advance fastest aren’t the ones with the most impressive-sounding goals. They’re the ones who can point to specific behaviors they’ve changed, specific experiences they’ve accumulated, and specific evidence of their growth.

So go look at your current professional development goals. Ask yourself: “If someone followed me with a camera, would they be able to see me doing this?”

If the answer is no, you know what to do.

Make it observable. Make it time-bound. Make it trackable. And then go do it.

Summary: After struggling with generic stock photos for a client project, this designer spent three months testing Krea.ai, Midjourney, and Visual Electric to find which AI image generation tools actually work for professional design. Krea.ai excels at custom training and real-time generation, Midjourney produces beautiful but obviously AI-generated images, and Visual Electric offers the best workflow integration for designers. The biggest takeaway: these tools replace old creative constraints (budget, availability) with new ones (algorithmic aesthetics, platform limitations) that designers need to understand and work within.

Earlier this summer, I was creating a presentation slide deck for a consulting project, scrolling through my 47th page of stock photos trying to find imagery that matched the client's brand tone. They had a sophisticated, minimalist aesthetic, think clean lines, muted colors, premium feel but every search returned the same sterile corporate imagery.

"Modern minimalist" gave me stark white backgrounds with floating objects that felt cold rather than premium. "Sophisticated business" delivered more of those forced handshakes and people pointing at charts. I tried "luxury minimal" and got marble surfaces with gold accents that screamed high-end retail, not the thoughtful professionalism my client embodied.

I needed imagery that felt authentic to their brand, but everything looked like it came from the same generic playbook. After two hours of searching, I was no closer to finding anything that fit.

This wasn't the first time I'd hit this wall. As someone who's spent years crafting visual experiences, I've felt this tension between having a clear vision and the constraints of available imagery. Stock photos rarely capture the exact mood or aesthetic I'm after. Custom photography isn't always in the budget or timeline.

I've played with various AI image generation tools in the past, but nothing seriously. That's when I decided it was time to evaluate AI image generation tools for my design practice.

The AI image generation space is crowded and confusing, so I wanted to be methodical about this.

The Testing Goal

Rather than getting swept up in feature comparisons or hype, I wanted to understand how these tools would actually work in practice.

The challenge with AI image generation tools is that they all sound impressive on paper. Every platform promises high-quality results, easy interfaces, and revolutionary capabilities. But the real question isn't what they can do in theory, it's how they perform when you're solving real creative problems.

I wanted to know which tools would genuinely improve my work; make it better, faster, or more creative. Which ones would I reach for under deadline pressure? Which interfaces felt intuitive versus frustrating? And which tools produced results professional enough to show clients?

I spent the better part of three months testing Krea.ai, Midjourney, and Visual Electric to see which ones actually delivered on their promises.

Krea.ai

When I first opened Krea.ai, the training capabilities immediately caught my attention.

Krea.ai allows you to train the AI on your own images and style, teaching it your specific character, aesthetic or brand look. You upload a set of images and the platform learns from them, then generates new images matching that particular style. It's the kind of customization that could solve the brand-specific imagery problem I was facing.

Beyond the training capabilities, Krea.ai positions itself as a comprehensive visual creation tool. It offers real-time generation, video creation, image enhancement, and access to various diffusion models including FLUX, Stable Diffusion, and many more, including their own proprietary model.

The first time I opened Krea.ai, it took some time to figure out how to access and use the training feature, but once I found it, the process was straightforward. Actually getting comfortable with the platform took maybe five minutes—it's intuitive once you know where everything is.

Pros:

• Real-time generation that eliminates waiting between iterations

• Comprehensive toolkit beyond just image generation

• Interface designed for creative workflow, not just prompting

• Perfect for exploring wild ideas without commitment: you can test concepts that would never make it past a traditional creative brief

• Excellent for client presentations where you need live adjustments

• Community-driven styles and Krea styles are high quality and give you more control

• Standard image and video file formats with multiple resolution options

• Upscaling and image enhancement capabilities

Cons:

• Technical limitations in advanced features

• Resolution options feel limiting, though this is common across all these tools

What impressed me most was how this real-time approach changed my creative process. Instead of the typical prompt-wait-evaluate-restart cycle, I could make adjustments and see immediate results. For a designer, this feels more like actual designing than prompting.

For design work, Krea.ai excels when you need to explore concepts rapidly or when working with clients who want to see live adjustments during presentations. It's particularly valuable in the early conceptual phase when you're not yet committed to a specific visual direction.

Midjourney

While Krea.ai impressed me with its flexibility, Midjourney presented an entirely different challenge.

Midjourney's biggest issue, in my experience, is that you can spot its output from a mile away. The platform produces high-quality, technically impressive images, but they all have that unmistakable AI-generated look. When I'm trying to create imagery that feels natural and authentic, that's exactly what I'm trying to avoid.

Recently, Midjourney added video generation capabilities, allowing you to animate existing images into 5-second video sequences. While limited, this opens interesting possibilities for bringing static designs to life.

Midjourney's community aspect means you can see everyone else's prompts and results, which is educational but also means your work is public unless you pay for a higher tier.

Pros:

• Strong community learning, see what others are creating

• I guess version 7 personalization learns your preferences after rating ~200 images. I haven’t done that.

• New video generation turns static images into 5-second sequences

Cons:

• Everything has that recognizable Midjourney aesthetic that screams "AI-generated"

• Limited control over precise brand-specific aesthetics, although you can create moodboards to control style.

• Potential legal implications due to training data concerns

Visual Electric: Built Different

Visual Electric was created specifically with designers in mind, and this focus shows throughout the platform. Rather than treating image generation as a standalone activity, it integrates into existing design workflows. The most significant advantage is its integration with other design tools.

Pros:

• Preset styles organized with design terminology that makes sense

• Generative canvas approach feels like designing, not just generating

• Real-time collaboration for teams working on same canvas

• "Art Director" feature refines prompts in design language

Cons:

• I ran across more bugs than the other two tools. There were times when I could not generate anything even though I had tons of “volts” and had to wait until the next day.

The platform offers preset styles, but more importantly, these styles are organized and named in ways that make sense to designers. Instead of abstract model names, you get categories like "Editorial Photography," "Product Mockups," and "Brand Identity" that map to actual design needs.

What sets Visual Electric apart is the generative canvas approach. Instead of generating isolated images, you work on an infinite canvas where you can layer, combine, and iterate on generated elements. This feels more like designing than generating.

The collaboration features allow team members to work together in real-time on the same canvas, addressing a real workflow challenge when multiple people need input on visual direction.

I hit the Visual Electric free tier limit within my first week of testing, which made it clear the free tier has constraints for intensive use.

In my design practice, Visual Electric works best when you're working within established design tools and need AI generation that integrates into your workflow.

What I Actually Use

After three months of testing, here's how these tools have fit into my design practice and creative workflow.

For presentations, fun creative endeavors, and new assets, and rapid ideation, I find myself reaching for Krea.ai. The real-time feedback makes it excellent for exploring concepts when I'm not sure what direction to take, and the training capabilities help me get closer to what I want faster.

When I need to edit images dramatically or for production design work that needs to integrate with existing projects, Visual Electric has become indispensable. There is as lot to be said about its interface and how approachable it is to those with design tool experience.

From a designer's perspective, no single tool handles every use case perfectly. But these two combined, they've fundamentally changed how I approach visual content creation, both professionally and personally.

Wrapping Up

These three months of testing have shown me something important: AI image generation isn't just about replacing stock photos. It's about expanding what's possible when you have an idea and want to see it visualized.

But what's become equally clear is that these tools come with their own creative constraints. Midjourney locks you into that distinctive aesthetic—even when you're trying to create something subtle for a conservative client. Krea.ai's training capabilities are powerful, but only if you already have imagery that represents your desired direction. Visual Electric's style categories, while organized well, are few.

We've traded the old constraints; budget, availability, technical skill, for new ones rooted in algorithmic biases and platform limitations. The question isn't whether these constraints are better or worse, but whether we're conscious of them. The best creative work has emerged from understanding and working within constraints. The difference now is we're creating within constraints we didn't choose and might not recognize.

We need to be aware of these new constraints. That awareness changes how I approach these tools. Instead of expecting them to solve all my visual problems, I work with their specific strengths and limitations, just like I would with any other creative medium.

If you're considering trying these tools, here's how to decide where to start:

Try Krea.ai if: You want to experiment with training custom styles, need real-time generation, want access to many many AI image models, or want a comprehensive toolkit in one platform. It's especially good if you have existing brand imagery to train from or work with clients who want to see live iterations.

Try Midjourney if: You're okay with a distinctive AI aesthetic, want to learn from a strong community, or need high-quality imagery where the "AI look" isn't a concern.

Try Visual Electric if: You work primarily in Figma or other design tools, need preset styles that match design terminology, or want clean integration with your workflow. Ideal if you're already comfortable with canvas-based design tools and want AI generation that fits into existing processes.

Summary: Moving from static screens to interactive experiences revealed the true power (and limitations) of AI-assisted development. While Claude Code excelled at implementing animations, state, and basic interaction and functionality, it also made assumptions about user behavior that required a human in the loop. This is where the designer's role shifts from pixel-pusher to experience architect, guiding AI through the nuanced decisions that make apps feel alive.

So, remember how I ended the last post saying I was going to tackle interactions and functionality? Yeah, well, that turned into an adventure.

I thought I knew what I was getting into. Static screens? Claude Code and Figma MCP pretty much handled those. But making things actually work and feel good? That's where things got really interesting. And by interesting, I mean both amazing and occasionally head-scratching.

This is part 3 of my series documenting how I'm building a wellness app using AI-assisted development. If you missed the earlier chaos, check out part 1 and part 2.

When Things Got a Little Too Smart

Okay, so I started simple. Or what I thought was simple. I asked Claude Code via Figma MCP to "make the breathing guide svg animate with a 4-second inhale, 4-second hold, 4-second exhale pattern."

What I expected: an svg that scales up and down with some basic timing.

What I got: a full breathing guidance system with smooth scaling animations, ease in and out applied, text instructions, and haptic feedback.

I literally sat there staring at my screen like... I didn't ask for half of this stuff.

But it all worked. Beautifully. On the first try. Although I would eventually dump some of these items and keep others.

This was my "oh shit" moment. Claude Code wasn't just following my instructions. It was making assumptions about what a breathing app should do based on... I don't know, every app it had ever seen?

Suddenly I realized I wasn't just directing code implementation. I was in a conversation with something that had opinions about user experience.

The Stuff AI is Weirdly Good At

After I got over the whole 'wait, the AI has UX opinions', I started noticing what it was actually good at. The technical implementation stuff? Claude Code crushed it. Way faster than I could have done it, and probably cleaner too.

Animations? The breathing circle wasn't just functional, it was smooth. Proper easing, handled interruptions gracefully, no weird jank.

Cross-platform stuff? When I mentioned wanting this on both iOS and Android, it just... handled the differences. Platform-specific things I wouldn't have even thought about. I am guessing because it knows I am using Flutter it could handle that.

But it got weird: Claude Code was constantly making these tiny UX decisions. What happens if someone taps the screen mid-breath? What if they navigate away and come back? Should the haptic feedback be subtle or more pronounced?

These aren't coding questions. These are experience design questions. And the AI was answering them based on... its training? Its best guess? I honestly don't know.

Learning to Talk to AI About Feelings

I quickly figured out that asking AI to build interactions is completely different from asking it to match a Figma design. You can't just say "make this work." You have to describe what it should do and how it should feel.

Instead of "add navigation between screens," I learned to say something like "create gentle slide transitions that keep the calm, meditative vibe. Users should never feel rushed or jarred."

Instead of "make the timer work," it was more like "build a timer that shows progress without creating anxiety. Make it feel supportive, not stressful."

The more I described the emotional experience I wanted, the better Claude Code got at building it. It was like directing a really talented developer who could build literally anything, but needed you to explain the why behind every decision.

All this said, I still needed to go in and direct it even more. Specifying animation speed, duration, etc.

AI Getting it Wrong is Useful

Not everything Claude Code assumed matched my vision. That breathing screen I mentioned? It added a bunch of stuff I never asked for:

• A "cycle count" (not terrible, but not what I wanted)

• A social sharing thing after each session (completely wrong for my minimal approach)

This is where I realized the designer's job isn't going away, it's just changing. AI can build any experience you can describe and technology can support, but it can't read your mind about which experiences fit your design philosophy.

I found myself constantly course-correcting:

"Remove the skip button – I want people to commit to the full cycle."

"Kill the audio cues, just do subtle haptic feedback."

"No social features. This should feel personal and private."

Each time I corrected something, I got better at understanding both what the AI could do and what I actually wanted.

No “One Shots”

After a few rounds of this "add features I didn't want" dance, I figured out something important, don't try to build everything in one go.

I was making the mistake of asking Claude Code to "create the complete breathing exercise screen with timer, animations, and user controls." And every time, it would interpret that as license to add whatever it thought a breathing exercise screen should have.

So I started breaking things down:

First: "Create just the breathing svg animation with the 4-second cycles."

Then: "Add a simple timer display that shows session progress."

Then: "Add start/stop controls, but keep them minimal."

Each smaller ask let me guide the experience more precisely. When Claude Code only had one thing to focus on, it did exactly what I asked for instead of trying to anticipate what else I might want.

This approach felt slower at first, but it actually saved time. No more removing unwanted features or explaining why the AI's suggestions didn't match my vision. Just clean, focused implementation of exactly what I designed.

The Debugging Reality

Of course, not everything worked perfectly. But Claude Code is really good at debugging its own work if you describe the problem clearly.

"The breathing animation gets choppy when someone returns to this screen" became a starting point for it to fix animation stuff.

"The breath count is not in sync with the animation" led to it completely refactoring the timing logic.

What's weird is how it approaches debugging. It doesn't just patch problems, it often finds root causes and makes the whole thing better. Sometimes the fixes improved stuff I didn't even know needed improving.

What I'm Doing Now

Three weeks into this experiment, my job has completely changed. I'm not pushing pixels anymore. Instead I'm:

• Describing how things should feel, not just how they should look.

• Learning to communicate design intent in ways AI can understand and run with.

• Constantly evaluating whether AI-generated experiences match what users actually need.

• Testing ideas in working code instead of static mockups.

This feels like what design was always supposed to be, focusing on the human experience and letting tools handle the technical implementation.

The Good, the Bad, and the Unexpected

What's working really well:

• Complex animations that would have taken me forever

• Cross-platform compatibility without me thinking too much about it

• Testing interaction ideas super quickly

What's still tricky:

• AI making assumptions about user behavior that don't match my vision

• Figuring out when to trust AI suggestions vs. when to override them

• Keeping the code organized as I add more features

• Balancing AI's "helpfulness" with my actual design goals

Where This Is All Heading

Building this app is making something pretty clear: we're not heading toward AI replacing designers. We're heading toward designers becoming experience orchestrators, working with AI to bring ideas to life way faster and more completely than before.

The technical barriers between design and implementation are basically dissolving. The question isn't whether AI can code your designs (it can), but whether you can articulate the experiences you want to create clearly enough for AI to build them well.

Up Next: When Things Get Messy

Next post, I'm diving into the less glamorous side of this experiment. What happens when you need to refactor AI-generated code? How do you handle edge cases the AI completely missed? And what happens when you try to add features that don't fit neatly into the AI's idea of what a "wellness app" should be?

What questions do you have about working with AI on interactions? Drop them in the comments. I'm documenting all of this and happy to dig into specific challenges in future posts.

This is part 2 of my series documenting how I'm building a wellness app using AI-assisted development. If you missed the backstory about why I'm doing this, check out part 1.

Thoughts in Design

Building a Wellness App with AI: Part 1

Summary: I was fed up paying $12+ monthly for wellness app features I never used. Building my own seemed overwhelming until I discovered Figma MCP and Claude Code. Despite my skepticism that AI could handle the load, my first test was mind-blowing: the AI implemented my interface design with ~95% accuracy. This is part 1 of a multi-part series documenti…

Read more

10 months ago · 1 like · Fred McHale

Okay, so after that first test where Claude Code somehow turned my Figma design into working code with really good accuracy, I was obviously super intrigued. But you know how it is with shiny new tools, there's always that moment where you have to figure out if it was just beginner's luck or if this thing actually works consistently.

Spoiler alert: it works, but there are definitely some things I wish I'd known before diving in headfirst.

The Setup

Getting this whole thing running is way simpler than I expected. The tricky part is learning how to design in a way that doesn't confuse the AI.

*If you aren’t comfortable with the terminal, I don’t recommend using my setup as a guide. Instead consider using something like Cursor or VS Code with Copilot. Figma’s instructions for setting up MCP with those can be found here. I decided to use Claude Code with the Claude Code Plugin for VS Code (that is a lot of Codes…) but Figma MCP also works with Cursor, VS Code/Github Copilot, and Windsurf.

Setting Up Claude Code

First things first, you need to have node.js and npm installed. Then you can install Claude Code following the instructions from Anthropic. It's pretty standard command-line stuff, nothing too scary.

From there create a folder where your project will live. In the terminal you will need to cd to the project folder, start claude with the command

cd project_folder
claude

and then tell Claude Code to initialize the project with the init command.

Once you are past this point it’s time to setup Figma and tell Claude Code to use it.

In Figma, go to your design file and in the Figma Menu ➡️ Preferences look for Enable Dev Mode MCP Server. When you check this it will start the MCP server.

Finally go back to Claude Code and add the MCP server with

claude mcp add --transport sse figma-dev-mode-mcp-server http://127.0.0.1:3845/sse

and that is it.

Well almost, For some reason I needed to go back into Figma and restart the MCP server.

From here I asked Claude Code to create a basic Hello World Flutter App. So I had something to work with.

How Figma MCP Actually Works

Here's something I didn't realize at first: Figma's MCP server doesn't just screenshot your designs and hope for the best. It actually reads the structure, understands relationships between elements, and picks up on some of your design decisions. Pretty cool.

But… it reads your Figma files like a developer would, not like a designer. And that changes everything about how you need to organize your work.

Designing Files That AI Can Actually Use

Remember how I mentioned my auto-layout wasn't quite right in that first test? That wasn't just a minor detail, it's actually crucial to how well the AI interprets your designs.

Frame Structure Matters

I discovered that Claude Code works best (at least in my situation) when my Figma files follow a clear hierarchy:

Pages in Figma should represent different sections or flows of your app. Frames should be actual screens or major components, EVERYTHING needs descriptive names (more on this below).

For my wellness app, I structured it like this:

• Design System page (colors, typography, components)

• User Flow page (main app screens)

Naming Is Everything

Here's something that took me a few failures to learn: generic names like "Frame 18555675" or "Rectangle 124567" are useless to the AI. But descriptive names like "breathing-exercise-card" or "navigation-tab-active" give Claude Code the context it needs to generate accurate code.

I started going through my designs and renaming everything with intention:

• primary-button instead of Button

• meditation-timer-display instead of Group 47

• breathing-guide-circle instead of Ellipse 3

The difference in AI interpretation was dramatic.

Auto-Layout: Your New Best Friend

If you've been avoiding Figma's auto-layout feature, now's the time to embrace it. Claude Code understands auto-layout constraints and translates them into mostly proper layout.

I spent a bit of time converting all my manually-positioned elements to auto-layout, and the payoff was immediate. The AI went from generating code that kind of worked to code that actually handled different screen sizes properly.

My First Real Test: The Breathing Exercise Screen

With my setup dialed in, I decided to build the core interface of my app: a guided breathing exercise screen.

I very quickly designed the screen in Figma with proper naming and auto-layout. When the design was complete, I made sure it was selected and returned to Claude Code. Then fed it to Claude Code with this prompt:

"Create a breathing exercise screen based on the design selected in Figma. Be exact."

The Results

The good news: Claude Code nailed the layout and styling. The visual design was nearly pixel-perfect for a simple screen.

The not-so-good news: Claude Code had decided to recreate an SVG I had used in the design file. It actually nailed it but I wanted it to use my SVG. Also, it started to implement some of the interaction and functionality. Something I didn’t want it to do just yet.

This taught me something important: AI is incredible at implementation, but it needs human insight for code organization (and experience design but more on that in Part 3). The code worked perfectly, although disorganized and could use A LOT of refactoring.

Learning to Guide, Not Just Generate

From here I added the SVG to the correct folder in my project and prompted Claude to use it instead of the SVG it had created. I also asked it to create an app theme because it hardcoded various design choices, like color and typography into the code. I didn’t want to deal with that mess later on.

It did all of these things without a hiccup.

What I'm Learning About This Workflow

A few days into this experiment, here's what's becoming clear:

Design skills matter more, not less. The AI can implement anything you can design well, which means the quality of your thinking becomes the bottleneck.

System thinking pays off. Building a proper design system in Figma translates to better, more consistent code output.

Iteration is faster than ever. Instead of waiting days for developer feedback, I can test design changes in minutes.

Although it can create working code, it may not be perfect code. I think you need to have some level of development knowledge to understand where it goes wrong or how to prompt it to do better.

Up Next: Addinging Interaction and Functionality

In the next post, I’ll dive into my experiences with implementing the rest of the screens, animations, and other functionality.

What questions do you have about AI-assisted development? Drop them in the comments. I'm documenting everything and happy to explore specific challenges in future posts.

Summary: I was fed up paying $12+ monthly for wellness app features I never used. Building my own seemed overwhelming until I discovered Figma MCP and Claude Code. Despite my skepticism that AI could handle the load, my first test was mind-blowing: the AI implemented my interface design with ~95% accuracy. This is part 1 of a multi-part series documenting how I'm building a wellness app using AI-assisted development.

After 20 years of designing product experiences, I thought I'd seen every workflow imaginable. Traditional design-to-development handoffs, endless redlines, the familiar dance of "that's not quite what I meant" between designers and developers. As someone who's spent nearly two decades on the design side with some development chops, I've always felt caught between two worlds, strong enough in code to know what's possible, but passionate enough about design to want to stay in my creative zone.

The $12/Month Frustration

Like many people, I'd been paying for various wellness apps, Headspace, Calm, you know the usual suspects. But I was paying $12+ monthly for meditations I never listened to, content I never read, and features I never touched. All I really wanted was good box breathing exercises and maybe a few other simple techniques.

Worse yet, as a designer, some of the alternatives to the big player apps drove me crazy. Poor visual hierarchy, confusing user flows, interfaces that felt more like afterthoughts than intentional experiences. I kept thinking, "I could design something better than this," but the prospect of building it myself felt overwhelming. Design I could handle, but development? That meant weeks away from what I actually love doing.

Figma MCP and Claude Code - Uh What

A few weeks ago, I stumbled across Figma's blog post about their new MCP (Model Context Protocol) Server and its integration with Claude Code. The concept was intriguing: design in Figma, then have Claude Code actually implement your interfaces with AI assistance. As someone who's always been fascinated by the intersection of design and development, I had to try it.

But I was skeptical. Like, really skeptical.

After months of seeing AI tools that promise the moon and deliver something that barely resembles what you asked for, I didn't expect much. Could an AI really look at my Figma designs and create accurate, functional mobile interfaces? It seemed too good to be true.

The Moment Everything Changed

I decided to start simple, a screen with animated navigation and SVG background for my wellness app concept. Nothing too complex, but enough visual elements to test whether this AI-assisted approach could actually work.

I set up quick and dirty Figma design file, made sure my auto-layout was properly configured (learned that lesson quickly), variables were set, components built out, and connected it to Claude Code. Then I held my breath and hit enter.

What happened next gave me the biggest smile I've had in sitting in front of a screen in awhile.

The AI didn't just understand my design, it implemented it with about ~95% accuracy. When I fired up the iOS simulator, there was my interface looking extremely close to the Figma file. The 5% that needed tweaking? Minor layout issues that were honestly my fault for not being more careful with auto-layout in a couple of frames.

Why This Changes Things

For the first time in my career, I felt like I could focus entirely on what I do best, designing user experiences, while still being able to build the actual product. The AI wasn't replacing my development knowledge; it was amplifying it. I could guide the process with my understanding of how apps work, but I didn't have to spend weeks writing code that pulled me away from design.

I feel like I can build anything.

What's Coming Next

Over the next few posts, I'm going to document this entire journey, from initial setup struggles to workflow discoveries to the inevitable moments where things don't go as planned. I'll show you exactly how I'm building this breathing app, what works, what doesn't, and how this AI-assisted design-to-development process is evolving.

Next up: Getting Figma MCP and Claude Code talking to each other (spoiler: it's easier than you think) and setting up Figma Design files.

Summary: A single idea from a talk at SF Design Week sparked this article: In the age of AI, what if trust isn't a bonus, but the most essential feature we can build? This post dives into why users are naturally wary of AI's "black box" nature and provides a clear guide for designing trustworthy systems. Forget just hoping for user confidence let's build it on purpose through transparency, practical examples, and putting people back in control.

I’ve just walked out of the session “When UX Meets ML/AI: Human-Centered Design in an Algorithmic World” at SF Design Week 2025. The speaker, Abdalla Emam, had been talking about the melding of UX and AI, one line he dropped felt less like an industry observation and more like a universal truth that had been hiding in plain sight.

Simple. but it’s been rattling around in my head ever since. We, the builders, the makers, the designers, have often treated trust as an afterthought or at best a happy accident. We build a functional product, ship it, and just hope our users will come to trust it over time.

But in the world of AI, hope isn't a strategy. In this new landscape, where algorithms can write poetry, diagnose illnesses, and hold conversations, designing for trust isn't just a good idea. It’s the only way forward.

The Ghost in the Machine

Think about the last time a piece of technology baffled you. Maybe it was your smart speaker suddenly playing a song you've never heard, or your Instagram feed serving you an ad for something you only thought about. It’s an unsettling feeling, isn't it? A little flicker of mistrust. You feel a loss of control, like you're dealing with a ghost in the machine.

That feeling is the default state for many people when they interact with AI.

Traditional software was a deal we understood. You press a button, a predictable thing happens. An "if this, then that" world. It was a clear contract. AI tore up that contract. It operates in shades of gray, on probabilities and inferences. Its inner workings are often a complete mystery, a "black box" that even its creators can't fully explain.

This is where the trouble starts. When an AI gets something wrong, when it confidently hallucinates a legal case, as one chatbot famously did, or when a hiring algorithm quietly develops a bias against a certain group of people, it’s not just a bug. It's a betrayal. It confirms our deepest fears about an unfamiliar intelligence making decisions that affect our lives. It’s no wonder IBM found that 82% of people believe AI needs a human in the loop to be trustworthy. We want to know someone is watching the ghost.

Designing the Handshake

So, if we can't just hope for trust, how do we build it? We have to design it into the very first pixel, the first line of code, the first everything we do. We have to design the handshake between the human and the AI.

The National Institute of Standards and Technology (NIST) has a great blueprint for this. You can think of its characteristics for trustworthy AI not as a technical checklist, but as the ingredients for a healthy relationship.

It starts with Reliability. The AI has to show up and do its job, consistently. No one trusts a flaky friend, and no one will trust a flaky algorithm.

Then there's Safety. This is non-negotiable. The system must be designed from the ground up to “Do no harm”, anticipating the wild ways users might interact with it.

It needs to be Secure, tough enough to fend off bad actors, and Resilient, able to fail gracefully instead of shattering at the first sign of trouble.

We need Transparency. Users should know when they are talking to an AI. They should have a basic map of how it works. This isn't about showing them the raw code; it's about being honest about the system's capabilities and its limitations.

And even deeper, we need Explainability. Imagine an AI that helps doctors spot tumors. It’s not enough for it to just point to a spot and say "we there’s your problem" A trustworthy AI would say, "I've identified a potential issue in this area, and here's why: I'm seeing these specific patterns that are 92% consistent with early-stage malignancies I've learned from my data set." That's the difference between a mysterious black box and a trusted co-pilot.

And Fairness. AI models learn from the world we've created, and that world is full of bias. A trustworthy system is one where immense effort has been made to find, flag, and fight that bias at every turn.

From Blueprint to Reality

This all sounds great in theory, but what does it look like on a screen?

It looks like showing your work. When a music app recommends a new artist, it shouldn't feel like a random guess. It should say, "Because you love the driving bass lines in this band, you might like this one." Suddenly, the ghost in the machine has a personality. It was paying attention.

It looks like giving up power. The user needs the steering wheel. An "undo" button, clear privacy controls, the ability to override a suggestion. These aren't just features, they are gestures of respect. They say to the user, "You are in charge."

It looks like a conversation. A simple "Was this helpful?" or a thumbs-up/thumbs-down on a generated image creates a feedback loop. It turns a monologue into a dialogue. It tells the user their opinion matters and helps the AI get better in the process.

The alternative is a future we've all seen in movies, and it isn't pretty. A world of glitches, misunderstood commands, and biased decisions that feel like a technological dystopia. We've already had glimpses of it. The cost of neglecting trust isn't just a lower engagement metric; it's the erosion of confidence in technology itself.

Walking through SOMA after that talk, I kept thinking about the handshake. That simple, ancient gesture of trust. It’s an agreement, a sign of mutual respect and good intentions. That’s what we need to build. We are designing that digital handshake between humanity and the most powerful tool we've ever created.

So, as you work on your next project, don't just ask if it's functional or beautiful. Ask if it's trustworthy. Are you building a black box, or are you designing the handshake? Because trust isn’t a bonus feature you unlock in level two. It’s the entire game.

Summary: This article is for design leaders (new and seasoned) and senior designers who aspire to build, nurture, and elevate their teams. We'll explore strategies to move beyond a collection of individual talents and cultivate a high-impact design team. Forget the idea of the lone genius; real impact in design is a team sport, where everyone's got each other's backs and pushes towards the same goal.

The Symphony of Skills

I'll never forget my first design leadership role. I was convinced that the key to success was assembling a team of rockstar designers, you know, the kind who are basically fire hoses of innovative ideas and possess jaw-dropping visual design skills. I spent months recruiting top talent, and I was ecstatic when I finally had a team full of them.

But then reality set in. Instead of a beautiful symphony, I found myself leading a group of brilliant soloists, each playing their own music, often clashing with one another. It was a frustrating and an extremely humbling experience. I learned the hard way that building a high-performing product design team is about so much more than getting the "best" of the "best" on the team. Turns out, "best" is subjective, and sometimes, "best" designers are the ones who play well with others. Who knew?

Building a high-performing product design team is about creating collaboration, and it goes beyond just assembling talent (although that is a big factor). It involves strategic leadership, a strong foundation of trust and clear purpose, a commitment to continuous growth, and the ability to effectively measure and communicate the team's impact. It's similar to conducting an orchestra where everyone's in sync and playing their heart out for the same song. The design leader in this scenario? They're the conductor, ensuring all that individual brilliance comes together to create powerful design. Or, more accurately, they're trying to prevent the brass section from starting a turf war with the percussionists.

A Foundation of Clarity, Confidence, and Minimal Confusion

Have you ever tried to get a group of friends to decide on a dinner spot? If everyone's throwing out random ideas and there's no clear direction, you usually end up with a lot of frustration and empty stomachs. It gets a lot easier if you all have a similar genre of food in mind. The same kind of goes for a product design team. You absolutely need a clear vision and purpose,that agreed-upon genre of food, so everyone understands what the goal is and why their work actually matters. The leader needs to be the one clearly saying, "Alright team, this is our destination, and here's why it's going to be great when we get there." (And maybe offering to buy the first round of drinks).

A clear vision and purpose provide the essential "why" behind the work. It's the North Star that guides the team's efforts and aligns individual contributions with overarching goals. For design leaders, this means:

• Connect to the "Why": Don't just state what the team does; articulate why it matters. How does the team's work impact users? How does it impact the business? What problem are they solving? Connect the daily tasks to a larger, inspiring mission. (Even if that mission is "to make this app slightly less annoying to use.") To make this super clear, try framing it like this: "Our work directly impacts X metric, which leads to Y business outcome. That's why your contribution is so valuable."

• Involve the Team: Make the vision and purpose a collaborative effort. Solicit input from team members to create a sense of ownership, accountability, and shared understanding. When people feel heard, they're more invested. (And less likely to passive-aggressively change the font size on everything.) A great way to do this is by holding a team workshop where you brainstorm the vision together.

• Communicate Consistently: Regularly reiterate the vision and purpose in team meetings, project kick-offs, and even informal conversations. Keep it top-of-mind. I graffitied our vision and purpose on an office wall at a prior workplace. I don't recommend this, the building operations people hated me.

• Make it Tangible: Translate the abstract vision into concrete goals and objectives that the team can work towards. Show how their individual contributions directly feed into the larger purpose. A helpful technique here is to use the OKR (Objectives and Key Results) framework, which can provide a clear roadmap for everyone.

Now, imagine that dinner again. If you suggest a place and everyone just shoots it down immediately, or if you spill your drink and everyone just stares at you, you're probably not going to feel very comfortable sharing ideas or taking risks in the future. That's why psychological safety is HUGE. It's creating a space where everyone feels like they can throw out ideas (even the crazy ones!), ask "dumb" questions (there are no dumb questions, just varying levels of knowledge!), and even mess up a little without feeling like they're gonna get roasted. When people feel safe, that's when real creativity happens.

For design leaders, creating psychological safety involves:

• Lead by Example: Be open about your own mistakes and learning experiences. Show vulnerability to encourage others to do the same. It's saying, "Hey, I messed up on this, and here's what I learned," which makes it okay for others to do the same.

• Actively Listen and Validate: When team members share ideas or concerns, listen attentively and acknowledge their perspective, even if you don't agree. (Nodding and saying "Interesting..." is a good start, even if you're thinking, "Are you serious?") Try using phrases like, "I hear what you're saying, and that's a valid point," to show you're listening.

• Normalize Failure as Learning: Frame mistakes as opportunities for growth, not as reasons for blame. Focus on what can be learned and how to improve. (Think “retrospective" instead of "public shaming.") A key mindset shift is to move from "Who's to blame?" to "What can we learn for next time?"

• Establish Clear Norms: Create team agreements about respectful communication, constructive feedback, and how disagreements will be handled. (Like, "No interrupting, unless someone is about to suggest using Clippy.") These norms could include things like, "Assume positive intent" and "Critique the design, not the designer."

• Celebrate Risk-Taking (Even if it Doesn't Work Out): Acknowledge and appreciate when team members step outside their comfort zones and try new things, regardless of the outcome. (Bonus points if the "failure" is spectacularly funny.) This could involve a team shout-out or even a small reward for "most daring idea."

And finally, back at dinner again, think about ordering. If your waiter takes your order and you don't hear anything until the food magically appears (or doesn't!), you're going to be pretty in the dark. Effective feedback loops are like those check-ins with your waiter , "Hey, just wanted to let you know the kitchen's working on your burger!" Regular feedback, both giving and getting, keeps everyone on the same page, helps catch issues early, and makes the final product way better. (And prevents designers from spending weeks on a feature that gets scrapped.)

Design leaders can establish effective feedback loops by:

• Implement Regular Cadences: Schedule recurring feedback sessions at different levels (individual, project, team). This could be weekly check-ins, mid-project reviews, or post-project retrospectives. Of course, let your designers actually design at some point. A good rule of thumb is to have at least one formal feedback session per project milestone, in addition to regular informal check-ins.

• Encourage Both Giving and Receiving: Create a culture where everyone feels comfortable giving and receiving feedback. Provide training on how to deliver constructive feedback effectively. (Tip: Start with something positive, even if it's just, "I like the shape of that...")

• Make it Specific and Actionable: Feedback should be focused on behaviors and outcomes, and it should provide clear steps for improvement. Avoid vague or personal criticisms. ("This design is bad" is less helpful than "I'm not sure the color contrast meets accessibility standards.") Instead of saying "I don't like it," try saying "I'm having trouble understanding X. Could we explore Y?"

• Create Multiple Channels: Offer various ways to give feedback, both formal and informal, written and verbal. This can include one-on-one meetings, team critiques, and anonymous surveys. Think about using a tool like Loom for asynchronous video feedback, which can be really helpful for visual design.

• Close the Loop: Feedback should be actionable. So make sure that feedback is actually acted upon and that team members see the impact of their input. This shows that their feedback is valued. (And that they're not just shouting into the void.) This means following up and saying, "Based on your feedback, we changed X, and here's the result."

Investing in Talent and Teamwork

Okay, so you've got a team with a clear direction and a safe creative space. What's next? Making sure everyone keeps getting better! The key here is intentional skill development. It's the design leader's responsibility to actively support the growth of team members. This could be anything from pairing up a junior designer with a senior, sending teams to workshops that'll blow their minds, or just carving out time for the team to share what they're learning. When people are constantly learning and growing, the whole team gets stronger. (And less likely to leave for a company that offers free learning and development opportunities.)

Design leaders should invest in the growth of their team members by:

• Identify Skill Gaps: Regularly assess the team's current skills and future needs. What new technologies or methodologies are becoming important? Where are there opportunities for growth? (Besides "patience" for dealing with stakeholders?) A skills matrix can be a useful tool, helping you visualize where everyone stands and where the gaps are.

• Create Learning Pathways: Develop structured plans for skill development, which might include mentorship, online courses, internal workshops, or conference attendance. Try creating a "learning budget" for each team member and encouraging them to use it for their professional development.

• Establish a Culture of Sharing: Encourage team members to share their knowledge and expertise through presentations, informal discussions, or internal documentation. Consider setting up a regular "Design Share" session where team members can present their work and learnings to each other.

• Provide Opportunities for Experimentation: Create a space for designers to try new techniques and tools, even if the outcome isn't always perfect. Learning often happens through doing. (And sometimes, spectacular failures lead to unexpected breakthroughs.) This could involve dedicated "innovation sprints" or "hackathons" where designers can explore new ideas.

• Recognize and Reward Growth: Acknowledge and celebrate when team members develop new skills or take on new challenges.

But just like in nature, nothing grows and thrives in total isolation. When designers are actually working with product managers, engineers, and others from the get-go, instead of just tossing designs over the wall, the end result is always more achievable and cohesive. (And there are fewer awkward "Why did you design it that way?" conversations later.)

Consider:

• Establishing Shared Goals: Make sure that design, product, and engineering teams are aligned on common objectives and understand how each team contributes to the overall product success.

• Create Integrated Teams: Where possible, get designers closer to engineering teams to create closer working relationships and better communication. (Think of it as design and engineering going steady.) This could involve embedding designers within cross-functional product teams.

• Implement Regular Joint Meetings: Schedule regular meetings where all disciplines can discuss progress, challenges, and upcoming work together. Regular stand-ups, sprint reviews, and planning sessions are important.

• Promote Empathy and Understanding: Encourage team members to learn about the processes and constraints of other disciplines. This can lead to more informed design decisions and smoother workflows. Possibly implement cross-functional shadowing, where designers spend time with engineers, and vice-versa.

• Use Collaborative Tools: Leverage shared platforms and tools that allow for seamless communication and feedback across teams. Tools like Figma, Jira, and Slack are essential for smooth collaboration.

And speaking of nature, it's full of diverse life. We should want the same for our teams. That's where embracing diverse backgrounds and viewpoints comes in. When you have people with all sorts of different experiences, skill sets, and backgrounds on your team, you get more creative ideas and you're more likely to build products that actually work for a diverse group of users. Leaders must actively build this kind of team and make sure everyone's voice is not just heard, but actually valued. (Unless that voice is constantly suggesting Papyrus. Then, maybe less valuing.)

Tips for Embracing and Hiring Diverse Backgrounds, Skill Sets, and Experiences:

• Broaden Your Search: Look beyond traditional design hubs and consider candidates from different geographic locations, educational backgrounds, and career paths.

• Re-evaluate Hiring Criteria: Focus on core skills and potential rather than solely relying on specific degrees or years of experience.

• Implement Inclusive Interview Processes: Ensure your interview panel is diverse and that your questions are designed to uncover a range of perspectives and experiences.

• Actively Seek Out Underrepresented Groups: Make a conscious effort to reach out to and recruit individuals from underrepresented backgrounds in tech and design. It’s more than just posting it in your LinkedIn job description…

• Promote an Inclusive Culture: Once you have a diverse team, make sure that the environment is welcoming, respectful, and provides equal opportunities for everyone to thrive and contribute their unique perspectives.

• Evaluate Team Needs and Fill Skill Gaps: Regularly assess the existing skills within your team and identify any critical gaps. Strategically hire individuals whose expertise complements the current team's strengths, creating a more well-rounded and capable unit.

Showing Design's Worth

Alright, so you've got this awesome team humming along. How do you know if they're making a difference? You have to figure out how to define meaningful metrics. Move beyond just "pretty designs" and start looking at stuff like "did user engagement go up after that redesign?" or "are more people actually clicking that button now?" Leaders need to work across functions to figure out what actually shows the impact of the design team's work. (Besides the number of Post-it notes used.)

Once you're tracking the right stuff, you should communicate design value effectively. Don't just show off the before and after of a UI. Tell the story of why you made those changes and, most importantly, show the results. "Hey, remember when users were dropping off at this point? After our redesign, we saw a 20% increase in completion!" That's how you get people to really understand the excellence of your design team. Focus on outcomes not output. (Unless your output is exceptionally beautiful, in which case, show that off too.) A powerful way to frame this is by using the "problem-solution-result" framework: "We identified this problem, we designed this solution, and here's the positive result we achieved."

Coach, Champion, Facilitator, and Occasional Therapist

Who is guiding this crew? You, the design leader! And the best ones lead with empathy and clarity. It is like being a really good coach. You should understand what makes each player tick, what their strengths are, and what they need to grow. But you also should have a clear game plan and make sure everyone knows what their role is and what the expectations are. (And showing up to meetings on time is, in fact, expected.)

Good leaders also know that they can't do it all themselves. That's why empowering and delegating is important. It's trusting your team, giving them ownership, and letting them run with things. When people feel trusted and have the space to shine, they usually do. Plus, it frees up the leader to focus on the bigger picture. (Like, figuring out how to get a bigger budget.) A key principle here is to delegate tasks, not responsibilities.

And finally, the best design leaders are total champions for their team and for the value of design within the whole company. Championing design means talking it up, making sure design gets the resources it needs, and helping everyone understand why good design isn't just about making things look pretty, it's making things work better and driving real results. (And that designers are, in fact, real people with feelings and opinions.) This involves proactively communicating design's impact to stakeholders and advocating for a seat at the table.

The Buck Stops With You

Leading a design team isn't just about guiding creative output; it's making a deep sense of ownership and accountability at every level. While we've discussed empowering individual contributors and delegating tasks, there's a crucial element that underpins the success of any high-performing team: the accountability of the design leader.

The conductor doesn't just wave the baton; they are ultimately responsible for the performance of the entire orchestra. Similarly, the design leader sets the tone for accountability within the team. This doesn't mean micromanaging every pixel or breathing down designers' necks. Instead, it's about establishing clear expectations, promoting a culture where taking ownership is the norm, and most importantly, demonstrating that the leader themselves is the ultimate point of responsibility.

This manifests in several key ways:

• Owning the Vision and Strategy: The design leader is accountable for the overall design vision and strategy. This includes ensuring it aligns with the product and business goals, communicating it effectively to the team and stakeholders, and taking responsibility when the strategy needs to adapt. It's about saying, "This is the direction we're heading, and I stand behind it."

• Championing Team Success and Taking Responsibility for Setbacks: When the team succeeds, the leader celebrates their achievements. But equally important is taking responsibility when things don't go as planned. This means acknowledging missteps, analyzing what went wrong, and focusing on solutions rather than blame. It's a "we're all in this together" mentality, where the leader shoulders the ultimate responsibility for the team's collective failures.

• Ensuring Clarity and Removing Obstacles: A significant aspect of design leadership accountability is ensuring the team has the clarity and resources they need to succeed. This involves proactively identifying and removing roadblocks,facilitating clear communication across teams, and advocating for the necessary tools and support. If the team is facing challenges, the leader is accountable for stepping in and helping to find solutions.

• Holding the Team Accountable (with Empathy): While the leader takes ultimate responsibility, they also play a crucial role in creating accountability within the team itself. This involves setting clear expectations for individual contributions, providing regular feedback on performance, and addressing any issues or inconsistencies constructively. It's about creating a culture where everyone understands their responsibilities and is motivated to deliver their best work. We aren’t being disciplinarians; we are guiding and supporting team members to take ownership of their work and its impact.

• Leading by Example: Perhaps the most powerful way a design leader can cultivate a culture of ownership is by demonstrating it themselves. This means being proactive, following through on commitments, and taking responsibility for their own actions and decisions. When the team sees their leader embodying accountability, it sets a strong precedent for everyone else to follow.

By having this deep sense of ownership, the design leader creates a more resilient, high-performing, and ultimately, less chaotic team. It creates a culture where everyone wants to contribute their best, knowing that they are supported and that the leader is ultimately accountable for the team's collective journey and outcomes.

Conclusion

Alright, so building a high-impact product design team isn't flipping a light switch on. It's more like planting a garden and constantly nurturing it. By focusing on more than just individual talent, by setting up solid foundations, by helping everyone grow and collaborate, and by showing the impact of the team's work, you're not just managing a team, you're building something powerful. Lead with empathy, be clear about the vision, and champion the hell out of design. Do that, and you'll be well on your way to creating a group that doesn't just make things look good, but actually changes the game for your company. (And maybe even makes your job a little easier. Maybe.)

Summary: While AI offers powerful tools for design, it lacks the human understanding of visual communication, particularly Gestalt principles, that are fundamental to effective design. Designers remain crucial for their ability to solve problems, empathize with users, and curate AI-generated work. AI can generate, but it cannot design with intent. Therefore, designers must leverage their expertise to guide AI, ensuring outputs are not just visually appealing but also functionally sound and user-centered, emphasizing that design is more than aesthetics, it's understanding and communicating with people.

Yes.

And I want to be clear. This isn't a pro-AI or anti-AI rant. AI is here, it's changing things, and pretending otherwise is just silly.

While generative AI tools are undeniably powerful, even mesmerizing, and getting better week by week, they often lack the fundamental understanding of visual communication that human designers possess. You know, the stuff you might have learned in design school or training? Yeah, those rules. Gestalt principles are key among them. They're the important stuff needed when making interfaces that resonate with people, that guide their eyes, that don't make them want to vomit in disgust. They are also the principles we need to sift through the mountains of AI-generated output to find the actual gems.

I get it though, you are busy and AI is seductive. It can generate a lot of shiny, new things, and it's easy to get swept up in the hype of influencers, marketers, and AI bros. It’s tempting to just let the machine do its thing. But without a solid grasp of Gestalt and other design principles, you're essentially forfeiting your role as a designer. You're not using AI to its fullest potential; you're letting it dictate the visual language, and likely missing out on potentially good design. You're feeding the algorithm and hoping for the best, and likely overwhelmed by the sheer amount of bad or boring designs, and that’s a recipe for frustration. You’ve become lazy. Don’t be lazy, be a designer. Have a discerning eye to pick and manipulate the best of what you instructed it to create.

The Building Blocks of Seeing

Before we can even talk about how to effectively use AI in design, we need to understand what good visual design is.

Enter Gestalt.

These principles, developed by some slightly eccentric German psychologists in the early 20th century, are essentially the foundational rules of how our brains process visual information. When we look at a UI, or any design for that matter, we don’t see a random assortment of visual elements; our brains actively seek to organize them, to create order and meaning out of them. This drive is fundamental to how we perceive everything, from recognizing a familiar face to understanding the layout of a website.

So, what are some of these fundamental rules?

Proximity, similarity, closure, figure-ground, continuity, and Prägnanz.

These aren't just words to impress people (though they might come in handy at your next feedback session). They're the core components of visual perception. They're the tools we use to create hierarchy, establish relationships, and guide the viewer's eye.

Think of proximity: grouping related elements. In UI design, this is HUGE. Think about a navigation bar. If the menu items are spaced out randomly, it becomes almost unusable. Without the concept of proximity users struggle to understand which design elements belong together, what the main sections of the site are, and where to click. Grouping related buttons, form fields, or cards creates a clear visual structure and makes the interface intuitive. Without it, your design becomes a jumbled mess where nothing makes sense. It's like trying to read a book where all the words are randomly scattered across the page.

Similarity is vital for showing what belongs together, for creating visual cues that tell the user "these things are related." Again, crucial in UI. Imagine a list of files. Using the same icon for all PDF files and a different icon for all image files instantly communicates file types. Using the same color for all primary buttons signals their importance. Inconsistent use of similarity leads to confusion and slows down user interaction. Imagine a website where the links are the same color as the regular text. Yikes!

And so on with the other principles. AI can spit out a million variations, maybe some great, maybe some horrible. Ultimately we decide if they make sense, if they follow design principles, if they tell a story, and if they induce migraines.

So, with those visual fundamentals in mind, let's zoom out and talk about what design really is.

Design Is More Than Pretty Pixels

Let's make something clear: Design is not just making things look good. Sure its an important part of it but it’s not just slapping some trendy colors on a page, poster, app, or whatever and calling it a day. That's decoration, not design. Decoration is the icing; design is the cake (and the oven, the recipe, and the whole damn bakery).

Design, at its core, is problem-solving. It's about understanding people's needs, often needs they themselves can't articulate, identifying their pain points, and creating solutions that make their lives easier, more efficient, or more enjoyable. It's figuring out how to get someone from point A to point B in the most intuitive, seamless way possible, whether that "point B" is completing a purchase, learning a new skill, or simply finding the information they need.

It's also communication, but on steroids. Designers are translators, taking complex information, abstract concepts, and raw data and making it accessible and understandable to a wide audience. We use visuals, language, interaction, and even sound to convey messages, tell stories, and guide users through experiences. We're not just making things; we're crafting narratives. We're not just arranging elements; we're orchestrating interactions.

And it's a deeply collaborative effort. Design rarely happens in a vacuum (despite what some lone-wolf designers might think). It involves working with developers to ensure feasibility, product managers to align with business goals, marketers to craft compelling messaging, and most importantly, users themselves to validate assumptions and gather feedback. It's creating something that meets everyone's needs and goals, not just the designer's artistic vision.

AI can be a helpful tool in this process. In fact, it's already changing how designers work:

• AI-Assisted Design: Designers are increasingly using AI to automate repetitive tasks, such as generating variations of layouts, resizing images, or creating basic wireframes. This allows them to focus on higher-level strategic thinking and more creative problem-solving.

• Curator and Editor: Designers are playing a crucial role in selecting, refining, and curating AI-generated content. AI can produce a vast number of options, but it takes a designer's eye to choose the best ones, ensure they align with the overall design vision, and polish them to perfection.

However, it's important to remember that AI can't replace the human designer's ability to:

• Empathize with users: To truly understand their motivations, frustrations, and desires on a deep, emotional level.

• Think critically and strategically: To analyze complex systems, identify root causes, and develop innovative solutions that address underlying problems, not just surface-level symptoms.

• Solve complex problems: To navigate ambiguity, make trade-offs, and find creative ways to overcome constraints.

• Communicate effectively: To articulate design decisions clearly and persuasively, both verbally and visually, and to build consensus among stakeholders.

• Collaborate with others: To work effectively in teams, to give and receive feedback constructively, and to build strong relationships with colleagues.

These are the skills that define a designer, that elevate us beyond decorators, and they're more important than ever in the era of AI. Because AI can generate, but it can't design.

Where Machines Fall Short

Here's where things get interesting, and where we start to see the cracks in the AI. AI-generated design often exhibits design principles, but it's more like a happy accident than intentional design. The AI has seen enough human-made designs (we won't discuss the legalities of that…) to pick up on these patterns, like a student who memorized the answers without understanding the concepts.

AI can group similar elements or create a decent figure-ground contrast in static mockups, but it can also produce visual nonsense, especially when we start thinking about user interfaces. Confusing compositions, ambiguous hierarchies, broken visual flow, and inconsistent interactions… the list goes on. And these issues aren't just aesthetic; they directly impact usability.

I’m sitting in front of a puzzle so let's use that as an analogy. AI can generate a bunch of puzzle pieces, but it doesn't know how they fit together to form a coherent picture. It might create a beautiful-looking button, but it doesn't understand its function in the overall user flow, its relationship to other elements on the page, or how it contributes to the user's goals. It might generate a visually striking image, but it doesn't know how it evokes emotion or tells a story in a way that aligns with the brand's message.

Consider a simple navigation menu on a website. AI might generate a visually appealing arrangement of links, but it might or might not fail to:

• Group related items: Leading to users struggling to find what they need.

• Establish a clear hierarchy: Making it difficult to distinguish primary from secondary actions.

• Maintain consistency across pages: Resulting in a disjointed and confusing user experience.

Why?

Because AI lacks human intuition, deep contextual understanding, and the intent that informs good design. It can generate, but it can't design. It's a tool, and a powerful one at that, and you should learn how to use it. But remember that it is ultimately lacking in the very thing that makes design, well, design: a deep understanding of human perception and behavior.

Why Designers Still Rule

So, all this hype got you sweating? Don't let it. Your skills are still crucial. In fact, imho they’ll become more crucial. We’re the ones who bring the human element to AI-generated work. We're the editors, the curators, the sense-makers. We use our understanding of humans, problem-solving, and visual communication to evaluate the AI output, critique its shortcomings, and refine its output. We're the quality control, the arbiters of taste in a world drowning in AI-generated meh.

AI is a tool, not a replacement.

And like any tool, it needs a skilled hand to wield it effectively. Imagine giving a chainsaw to someone who's never seen a tree. Chaos and a visit to the E.R. That's AI design without a designer's touch. Without us, AI design is just a bunch of pretty (or sometimes not-so-pretty) pixels, devoid of meaning, purpose, or effective communication. We are the ones who give it meaning, who make it work, who make it design.

Teaching AI to See

Want to make AI design that doesn't suck? It's not just knowing Gestalt; it's understanding design to guide the AI. By consciously incorporating design principles into our prompts and parameters, we can steer AI towards creating more visually coherent and effective designs. We become the AI's design directors, the ones who give it the instructions it needs to (hopefully) create something worthwhile.

Even with the most precise prompting, AI can still generate visuals that miss the mark. It might misinterpret your instructions, produce conflicting elements, or simply create something aesthetically displeasing. The key is to use your knowledge to increase the odds of success and to effectively filter through the results.

Instead of just asking for 'a futuristic city,' we can specify 'a tightly grouped cluster of neon buildings with a clear visual hierarchy, where taller buildings dominate the skyline and smaller structures form distinct neighborhoods' (proximity, figure-ground). We're not just asking for a city; we're guiding the AI to create a composition with depth, structure, and a clear focal point.

Instead of 'an abstract logo,' we can ask for 'an abstract logo with implied geometric shapes that uses negative space effectively to create a sense of balance and closure' (closure, Prägnanz). We're not just asking for a logo; we're directing the AI to use specific visual techniques to achieve a desired perceptual effect.

Here are some more obviously simplistic examples of how to use Gestalt to prompt AI:

Proximity:

• A grid of product images with clear spacing between each item to create distinct visual units.

• A navigation bar where related menu items are grouped together to improve usability.

Similarity:

• A series of icons that use consistent shapes and colors to indicate their function.

• A color palette where elements of the same color are perceived as belonging to the same group.

Closure:

• A loading animation that uses incomplete shapes to create a sense of anticipation.

• A logo that implies a complete form through the strategic use of negative space.

Figure-ground:

• A landing page with a clear call to action button that stands out from the background.

• An image with a sharply defined foreground subject and a blurred background to create depth.

Continuity:

• A user flow that guides the user's eye through a series of steps with clear visual cues.

• A data visualization that uses lines and curves to connect related data points.

Prägnanz:

• A simplified icon that represents a complex concept in a clear and concise way.

• A layout that uses a clear and consistent grid structure to create a sense of order.

As AI tools evolve, this ability to guide the machine with our design knowledge will become even more important. We'll be less like button-pushers and more like design directors, shaping the AI's output with intention and precision, even when it tries to give us something… less than stellar.

The Future of Form (and Function)

So, where does this leave us, staring into the abyss of AI-generated visuals that all look blah? I don’t know for sure but one thing is certain: the basic design principles aren't going away anytime soon. They're still the foundation of effective visual communication, the bedrock upon which good design is built.

But AI is undeniably changing the game. It's forcing us to re-evaluate how we use these principles, how we teach them, and how we push the boundaries of design. It's also forcing us to really emphasize that design is so much more than just visuals.

It's understanding people, solving problems, communicating ideas, collaborating effectively, and a million other things that go way beyond "making it pretty." AI can sometimes help with or inspire the "pretty" part, but it can't replace the human designer's brain and heart.

Summary: Object-Oriented UX Design is an alternative approach to traditional, linear UX design, especially useful for complex products. OOUX shifts the focus from user flows to the objects within a system and their relationships. By prioritizing these objects, designers can create more intuitive, consistent, and scalable experiences that better align with how users naturally understand and navigate the world.

When Traditional UX Approaches Aren’t Enough

Okay, so you landed that dream job! Congrats! But then they drop a project on your desk that looks less like a design challenge and more like a plate of spaghetti someone sat on. A million features, tangled user flows, and stakeholders all pulling in different directions. You grab your trusty toolkit of user flows and task analyses, ready to tame this beast, but it feels like you're trying to build the Eiffel Tower with, well, toothpicks.

We designers, in our infinite wisdom (and sometimes misguided optimism), often lean heavily on user flows. We meticulously map out every interaction, every decision point, every possible path a user might take. We're like, "Aha! If they just click this button, then this magical thing will happen!" But users are chaotic, unpredictable, and do what they want. They rarely stick to the script. They jump around, explore, get distracted by shiny things, and find workarounds we never, in our wildest dreams, anticipated. Those painstakingly crafted flows? Yeah, they can end up just being an option. And we're left trying to patch this leaky, convoluted system.

It's like trying to build a house by focusing only on the plumbing or the electrical wiring, without considering the overall architecture. You might end up with a functional system, but it'll be about as livable as a storage unit. This is the "complexity crisis" we often face. As products become more intricate, with more features, more data, and more interconnectedness, those traditional, linear approaches are starting to show their age. We need a new way of thinking, a new methodology that can bring order to the chaos. A methodology that doesn't make us want to throw our laptops out the window. And that is where OOUX design steps in.

How to Design Without Losing Your Mind

So, what's the answer to this abundance of complexity? How do we move beyond the limitations of traditional UX and create digital experiences that people actually enjoy using? Object-Oriented UX Design (OOUX). OOUX isn't just another tool in your design toolbox; it's a shift in how we approach design. It's a paradigm shift that asks us to ditch linear thinking and embrace a more holistic, object-centric view. It's not just tweaking user flows or optimizing tasks; it's re-centering our focus on the objects that users interact with.

To really grok this shift, think about how we, as humans, perceive and navigate the real world. We don't experience reality as a series of abstract actions or linear processes. Instead, we understand our environment through tangible, identifiable elements, through objects. We see a chair, a table, a lamp, a book, a person, and we instantly grasp their purpose, their relationships to each other, and how to interact with them. We don't need a user flow to tell us how to sit on a chair or read a book; our inherent understanding of these objects guides our interactions. It's intuitive. It's natural. It's how our brains are wired. Object-Oriented UX taps into this natural cognitive process. It recognizes that users approach digital products with this same object-oriented mindset. When they use an e-commerce site, they don't primarily think in terms of 'search for product,' 'add to cart,' and 'checkout.' They think in terms of products, orders, users, and shopping carts. They understand the system through these core entities and their relationships to each other.

Sophia Prater, a true OOUX design guru, articulates this beautifully: OOUX "respects the fact that people think in objects and need consistent, recognizable objects to understand an environment or product". We're not just designing interactions or optimizing task completion; we're designing a system of interconnected, understandable entities that mirror how users naturally perceive and organize information in their minds. We're designing for humans, not robots.

Joe Natoli, another OOUX champion, further emphasizes this shift, stating that OOUX involves "...putting the design of objects before the design of procedural actions". This prioritization means that a deep understanding of the system's core entities, their attributes, their relationships, and how users conceptualize them – should precede the design of the specific tasks or flows users will perform. In other words, think "objects" first, "actions" later.

This object-centric perspective allows us to create more intuitive, consistent, and scalable experiences by aligning our designs with the fundamental building blocks of human cognition. It's moving from designing just for users to designing for and with their natural cognitive processes in mind. It's about creating experiences that feel less like a chore and more like a natural extension of our everyday interactions.

From User Flows to Object Maps

To really understand the power of Object-Oriented UX, we need to dive deeper into its shift in focus, particularly when compared to one of the most common deliverables in traditional UX design: user flows.

At some point, when using a traditional method of UX design, we're likely going to create user flows. These diagrams, with their arrows and decision points, map out the user's journey within a product. Think of it like a choose-your-own-adventure story, but for a website or app. We chart every action, every decision point, every potential path a user might take to achieve a goal. For example, in an e-commerce product, a user flow might outline the steps involved in purchasing a product: "User lands on homepage -> User searches for product -> User views product details -> User adds product to cart -> User proceeds to checkout -> User enters shipping information -> User enters payment information -> User confirms order." Sound familiar?

User flows are undeniably valuable. They help us visualize the steps involved in a process, identify potential bottlenecks or pain points, and ensure that users can navigate through key tasks. They're great for planning out linear processes, but they can also be limiting, especially when dealing with complex systems.

One of the main limitations of user flows is their inherent linearity. They tend to depict a single, predefined path, often the "happy path" (that mythical unicorn of user behavior), and don't always account for the messy, unpredictable ways humans actually interact with a product. Users rarely follow a perfectly straight line. They deviate, explore, backtrack, get distracted by cat videos, and find workarounds we didn't anticipate. As a result, designs based solely on user flows can sometimes feel rigid, restricting, and about as adaptable as a rock. They struggle to accommodate the dynamic and often chaotic nature of user behavior.

Also, user flows often focus on the verbs, the actions users take. While this is important, it can sometimes overshadow the nouns, the objects users interact with. We might obsess over the "add to cart" button and the intricacies of the checkout process, but neglect the underlying structure of the products, orders, and users themselves. It's like focusing on the mechanics of a car engine without understanding the overall design of the vehicle.

OOUX design, on the other hand, prioritizes these nouns, these fundamental building blocks of a system. Instead of starting with "what the user does," OOUX begins with "what the user interacts with." It's a subtle but powerful shift in perspective.

Instead of creating user flows, OOUX employs "object maps." These diagrams don't chart a linear path; they visualize the relationships between the core objects in the system. In our e-commerce example, an object map would focus on the relationships between products, users, orders, categories, and so on. It would define the attributes of each object (e.g., a product has a name, price, description, images) and the calls to action users can perform on them (e.g., a user can add a product to a cart, review an order, update their profile). It's a more holistic view of the system.

This object-centric approach offers a more flexible foundation for design. It allows for non-linear navigation, greater consistency, and a system that can scale and adapt more easily as the product evolves. It moves us away from designing a series of isolated tasks and towards designing an interconnected ecosystem of objects that users can explore and interact with in a more natural and intuitive way—it's like building a city, not just a series of roads. It's a shift from designing for a specific, often imaginary path to designing with the user's natural understanding of the world, recognizing that they perceive and navigate digital environments through the lens of objects and their relationships: it's about designing for how people actually think, not how we wish they would think.

The ORCA Process: A Practical Guide to OOUX

OOUX isn't just a philosophy; it provides us with a structured approach to translate object-oriented thinking into concrete design. This is where the ORCA process comes in. Think of ORCA as the backbone of OOUX, a framework that helps you systematically analyze and define the components of your digital system. It's an acronym designed to help you remember the key elements:

• Objects: These are the core entities that populate your digital world. They're the "things" users recognize and interact with.

• Relationships: This defines how those objects connect to and interact with each other.

• Calls to Action: These are the actions users can perform on and with those objects.

• Attributes: These are the properties or details that describe and define each object.

Let's break down each element of ORCA process with some more detailed examples:

• Objects: Imagine you're designing a social media platform. What are the core "things" users encounter? You might identify objects like "Users," "Posts," "Comments," "Groups," and "Messages." These are the nouns, the foundation upon which your design will be built. Think of these as the characters in your user's experience with your product.

• Relationships: Now, how do these objects connect? A "User" can create multiple "Posts." A "Post" can have multiple "Comments." A "User" can belong to multiple "Groups." These relationships define the structure of your system and how users navigate it. Think of them as the plot connections that tie your characters together. Understanding relationships helps us design navigation and information architecture that feels natural to users. For example, if a user clicks on a user profile, they’re expecting to be able to see that user’s posts because those two objects have a relationship. It's about understanding the ecosystem, not just the individual elements.

• Calls to Action: What can users do with these objects? A "User" can create a "Post," like a "Post," comment on a "Post," or follow another "User." Calls to Action are the verbs, the interactive elements that allow users to manipulate the objects within the system. These verbs are crucial for designing intuitive interactions. Think of calls to action as the interactions between characters in your digital story. They're the "doing" part of the design.

• Attributes: What are the defining characteristics of each object? A "Post" has attributes like "text," "image," "timestamp," and "number of likes." A "User" has attributes like "username," "profile picture," and "bio." Attributes provide context and detail, allowing users to understand and differentiate between objects. They are the descriptive details that make your characters feel real and vivid. They're the "being" part of the design.

Going back to designing an e-commerce website. The main objects are things like products, customer accounts, shopping carts, and orders. The attributes for a product would be things like product names, descriptions, and prices. The calls to action on the product object are actions like “add to cart”.

ORCA provides a clear and structured methodology for object-oriented design. By systematically defining these elements, you create a solid design that can effectively organize complex systems. It's like building the foundational framework of a building before worrying about the interior design. ORCA lays the groundwork for creating a user experience that is both functional and intuitive. It's building a system, not just a series of screens.

OOUX in Action: Real-World Examples

Object-Oriented UX is a practical means to a solution employed by forward-thinking companies to tackle real-world design challenges. Let's explore some examples:

• CNN, Navigating the Chaos of Election Night: Imagine the challenge of presenting real-time election results to millions of viewers. CNN faced this very problem. Election data is incredibly complex, with a tangled web of relationships between candidates, states, districts, counties, and electoral votes. Traditional linear UX design methods would have been a disaster. Can you imagine trying to navigate that with just a bunch of user flows? CNN turned to OOUX to bring order to this chaos. They identified the objects "Candidates," "States," "Districts," and "Electoral Votes" and then carefully mapped out the relationships between them. This object-oriented approach allowed them to create a dynamic and intuitive interface that allowed users to explore the election results in a non-linear way. Users could drill down into specific states, compare candidates, track electoral vote counts, and understand the overall narrative of the election, all because OOUX provided a clear and structured framework for organizing and presenting this complex information. It was like turning chaos into clarity.

• HelloFresh, Simplifying the Meal Planning: Consider the challenge faced by meal delivery services like HelloFresh. They need to manage a vast and interconnected system of "Recipes," "Ingredients," "Orders," "User Profiles," and "Delivery Schedules." Traditional design approaches might have resulted in a confusing and frustrating user experience. Imagine trying to manage your weekly meals with a bunch of rigid user flows. HelloFresh utilizes OOUX to bring clarity to this complexity. By focusing on the relationships between these objects, they've created a system that feels intuitive and easy to navigate. Users can seamlessly browse meal recipes, add to their cart, manage their delivery schedule, and customize their meal preferences.

• Taco Bell's Quick Menu Makeover: Even seemingly simple interfaces can benefit from OOUX. Take the example of Taco Bell. They needed to quickly redesign their online menu to improve the ordering experience. Instead of focusing on a linear ordering process, they adopted an object-oriented approach. They identified the objects – "Menu Items," "Categories," "Customization Options," and "Deals" – and structured the menu around these objects. This allows users to easily browse categories, customize their orders, and find what they're looking for, leading to a more efficient and enjoyable ordering experience. It's about designing a menu, not a flowchart.

Addressing OOUX Challenges

While OOUX offers a powerful approach to design, it's not a magic bullet that solves every problem effortlessly. Like any methodology, it presents its own set of challenges. Acknowledging these hurdles and developing strategies to overcome them is important for its successful implementation.

One of the most significant challenges is the initial time investment. OOUX requires a substantial commitment of time and effort upfront. Carefully identifying and defining the objects, mapping their relationships, establishing attributes, and understanding their actions takes a considerable amount of planning and thought. This can be a tough sell, especially in fast-paced projects with tight deadlines. However, it's essential to recognize that this upfront investment pays off in the long run. By creating a foundation, OOUX streamlines the design and development process, reduces rework, and leads to a more scalable product. To reduce this initial time commitment, consider breaking down the OOUX process into smaller, more manageable phases. Start with the core objects and gradually expand the map as the project progresses. Be strategic, not just reactive.

Another challenge is resistance to change. Designers who are accustomed to traditional, flow-based methodologies may be hesitant to embrace OOUX. It requires a change in mindset, a willingness to ditch the old habits and adopt a new way of thinking about design. It's like asking someone to learn a new language after they've been fluent in another for years. Overcoming this resistance requires clear communication, education, and a gradual introduction to OOUX principles. Demonstrating the benefits of OOUX through small-scale pilot projects can help gain buy-in and build confidence in the methodology. It's about showing, not just telling.

Complexity management can also be a significant hurdle. In large and intricate systems with a multitude of objects, those object relationships can become incredibly complex and difficult to manage. Too much complexity and we are back where we started. But with careful planning and organization, an overwhelming object map can be avoided. To navigate this complexity, be sure to have clear and consistent documentation practices. Use visual diagrams, consistent naming conventions, and a well-structured approach to organizing your object map.

Finally, there's the risk of losing sight of the user's journey. While OOUX emphasizes the importance of objects, it's crucial to remember that the ultimate goal is to create a positive user experience. It's possible to become so focused on the objects and their relationships that you neglect the overall flow and interaction of the user. To avoid this, it's essential to combine OOUX with other user-centered design methodologies. Conduct user research, create user personas, and test your designs with real users to ensure that the object-oriented structure supports and enhances the user's experience.

Embracing Object-Oriented Thinking

Whether you're a seasoned designer grappling with the complexities of enterprise-level systems or a fresh-faced designer eager to make your mark, think about embracing Object-oriented UX Design. It might require a shift in your mindset, a willingness to learn new techniques, and a commitment to rigorous thought and planning. Be open-minded, not stuck in your ways. The payoff is immense.

Summary: A robust design system is not just a collection of components, it is a strategic asset that directly impacts an organization's bottom line. By establishing a unified design language and framework, businesses can significantly improve time to market, reduce development costs, enhance brand consistency across all touchpoints, and drive meaningful digital transformation. This article provides a candid look at the challenges and opportunities of building and maintaining a scalable design system, offering actionable insights for senior product designers and managers seeking to leverage design as a competitive advantage.

Why Design Systems Aren't Always a Smooth Build

We’ve all heard the pitch. A design system is the ‘easy button’ for design consistency. Click, drag, drop, boom – instant design maturity. That’s about as accurate as starting my diet on Monday.

Imagine orchestrating a unified user experience across multiple platforms, but your design teams are working from disparate style guides and component libraries. That’s the reality for many large organizations. Creating a design system to solve this problem is not just a style and component library; it’s a strategic endeavor requiring organizational alignment, navigating technical complexities, addressing the inherent resistance to change, and ultimately, managing organizational change.

Beyond the technical and design challenges, implementing a design system is fundamentally an exercise in change management. It requires shifting ingrained behaviors, breaking down silos, and creating a culture of collaboration. This is especially true in large, established organizations where resistance to change can be deeply rooted. Design leaders must anticipate these challenges and develop strategies to navigate them effectively.

Building a design system often feels less like building, and more like managing a complex, evolving ecosystem. One miscalculated move, and you risk creating more design debt than you started with. It's aligning pixels; but it’s more aligning people, processes, and a multitude of strategic priorities.

For example, a situation I heard about from a colleague who previously worked for a large e-commerce company, let's call them 'RetailGiant.' They embarked on a design system project with the lofty goal of unifying their customer experience across web and mobile, a critical strategic initiative for their brand. They had the resources, the talent, and the executive buy-in. What they lacked was a comprehensive understanding of the existing tech and design debt, the deeply entrenched departmental silos, and the change management expertise needed to navigate the organizational shift. They started by trying to create a comprehensive system from scratch, without auditing their existing patterns or involving stakeholders early on. Months into the project, they realized they had created a system that was incompatible with their legacy design and code, and that their teams were actively avoiding its adoption. They ended up scrapping the entire project and starting over, this time with a more iterative approach, a thorough audit, and a focus on collaboration and change management. This experience highlighted the importance of a strategic, phased approach to design system implementation.

The Challenge of Organizational Buy-in

You've meticulously crafted a data-driven proposal, showcasing the undeniable ROI and long-term strategic impact of a robust design system. You're prepared to present your visionary plan to leadership, confident in its alignment with the organization's future goals. Then, you step into the boardroom, and reality hits: the executive team, while polite, is primarily focused on immediate quarterly targets and minimizing disruption. Securing buy-in isn't just about presenting compelling data; it's about translating strategic vision into tangible short-term wins. It's about crafting a narrative that demonstrates how the design system directly supports their immediate business objectives, while simultaneously laying the groundwork for long-term value. You must address their concerns about implementation costs and potential disruption head-on, showcasing how the design system will ultimately reduce costs and improve efficiency, delivering both short-term and sustained benefits.

Take, for instance, a project I worked on a few years back for a large company in Milpitas, California. We'd researched and documented how a design system would shave design and development time by about 20%, reduce support tickets by 10%, and ensure a consistent brand experience across all platforms, directly contributing to key strategic goals. We even had testimonials from similar organizations who'd seen these results. But when we presented, the pushback wasn't about the numbers. It was about 'disrupting existing workflows' and 'the cost of initial implementation.' What they really meant was, 'We're comfortable with the status quo.' We had to shift their approach, framing the design system not as an overhaul, but as a strategic investment to 'optimize existing processes.' We started with a small, high-impact pilot project, showcasing tangible results and demonstrating strategic value before asking for full-scale adoption. It wasn't the grand vision that was initially pitched, but it was a crucial step towards long-term success.

Building a Sustainable Framework

You've secured buy-in, and your pilot project is successful. Now comes the challenge of building a sustainable design system. You're faced with a blank canvas and the question: "How do we scale this effectively?"

Design systems are not built overnight. They require a clear design philosophy, a thorough audit of existing patterns, and a focus on core components. Define your organization's design philosophy, your North Star, to ensure consistency and alignment. This philosophy should be a living document, evolving with your organization.

Conduct a comprehensive audit of your existing products, interfaces, and codebases to identify existing patterns and inconsistencies. This process will inform your design system's foundation. Leverage existing solutions and patterns to accelerate development.

Focus on core components and styles that address immediate needs. Avoid over-engineering and prioritize building a solid foundation. Document everything meticulously, documentation has strategic value.

A common pitfall is designing in isolation. Engage cross-functional teams through workshops and feedback sessions to ensure the design system meets their needs. Establish clear governance models and contribution processes to maintain consistency and quality.

Implement a documentation strategy, including version control and accessibility guidelines. Treat documentation as a strategic asset.

If you need inspiration, here are a few examples of well-crafted design system documentation:

• Carbon Design System (IBM): Emphasizes open-source collaboration and design thinking.

• Polaris (Shopify): Strong focus on accessibility and e-commerce best practices.

• Lightning Design System (Salesforce): Tailored for the Salesforce platform.

As your design system grows, maintaining consistency and quality becomes increasingly challenging. To address this, establish a robust governance model and contribution process. Implement concepts like visual regression testing and validation to ensure that new components and patterns adhere to established standards. Conduct regular audits and reviews to identify inconsistencies and areas for improvement. Track design system metrics to monitor its health and effectiveness, and promote a strong community and feedback loops to ensure that the system remains relevant and useful.

Cross-Functional Collaboration and Influence

Designers, developers, and product managers often operate in distinct worlds, each with their own specialized languages and priorities. Designers focus on user experience concerns, developers on technical implementation and code efficiency, and product managers on business objectives and product strategy. Senior designers and managers play a pivotal role in translating these disparate languages into a cohesive, unified vision.

This isn't about facilitating meetings; it's about making a culture of mutual understanding and respect. It’s about cultivating the ability to articulate design decisions in a way that resonates with developers, and to translate technical constraints into design opportunities. It’s about understanding the product roadmap and aligning the design system with strategic goals.

Translating design into reusable coded components is a particularly challenging aspect of this communication dance. It requires a deep understanding of both design intent and technical feasibility. Senior designers and managers must establish clear guidelines for design-to-code handoffs, ensuring that developers have the necessary context and resources to implement design system components accurately and efficiently.

Tools like Figma's Dev Mode are increasingly vital in this process. Dev Mode, for instance, provides developers with direct access to design specifications, code snippets, and asset exports, all within the Figma environment. This reduces ambiguity and minimizes the risk of misinterpretations, streamlining the handoff and ensuring that designs are implemented as intended. We don’t want to just provide assets; we want to create a shared workspace where designers and developers can collaborate in real-time, for a more seamless and efficient workflow.

But even with the best tools and processes in place, maintaining a design system requires ongoing effort and vigilance. It's not a one-time project, but a continuous process of refinement and adaptation. Senior designers and managers must establish clear communication channels, regular meetings, and a culture of feedback to ensure that the design system remains relevant and effective. This includes providing ongoing training and support to empower teams to use the system effectively, and demonstrating the strategic benefits of the design system to stakeholders across the organization.

Moreover, senior designers and managers must act as advocates for the design system, championing its adoption and highlighting its impact on key metrics. They must be able to articulate the value of consistency, efficiency, and user experience to stakeholders who may be more focused on short-term gains. This requires a combination of strategic thinking, communication skills, and a deep understanding of the business context.

Ultimately, bridging the communication gap is about building relationships and fostering a shared sense of ownership. It's about creating a collaborative environment where designers, developers, and product managers can work together seamlessly to deliver exceptional user experiences.

Balancing Structure and Creativity

When creating a design system we are also navigating a delicate tension: the need for consistent, scalable design versus the imperative for creative exploration and innovation. Senior designers and managers must cultivate a culture of "creative constraint," establishing a framework that empowers teams to push boundaries while maintaining a cohesive user experience.

It is much more than setting rules; it's defining the why behind those rules. Establish clear guidelines and core principles that articulate the strategic intent of the design system. This provides a foundation for informed decision-making and empowers designers to understand the rationale behind design choices.

Think of it like jazz: a structured framework with room for improvisation and individual expression. The design system provides the melody and rhythm, while designers are empowered to add their own unique flourishes and interpretations. This approach allows for a sense of ownership and encourages experimentation, leading to innovative solutions that align with the system's core principles.

To keep the design system's continued relevance and effectiveness, leaders must implement robust metrics to track its impact and demonstrate ROI. This involves measuring key performance indicators such as design time, development time, user satisfaction, and consistency across platforms. If you quantify the benefits of the design system, you can build a compelling case for its continued investment and support.

Furthermore, proactively manage design debt by prioritizing updates and addressing inconsistencies. Regularly audit the system to identify areas for improvement and ensure that it remains aligned with evolving user needs and business objectives. This ongoing maintenance is crucial for preventing the design system from becoming a source of frustration and inefficiency.

We are cultivating an environment of continuous improvement, where feedback is valued and iteration is embraced. We must champion this approach, empowering various teams in the organization to experiment, learn, and evolve the design system over time. This creates a dynamic and adaptable framework that promotes sustained organization adoption and supports both consistency and innovation, ultimately driving better user experiences and achieving strategic business goals.

Scaling Design Maturity

Building a successful design system is a strategic imperative for organizations seeking to scale design maturity. It requires leadership, collaboration, and a focus on continuous improvement. By prioritizing strategic alignment, establishing robust processes, and cultivating a collaborative culture, design leaders can create systems that drive innovation and deliver exceptional user experiences.

Summary: Generative AI is transforming software, moving from predictable tools to creative playgrounds. By offering diverse outputs, it empowers users with choice, but risks overwhelming them. Effective design curates options, provides customization, and prioritizes user collaboration and transparency.

The Shift from Predictable to Playful

Last week, I was trying to pick out a birthday card for my niece. Not just any card, something with personality. A card that screamed 'cool uncle who gets her.' I spent what felt like a lifetime sifting through the same tired cliches: kittens with yarn, puppies with floppy ears, rainbows and glitter explosions. My frustration grew. Where was the card that captured her love for skateboarding and her obsession with Harry Potter? Where was the card that said, 'I see you, you tiny human’.

This frustration, this hunger for something different, is precisely what generative AI is trying to resolve.

We've long designed software features with a singular, defined purpose. A button does one thing. A search bar yields mostly expected results. But generative AI, with its inherent variability, is turning this model on its head. It's doing more than delivering an answer; it's opening a playground of ideas.

For example, what if we had an image editor that doesn't just apply a filter, but generates a dozen variations, each with a unique artistic, or awful, flair. Or a music app that crafts not one, but a collection of songs from a single prompt, allowing users to choose or combine their favorites. This shift is obviously a technical advancement but more importantly it's a foundational change in how we think about software and user interaction. We're moving from predictable tools to dynamic, creative partners.

Understanding Generative AI Variability

At its core, generative variability is the AI's way of saying, 'Here's a buffet of options, take your pick!' It's the ability of a model to produce many diverse outputs from the same input. This isn't about random chance. No, it's more sophisticated than that. It's the result of intense training on massive datasets. The AI learns the patterns and variations within that data. It absorbs the nuances of the data.

But how does it actually do this? To explain this, let’s go back to what the internet is famous for, cats. Imagine feeding the AI a million pictures of cats. Not just any cats. Cats of all shapes, sizes, and colors. Fluffy cats, sleek cats, grumpy cats, and cats with mischievous grins. The AI starts to recognize the underlying essence of "catness." It discerns the common features, the subtle variations, and the unique quirks of cats.

And then... it creates. This is where the generative variability unfolds. It creates cats in hats, kittens in mittens, cats in space, and cats that can defy the laws of physics. We can move beyond rigid, pre-defined experiences. We can craft products that adapt, evolve, and inspire our users.

Empowering Through Choice

So why is this so cool? Simply put, choice and empowerment. By offering a range of creative outcomes, we're not just handing over a product; we're handing over the keys to a world of choice, exploration, and discovery. This is extremely compelling in creative fields, where self-expression and experimentation are of top concern.

But how does this translate into real-world products? Let's explore some examples:

• Google Photos Magic Eraser: Imagine an amateur photographer wrestling with a photo. An unwanted object stubbornly refuses to disappear. Maybe it's a tourist photobombing a perfect sunset shot, or a stray power line ruining an otherwise pristine landscape. Instead of painstakingly cloning out the offending element pixel by pixel, the photographer turns to Magic Eraser. With a few taps, the AI analyzes the image, understands the context, and generates multiple variations, each with the object seamlessly removed in a different way. One option might blend the background seamlessly, another might introduce a creative element like a flock of birds or a wisp of cloud. The photographer, now empowered with choice, selects the version that best fits their artistic vision. This shows how powerful AI design collaboration can be.

• GitHub Copilot: Consider a developer, brow furrowed, stuck deep in code. A particularly nasty bug refuses to be squashed, or a complex algorithm remains elusive. GitHub Copilot comes to the rescue. This AI-powered assistant doesn't just offer a single solution, it generates numerous code suggestions. Different approaches. Different styles. Different levels of efficiency. The developer, now empowered, not only overcomes the obstacle but also learns and grows in the process. They might discover a new library, a more elegant approach, or a clever workaround they wouldn't have considered otherwise.

• Midjourney: And then there's Midjourney. A designer, seeking inspiration for a new project, types a simple phrase: "a futuristic cityscape at sunset." Midjourney, the digital artist, responds. A gallery of images emerges, each a unique interpretation of the prompt. One might showcase soaring skyscrapers bathed in golden light, another might depict a gritty, cyberpunk metropolis with neon signs reflecting in rain-slicked streets. The designer, now explorer, navigates this visual landscape, selecting the image that resonates most deeply with their creative vision. Or perhaps, they combine elements from different images, sparking a new idea entirely.

Overcoming the Paradox of Choice

Choice, while important, can also overwhelm. This is where the 'paradox of choice' comes into play. As psychologist Barry Schwartz demonstrated, while we often believe more options are better, an abundance of choices can lead to decision paralysis, decreased satisfaction, and even anxiety. With generative AI, the risk of overwhelming users is particularly high. Imagine being presented with dozens of AI-generated images. Decision paralysis sets in, fueled by the fear of making the 'wrong' choice. Even after selecting an option, buyer's remorse can linger, diminishing overall satisfaction. This cognitive overload can lead to frustration and ultimately, product abandonment. As designers, we must proactively address this. Implement progressive disclosure, gradually revealing options based on user interactions. Leverage AI-powered recommendations to filter and prioritize choices. Organize outputs with clear visual hierarchies and robust filtering tools. And most importantly, if not already apparent, highlight the key differences between the AI generated outputs.

Leveraging Generative Variability Effectively

Okay, so we've established that generative AI is cool. But how do we know that this buffet of options doesn't overwhelm our users? Designing for generative variability requires a new mindset. We need to embrace fluidity, provide guidance, and relinquish some control.

Think of it like this, you're not just designing a product; you're designing a collaboration. A dance between human intent and AI capability. Here are a few steps to help you get started:

1. Start with a Clear Intent: Define the user's goal. What are they trying to achieve? What problem are they trying to solve by using your generative AI? This clarity will guide the generative process and ensure that the AI's outputs are relevant and meaningful.

2. Embrace the 'Why,' Not Just the 'What': Traditional design often focuses on the 'what' – what the product should do. With generative AI, we need to shift our focus to the 'why' – why the user is interacting with the product. This deeper understanding of user intent allows us to leverage generative variability effectively.

3. Curate, Don't Just Generate: Don't just throw a mountain of AI-generated options at your users. Provide tools for filtering, sorting, and organizing those outputs. Help them navigate the abundance and find the gems that resonate.

4. Give Users a Paintbrush, Not Just a Palette: Don't let the AI have all the fun. Provide ways for users to refine and customize the generated outputs. Imagine a slider that adjusts the level of abstraction in an AI-generated image, or a text field that allows users to tweak the tone of an AI-written article. This hands-on control transforms the user from a passive recipient to an active participant in the creative process.

5. Educate and Empower: Generative AI is still a new frontier for many users. Provide clear explanations, tutorials, and interactive guides to help them understand how to interact with these systems effectively. Empower them to experiment, explore, and shape their own experiences.

6. Transparency: Be upfront about when and how AI is being used in your product. Don’t treat it like magic, behind a curtain, to never be seen. Users appreciate transparency and are more likely to trust systems that are open and honest about their capabilities.

7. Test, Iterate, and Refine: As with any design process, testing is crucial. Gather user feedback, observe how they interact with your generative AI features, and iterate on your designs accordingly. Remember, this is a dance. A collaboration. And like any good dance, it requires practice and refinement.

Ultimately, generative variability isn't just about giving users more options. It's a fundamental shift in how we design and experience products. It's about embracing the unexpected, inspiring creativity, and building a collaborative relationship between humans and AI. It's about recognizing that the most engaging experiences are often those that we shape ourselves, with the help of intelligent tools that expand our creative horizons.

A critical principle often taken for granted in product design is the concept of mental models. These ingrained understandings of the world around us, shaped by our experiences, govern how we use software. Think about the last time you used Google or Apple Maps. You expect to type an address, see a map, and get directions. All of this taken from your real world experience. If Google Maps fails to meet these expectations, it clashes with your mental model. Generative AI products are unique because they often interact with users in ways that feel more human-like than traditional software. This makes users' expectations and mental models even more critical. If the AI's behavior clashes with these models, users can become confused, frustrated, or even distrustful.

What are Mental Models?

Mental models are internal representations that people create to understand how something works. They are based on previous experiences, assumptions, and learned knowledge. These models help users predict how to interact with a product and what to expect from it. For instance, when you see a door with a handle, your mental model tells you to pull it to open. (Unless it's one of those doors, in which case your mental model is probably screaming in frustration.) Mental models can evolve and adapt as users gain more experience.

Why Are Mental Models Important in UX Design?

Aligning designs with users' mental models leads to more intuitive and user-friendly products. When products match users' mental models, they are perceived as easy to use, reducing errors and increasing user engagement. For example, the design of an e-commerce website leverages users' mental models of shopping in a physical store by using familiar actions and elements like browsing, a shopping cart, and a checkout process.

Mismatches between mental models and a product's design can lead to user frustration and product abandonment. Imagine a website where the "add to cart" button is replaced with a less familiar icon. This mismatch can confuse users and hinder their ability to complete their purchase.

How Generative AI is Reshaping Mental Models

Generative AI allows users to directly interact with AI models, which requires a shift from thinking of AI as a tool to thinking of it as a collaborator. This shift can change users' mental models of how they interact with technology. Generative AI can create more dynamic and personalized experiences because the AI adapts to user input. This adaptability requires designers to consider how users' mental models will evolve as they interact with the AI.

The shift from deterministic systems to non-deterministic systems, where the AI's output is not predictable, requires designers to adopt new approaches that facilitate users in understanding and working with the AI's ability to generate unique and occasionally unexpected outputs. Designers should strive to create interfaces and interactions that make the AI's processes more transparent and predictable where possible, and provide clear explanations for unpredictable results.

Challenges and Risks of Ignoring Mental Models in AI Design

Ignoring mental models in AI design can lead to several risks:

• Reduced user trust: If the AI's behavior doesn't align with user expectations, it can erode trust in the system.

• Increased user errors: Mismatched mental models can lead to users making incorrect assumptions about how the AI product works, resulting in errors.

• Product abandonment: Frustration and confusion caused by misaligned mental models can lead users to abandon the product entirely.

AI's dynamic nature presents unique challenges. Designers need to consider how to communicate the AI's capabilities and limitations to users in a way that aligns with their mental models.

Designing AI Products with Mental Models in Mind

Creating AI native or embedding AI into existing products is not just slapping an AI model onto an existing interface; it requires a fundamental shift in how we think about user experience. We're dealing with a technology that adapts and can surprise us with its output. We need to guide users through this new landscape, setting clear expectations, facilitating understanding, and empowering them to achieve their goals. Here are a few best practices that can help us build generative AI products that are not only functional but also delightful and intuitive to use.

• Set Expectations: Build on existing mental models and communicate the AI's adaptability and capabilities.

• Onboard in Stages: Set realistic expectations early and introduce features gradually to allow users' mental models to adapt.

• Plan for Learning: Connect user feedback with personalization and allow users to see how their actions impact AI outputs.

• Account for User Expectations of Human-like Interaction: Clearly communicate the algorithmic nature of AI and set realistic expectations for human-like interactions.

• Transparency: Indicate when AI is involved and provide explanations when possible.

• Guided Prompting: Provide clear instructions and support for prompt refinement to help users interact effectively with the AI.

• Prioritize User Goals: As always, focus on meeting specific user needs and goals and measure success based on user outcomes.

Examples of AI Products and Their Mental Models

Generative AI products thrive by aligning with users' existing mental models, creating experiences that feel intuitive and natural. Here are some examples illustrating how this works:

Chatbots: Software like ChatGPT and Gemini often tap into users' mental model of human conversation. Users expect chatbots to understand natural language, respond appropriately to questions and requests, and maintain a coherent dialogue. A well-designed chatbot doesn't require users to learn a special command language; they can simply type or speak as they would to another person. For example, instead of typing "/get_weather_city=London," a user can simply ask, "What's the weather in London?" The chatbot leverages the user's mental model of asking a question to understand the intent and provide the answer.

Image Generation Tools: Midjourney, Dall-E, Imagen and others rely on users' mental models of visual concepts and how they relate to language. People have an understanding of what a "red apple" looks like, and they expect the AI to translate that textual description into a corresponding image. The tool leverages this mental model to interpret the prompt and generate a relevant visual. Additionally, more advanced prompts might involve combining concepts ("a red apple on a wooden table in a sunny room"). The AI needs to understand the relationships between these concepts, mirroring the user's mental model of how these elements would combine in a real-world scene.

Music Generators: These tools often tap into users' mental models of musical structure, genre conventions, and emotional expression. A person might have a mental model of what a "jazz blues" piece sounds like, including its characteristic chord progressions, rhythms, and instruments. The AI can then use this mental model to generate music that conforms to those expectations. Similarly, a person might describe the desired mood of a piece ("something upbeat and energetic"), and the AI can leverage its understanding of musical elements associated with those emotions to create a fitting composition.

In each of these examples, the success of the generative AI product hinges on its ability to leverage and align with the user's existing mental models. By doing so, the AI becomes a more intuitive and helpful collaborator, rather than a confusing or unpredictable tool.

As generative AI continues to evolve, its success will depend heavily on how well we integrate it with our existing mental models. By understanding this and designing AI experiences that align with users' understanding, we can make the technology useful in real world scenarios. This isn't just a UX concern; it's a fundamental principle for creating AI products that are intuitive, trustworthy, and ultimately, beneficial to humanity. Prioritizing user mental models is not just good design, it's essential for creating a future where humans and AI collaborate seamlessly and effectively.

The Blade Runner Dilemma

The movie Blade Runner's vision of a technologically advanced yet deeply chaotic world isn't just science fiction; it's a cautionary tale for product designers in this age of generative AI. The decisions we make today will determine whether AI empowers humanity or diminishes it. We wield the power to shape how humanity interacts with this transformative technology. It's our responsibility to design generative AI products that serve humanity, and Do No Harm. This requires that we revisit and embrace the principles of Designing Responsibly. It's not enough to create aesthetically pleasing and functional products; we should also prioritize ethical considerations, equality, and the well-being of humanity above all else.

Creating a positive future hinges on one core principle: Designing Responsibly. This principle must be the foundation of every AI-infused product we create. It means crafting systems that not only meet user needs but also uphold values, promote equality, upload transparency, and minimize environmental impact. Technology is not neutral; it reflects the values of its creators. Therefore, we must be deliberate in the values we embed in our designs.

The Human Factor

In the face of complex technologies, like generative AI, responsible design can feel overwhelming. But at its core, it's profoundly human. It begins, as it always should, with a human-centered design approach, building a deep understanding of the people our products aim to serve. We must immerse ourselves in their world, understanding their needs, their frustrations, and what really matters to them. What are their daily struggles? How can AI make a positive impact? We can't rely on assumptions; we must actively engage with our users, integrating their voices into the design process. And let's not forget a crucial question: Is AI the best solution for their particular problem? Sometimes, simpler, more established methods are more appropriate.

Value Tensions and Trade-offs

Human-centered design is essential, but it's not enough. Designing responsibly for AI requires navigating a complex landscape of competing priorities and value tensions. As designers, we're constantly walking a tightrope, balancing the desire for user empathy, product innovation, and profit. It's a delicate balancing act, especially with a technology as powerful, disruptive, and hyped as generative AI. Value Sensitive Design(VSD) offers us a framework for navigating these tensions. It goes beyond understanding user needs; it compels us to consider the values of all stakeholder: users, developers, businesses, and society at large. VSD prompts us to ask: How might this AI-powered tool impact different groups of people involved with the product? Will it exacerbate existing inequalities? Could it be used for malicious purposes? For example, imagine designing an AI-powered hiring software. VSD would push us to consider not only how it streamlines the hiring process (a business value) but also how it might perpetuate bias against certain demographics (a societal value) or compromise individual privacy (a user value). It forces us to confront these value tensions head-on, acknowledging that there are often no easy answers. Sometimes, we'll need to make difficult trade-offs. But by explicitly considering these competing values, we can make more informed design decisions.

Managing Emergent Behaviors

Another critical challenge in designing for generative AI lies in its capacity for unforeseen capabilities. These 'emergent behaviors,' as they're sometimes called, can be both a blessing and a curse. On the one hand, an AI might suggest an insightful solution that no one anticipated. This can be incredibly valuable. However, these unexpected capabilities can also lead to unintended, and potentially harmful, outcomes. Imagine an AI designed to help writers overcome writer's block. It might suggest creative phrasing or plot twists. But it could also generate plagiarized content, or content that inadvertently promotes harmful stereotypes. We must anticipate and address these potential issues during the design process. How do we encourage beneficial emergent behaviors while reducing the risks? The answer lies in testing and continuous monitoring. Constantly evaluation of our AI systems, to ensure they're not only performing as intended but also avoid harmful outputs should be designed in.

Creating software with this new paradigm is not a 'build it and forget it' job. It's an ongoing dialogue with our users. Just as a conversation evolves, so too must our AI products. We need to establish robust feedback loops, constantly testing in real-world scenarios, observing how people interact with them, and actively seeking user input. Identifying emerging biases, detecting toxic content, and validating feature usefulness are tasks that require continuous attention. Testing and monitoring must be integrated into the product lifecycle, not afterthoughts. A proactive approach allows for early identification and resolution of potential issues, making sure the evolution of our product is ethical.

Ethical Considerations

Now, we can't talk about designing responsibly without tackling the big "E", ethics. Generative AI throws up a whole bunch of ethical questions. Is the AI biased, favoring certain groups over others (See early editions of image creation in Gemini)? Who owns the content the AI creates? These are tough questions, and there aren't always easy answers. But we can't just ignore them. We have to wrestle with these issues and try our best to create products that align with our values.

How do we put all this into action? Here are a few things we can do:

• Ethics First: Don't treat ethics like an afterthought. Think about the ethical implications from the very beginning of the design process.

• Listen to Your Users: Talk to them. Observe them. Try to understand their needs, their values, and their concerns.

• Diversity Matters: The more diverse your design team, the better. Different perspectives can help you spot potential biases and harms that you might otherwise miss.

• Fight Bias: Use the tools and techniques available to detect and reduce bias in your AI.

• Be Transparent: Tell your users what your AI can do, and what it can't. Don't try to hide its limitations.

• Safety First: Always prioritize the safety and well-being of your users.

And don't worry, you're not alone in this. There are tons of resources out there to help you design responsibly. Google's AI Principles are a great place to start.

Do No Harm

Designing responsibly isn't just about avoiding problems. It's about building amazing experiences that are safe, effective, and benefit humanity. We're in the driver's seat when it comes to shaping the future of generative AI and its uses. Let's weave these principles and strategies into everything we do, and create a future where technology makes life just a little better by Doing No Harm.

I recently stumbled across an article about taking inventory of the digital tools we use every day. It got me thinking, "What the **** am I even using these days?" So, I compiled my own list. Fair warning, it's a bit long, and I'm sure I've missed a few things. I purposely left out some items used for very specific work tasks. This isn't a recommendation list or a review. Just a brain dump of my current setup and some thoughts.

Why bother with this whole thing? Well, it's easy to get lost in the sea of subscriptions and new apps. This exercise forced me to take a step back and see the big picture. In a couple cases I realized I was paying for two tools that do the same thing. It's also a chance to ask myself, "Is this still serving me, or is it time for a change?" I guess it's like decluttering, which I’ve been doing a lot lately.

My Creative Toolkit

• Paper and Pencil: I doodle and sketch. I don’t always have my iPad available but do carry a Sketchbook and Pencil.

• Figma: Used for UI design and most digital content creation. Just starting to use it for presentations.

• Substack and Medium: I believe that the best way to understand something is to learn it and express it.

• Xnapper: My favorite screenshot tool. Quick, easy, and does the job perfectly.

• Screen Studio: When I need to quick screen recording that looks good.

• OBS: I mainly use this for streaming, but it's a solid tool for recording too.

• Adobe After Effects: For random motion graphics.

• Adobe Premiere: Occasionally, I need to edit longer videos. Eventually I’ll try DaVinci Resolve

• Adobe Illustrator: I don't use it as much as I used to, but it's still my go-to when I need to do more heavy-duty vector work than Figma can handle. Figma can probably still handle it so we will see what happens this year.

• Google Docs: Most of my writing happens here.

• Procreate: Digital sketchbook for quick ideas and doodles.

• Adobe Fonts, Google Fonts, MyFonts: I use Adobe Fonts and Google Fonts for most projects, but sometimes I buy a typeface outright from MyFonts.

• Mobbin: Design inspiration and teaching.

AI Assists

• Gemini: Since the paid version comes with my Google subscription, I use it. Gemini 1.5 and 2 seem to be up there with ChatGPT for my use cases. I use it to brainstorm and when I need images of “people”. I find that Imagen 3 does a better job than Midjourney. I am also finding 1.5 Pro with Deep Research useful.

• Claude: Helping me write and debug code.

• Vercel v0 and Cursor: I like experimenting with new AI coding tools, and these have been my latest.

• Midjourney: Just started using it for more stylized and artistic imagery.

• Eleven Labs: Use it for short voice overs and random content on other platforms. Typically when I can’t, or don’t want to, record myself.

• NotebookLM: For more focused things.

Dev Tools

• Kitty: What can I say, it's a terminal. I like the way it’s configured.

• Neovim: I started writing code in Vim and graduated to Neovim. I tried vim mode in VS Code, but it just wasn't the same.

• Visual Studio Code: Sometimes I just need it.

Staying Connected and Distracted

• LinkedIn: It can be cringey sometimes, but a necessary evil for staying connected with colleagues and former students. (go head and follow)

• Slack: General communication hub for projects.

• Instagram and Threads: For distraction.

Knowledge Quest

• Readwise Reader: I use it to highlight articles, books, and take notes. I like that it automatically exports my highlights and notes as Google Docs that I can bring into NotebookLM easily.

• YouTube Premium: Worth it for the lack of ads.

• Libby: One of the best resources for free books. Connects to the San Francisco Library’s Digital Collection. The wait for some books can be multiple weeks but worth it. Also, syncs with Kindle so I’m not stuck on my phone or iPad to read.

• Talk To Me In Korean: A web and mobile app I use for language learning.

The Apps That Keep Me Sane (Mostly)

• Todoist: My task manager, keeping me organized and on track. The paid version has some interesting AI features that help rewrite task so they are more actionable.

• Gmail and Google Calendar: My email and calendar since their beginning.

• Outlook: I need this for work email and calendar. I've managed to sync Outlook Calendar with Google Calendar, though.

• Google Drive (Docs, Sheets, etc.): Part of my Second Brain. I store most of my files in Drive. I also do most of my writing in Google Docs.

• Notion, Apple Notes, Google Keep: I bounce back and forth between note taking apps at least 2 times a year.

• Hover: Domain registration.

• Webflow: For site hosting. Will move over to Framer next time my payment comes due.

• Partiful: For all the parties I don't go to (just kidding... mostly).

The Gadgets

• Macbook Pro: I've had a 14-inch M1 Macbook Pro for a while now. It still does the job, but I get tempted…

• iPad Pro: Can't remember the exact model, but I use it as a second screen with Sidecar or sketching in Procreate.

• iPhone 14 Pro: Still a great phone. No need to upgrade yet, though I'm tempted to switch to the "green bubble" now that Messages supports RCS.

• Kindle Paperwhite: My default reading device.

• ASUS ProArt Display (32 inch): A large display that looks good. It was a bit pricey, but I got a good deal.

• Logitech MX Master 3s for Mac: I'm a longtime fan of Logitech mice, and this one is no exception.

• Durgod Mechanical 80% Keyboard: A solid mechanical keyboard (I don't think the company exists anymore). I swapped out the keycaps for some with Hangul and English characters.

• Fuji X-T3: My DSLR. Used daily as a webcam with an Elgato Cam Link 4K.

• Samson G-Track Pro Microphone: Significantly improved my audio recording game.

• Elgato Cam Link 4K: Lets me use my Fuji as a webcam.

• Elgato Key Lights: My recording/streaming space is dimly lit. They work well overall, but I occasionally have some issues with the Wi-Fi connection.

The Graveyard

• Monotype Subscription: Beautiful selection of typefaces, but I couldn't justify the yearly cost.

• Blinkist: I found myself reading more reviews and buying the full books anyway.

• Snipd: Too frustrating to listen to a podcast and then try to extract the highlights.

• Opal: I can see why people like it but I don’t need something that complicated. Apples Focus and Screen Time do the job.

• Obsidian: I love the idea of connected note-taking, but I already have so much invested in my other tools that it's hard to make the switch.

• X: I never really used it much.

Stay Tuned...

• Replit: Looks intriguing.

• Sora and Veo 2: I want to check these out as they become available.

• Suno: If they still exist by the time I get to it. I read recently they are having a lot of copyright issues.

• Lottie Creator and Phase: Lottie animation and micro-interaction creation tools.

• Capcut: Late edition to this list.

So, there you have it, a peek into my toolbox. Do you have anything you think I should be trying out? Comment below and let me know.

You know that scene in The Wizard of Oz where Dorothy finally meets the Wizard, and he turns out to be just a regular guy hiding behind a curtain? That memorable moment isn't just a Hollywood creation; it's actually a powerful and fun UX research technique.

It's called the 'Wizard of Oz' (WOZ), and this method has been helping researchers and designers understand how people interact with technology since the 1980s. Consider it a bit of harmless trickery, all in the name of creating awesome products.

Pulling Back the Curtain

Let's say you're testing a new voice assistant. You ask it to set a reminder, and it responds exactly how you expected. But what you don’t know is that there's a human "wizard" behind the interface, coming up with responses on the spot or selecting them from a pre-written list.

This method lets us test our concepts, interfaces, and more using a believable illusion, even if the technology isn't fully functional yet.

Wizard.ai

In the age of AI, where things move at warp speed, WOZ is more relevant than ever. Building AI-powered products is complex and expensive. WOZ lets us test our ideas early on, without writing a single line of code, something that is hard to do when designing AI and other complex products.

By catching usability flaws early on, you avoid costly redesigns down the line. More importantly, observing real users interacting with your AI-powered features allows you to create effective experiences (all before investing heavily in development).

Showtime!

How do you facilitate a WOZ study? It’s a little like filming a movie.

Staging and Casting

• The Director (That's You): You'll define the goals and features you want to test.

• The Stage: A prototype that users can interact with, this could be a simple mockup or even a physical prop.

• The Actors: A human acting as the AI interface, responding to user actions, like a wizard behind a curtain. The wizard can use predefined responses (closed method) or improvisation (open method).

• The Audience: Your target users, ready to experience your art.

Lights, Camera, Action

During the study, observe how users interact with your "magical" prototype. Collect data and take notes. Afterward, analyze the results and use those insights to shape your design.

More Than Just Smoke and Mirrors

WOZ goes beyond 'fake it till you make it.' It's a excellent tool for tackling those intricate design challenges that leave you feeling stuck. Consider scenarios like:

• Adaptive Learning: Language learning app that adjusts to the learner skill level and provides personalized lessons. WOZ lets you test different learning paths and feedback mechanisms to create a customized experience.

• Personalized Feedback: A fitness app that analyzes workout data and provides recommendations and tailored exercise advice. WOZ helps you fine-tune those recommendations and ensure they're motivating and helpful.

• Complex Systems: Smart home system that responds to voice commands and anticipates user needs. WOZ lets you test different scenarios and ensure a frustration free experience.

Budgets are always a concern, and the beauty of WOZ is that it allows you to test and iterate without the cost of any implementation. This means you can gather insights, avoid expensive errors, and ultimately, bring your product to market faster.

The Ethics of Illusion

It's crucial to address the ethical considerations that come with WOZ’s deceptive nature. We're essentially pulling the wool over our participants' eyes, even if it's for a good cause. To make sure your WOZ study remains ethical and you maintain your integrity, transparency and informed consent are key.

Before starting your study, be upfront with participants about the nature of the experiment. Explain that some aspects of the technology are being simulated by a human operator. Don't reveal all the mechanics of the Wizard, but emphasize that their feedback is crucial for developing a genuine experience.

After the session, conduct a in-depth debriefing, explaining the WOZ technique in detail and highlighting why the role of the Wizard was necessary. This open communication helps participants understand the purpose of the study and its potential.

There's No Place Like Home... But WOZ Can Help You Get There Faster

So, as you go down the yellow brick road of design, remember the lessons of The Wizard of Oz. Embrace the power of illusion, gather insights from your users, test your product, and don't be afraid to experiment. With a little help from the Wizard, you'll be well on your way to creating delightful product experiences.

This winter break, I hit the road, craving the escape of a long drive. You know, the kind of trip that stretches for a few hundred miles and weaves through the glow of city horizons and sunbaked mesas. After a few months of being static in San Francisco, I was delighted by the freedom of the open road.

But as I sped through the breathtaking (and sometimes nose-holding - sorry, Coalinga!) scenery, my attention was very unexpectedly captured by the humble highway sign, that wayfinder we so often take for granted.

Call me a nerd, it's okay. I just couldn’t help but be fixated on the typefaces of those green guideposts. And that's how I started down the rabbit hole of the Highway Gothic and Clearview typefaces.

The OG of Road Sign Typefaces

Rewind to the 1940s. A time when chrome gleamed, engines roared, and America hit the gas, embracing a newfound freedom on the open road. Post-war America was in love with the automobile. Families piled into their new Chevys and Fords, eager to explore a country inaccessible to them in previous years. But road trips became a gamble. Would that next turn lead to Aunt Barbara's, or a dead end, thanks to a confusing sign? Imagine a jumble of signs, some faded, some freshly painted, each shouting its own message in a disharmonious collection of fonts and colors. This visual chaos wasn't just annoying, it was dangerous. Drivers, eyes darting between the road and a mishmash of competing signs, were prone to miss crucial information, leading to wrong turns, near misses, and worse.

Enter the Federal Highway Administration, determined to bring order to this visual anarchy. Their solution was a typeface designed for the age of the automobile: Highway Gothic.

Highway Gothic was more than just a simple typeface. It was a breakthrough in safety, designed for the demands of the open road. No serifs to get lost in the blur of the passing landscape, just pure, legibility. Even at a breakneck 35 mph (hey, it was the 40s!), Highway Gothic allowed drivers to grasp crucial information in the blink of an eye. For decades, it stood as a symbol of clarity and order in a rapidly changing world, a tribute to the power of good design.

A New Challenger

But time, as they say, marches on. By the late 20th century, highways were aglow with new, reflective signs, shimmering under the headlights like constellations. Ironically, these technological advancements, intended to make roads safer, introduced a new visual challenge: halos of light around the letters, especially those of Highway Gothic. For people with less-than-perfect vision, these halos could be a real headache.

What was needed to remedy this? Of course, another typeface: Clearview. Clearview took the best of Highway Gothic and subtly refined it, enlarging the counters of letters like 'o' and 'p', and giving lowercase letters a boost in height. This lead to sharper letters that cut through the halo effect, making signs legible from even greater distances, in even worse conditions. Clearview is proof that good design is always adapting, always finding better ways to guide us on our journeys.

Legibility vs. Tradition

Clearview's arrival wasn't met with universal applause. In fact, it ignited a debate that would illuminate the complexities of design, it pitted researchers against each other, with drivers caught in the middle. Penn State University conducted research that resulted in promising findings, suggesting that Clearview could shave precious milliseconds off a driver's reaction time. Milliseconds that could mean the difference between a safe swerve and a tragic collision.

Just when it seemed like Clearview was about to conquer Highway Gothic, a plot twist emerged from the Lone Star State. Texas A&M organized a study that challenged Penn State's conclusions, slowing down Clearview's momentum. Their research found that Clearview wasn't always an improvement, particularly for signs with negative contrast (dark letters on a light background, often used for warning and speed signs). This was a crucial detail, as these signs often convey the most urgent information.

The Federal Highway Administration, initially eager to embrace Clearview, suddenly found itself playing referee. In response to the conflicting research, they opted to remove their recommendation of Clearview. The future of Clearview, once so bright, now hung by a thread, leaving drivers and designers alike to wonder. What's the next chapter in this saga?

Congress Gets Involved

As everyone was floating around in limbo, the government decided to get involved. Congress, in all its wisdom, decided to wade into the typeface debate, reinstating Clearview and throwing the entire highway signage system into a state of confusion.

So now, thanks to our elected officials, America's highways became a typographic mixtape. The reinstatement of Clearview meant that both typefaces were officially sanctioned, leaving the states to do the decision making.

The Clearview saga became a case study in how government intervention and design by committee can sometimes muddy the waters, even with the best intentions. This wasn't just about fonts anymore. It was about bureaucracy, politics, and money (oops…).

Heading Home

With miles fading behind me, and Highway Gothic and Clearview twerking in my rearview mirror, I wondered. Will either of them ever stand alone? Will we stick with the typographic status quo? Or could a new contender emerge, a typeface that can morph to the whims of a digital highway sign?

Maybe Waymo's robo-taxis will usher in an era of emoji-based navigation. (Shudder.) But one thing's for sure, as long as there are roads to travel, there will be typefaces vying for our attention, guiding us towards Aunt Barbara’s.

This critical juncture of the design process is like navigating a tightrope. Misunderstandings, overlooked details, and conflicting expectations can transform this bridge between creativity and functionality into a battleground. However, this adversarial relationship is avoidable.

We can have a world where designers and developers work in harmony, where the handoff is a dance of collaboration, not a clash of wills. Where the final product not only looks stunning but also works flawlessly. This is the power of a smooth design handoff.

Why a Smooth Handoff Matters

A well-executed handoff is the cornerstone of a successful product. It's not only about aesthetics; it's creating a user experience that is both beautiful and intuitive. When designers and developers are in sync, the final product reflects the original design intent, ensuring a cohesive and delightful user journey.

But the benefits extend beyond the product itself. A collaborative handoff process creates a culture of respect and understanding between designers and developers. It breaks down silos, encourages open communication, and builds a sense of shared ownership and accountability over the final product. This translates to happier, more productive teams.

Moreover, a smooth handoff is a time-saver and money-saver. When developers have all the information they need, they can avoid making assumptions and going down the wrong path. This reduces rework, speeds up development time, and ultimately saves valuable resources.

Navigating the Challenges: Common Pitfalls and Solutions

The path to a smooth handoff is not without challenges. Let's explore some of the most common obstacles and how to overcome them:

The Tower of Babel: Miscommunication and Knowledge Gaps

Having been a developer and now a designer I can say, we often speak different languages. Designers may use design jargon that developers don't understand, and developers may have technical constraints that designers aren't aware of. This can lead to misinterpretations and a final product that doesn't get the job done.

The solution? Build bridges of communication. Encourage open dialogue, regular meetings, and design reviews. Create a shared space where designers and developers can ask questions, clarify doubts, and ensure everyone is on the same page. 

The Maze of Files: Disorganized Design and Lack of Clarity

Without a smooth handoff developers often find themselves lost in a maze of disorganized design files, struggling to find the assets they need or understanding the designer's intent. This can lead to frustration, delays, and flaws in the implementation.

The key is to create a clear and organized structure. Implement a standardized file naming convention and folder hierarchy that mirrors developer practices. Also be aware of what information developers actually need. It is unlikely they will need research deliverables and user insights. Having to dig through unneeded information is just as frustrating as not being able to find the files they need right away.

Provide comprehensive documentation, including annotations, specifications, and explanations of design decisions. Use features in your design tools like Figma’s commenting or cursor chat.

Overlooking Crucial Design Details

Designers, in their pursuit of the perfect user flow, sometimes overlook crucial details like error states, loading screens, empty states, and various interactive element states. These "unseen corners" of the design can lead to a disjointed user experience and unexpected development challenges.

So provide detailed documentation that covers all possible use cases and design states. Use video recording tools to make walkthroughs and explain design behavior and user journeys. Consider creating flowcharts or wireframes to illustrate the information architecture and user flows.

The Path to Success: Tips for a Seamless Handoff

Involve Developers Early and Often

Bring developers into the mix from the early phases. Their early feedback on feasibility and technical constraints can save you from design decisions that are impossible to implement.

Embrace Design Systems

A robust design system is the Rosetta Stone of product development. It provides a shared visual language and a library of reusable components and styles, promoting consistency and efficiency between designers and developers.

Leave Nothing to Chance

A handoff checklist ensures that all necessary assets and documentation are delivered, leaving no room for ambiguity. It's a safety net, ensuring nothing falls through the cracks.

Schedule a Follow-Up Meeting

A dedicated meeting after the handoff allows developers to ask questions, clarify any doubts, and ensure a smooth transition into the development phase. It's your chance to address any lingering concerns and set the stage for a successful implementation.

Don't Stop Communicating

Communication shouldn't end at the handoff. It's an ongoing process. Encourage open dialogue throughout the development process to address any issues or questions that arise. Remember, you're all on the same team with the same goal.

Conclusion

The design to developer handoff is arguably one of the most important junctures in the product development journey. It's where design vision meets reality, where creativity meets functionality. By understanding the challenges, implementing solutions, and embracing a collaborative mindset, you can transform this often-dreaded phase into a seamless experience. Remember, a smooth handoff is not just about delivering a product; it's about building bridges and creating experiences that delight users and make deadlines.

‍