Today we’re exploring @bethanygilleeney’s article, MCP for Designers: What It Actually Does (and Doesn’t). She resets expectations. MCP does not change what designers do, and it does not magically make AI products better. It makes it easier and safer for AI systems to connect to real data and tools.
That matters, but it is not design. MCP does not create better experiences on its own. As you highlight, it does not understand users, make judgment calls, or solve product problems. It is infrastructure, not something users directly see.
Here are the areas you suggest it helps:
Connects AI to real tools and data in a clean, standard way
Reduces one-off integrations and brittle custom code
Makes AI systems easier to maintain and scale
Improves security by controlling what AI can access
Helps teams move faster once decisions are already made
Supports consistency across products and services
Lowers engineering friction behind the scenes
Let’s jump into the discussion
Your main point is that MCP is a building block. It helps AI tools work with real systems, but it does not replace design judgment, research, or decisions. Designers should understand it enough to work better with engineers and ask better questions.
So let’s open it up: If MCP is a building block and not the work of design, where does it actually change the future of products and design?
Let’s explore with Beth Gilleeney, a new Glare author, and dive into this emerging technilogy!
Great to chat with you today, Beth. I’m excited to explore your ideas with product and design leaders who support their teams. Things are changing week by week. What drew you to dive deeper into the technical side of design?
Thanks so much for having me! There’s a lot of debate about the technical side of design, so it naturally got me curious. For me, mainly, it’s about knowing what constraints exist. That way, I have a better idea of when it makes sense to sit within them & when it makes sense to challenge them. Early on in my career I’d go into meetings with developers and a lot of my questions would be “Is it possible to…? Can we do…?”, so on and so forth. As soon as you start to embrace a more technical perspective, you can begin to answer those questions for yourself and lean on your dev team for the more complex bits.
Here’s how Eames frames design:
Design is the deliberate arrangement of elements to accomplish a purpose.
It is a method of action grounded in recognizing needs and working within constraints.
It’s great to see you diving into these problems. For the leaders in this community who are still experimenting with AI, where do you think they should start using MCP with their teams?
Great question. AI is a hell of a beast, and design especially has seen a surge in people building for the first time. Because of this, it’s easy to experience FOMO and feel like you’re falling behind. MCP was a tough one to get the hang of, and I’ll be the first to throw my hands up and say I’m still in the early stages of learning about it.
For anyone who hasn’t used it, I’d start with Figma’s MCP. We already know Figma, so it doesn’t feel like too far of a step into unknown territory. From there, there’s no shame in starting small. Build something in Figma, connect it to whatever AI tool you’re using, and watch static screens come to life. That’s where the magic kicks in for me. MCP is allowing me to create experiences, and experience what I’ve designed, in a way & at a speed I never could’ve before.
This is great advice. Even for leaders, building something is the fastest way to learn about the constraints and medium.
I’m curious from your perspective, what does the speed give you? More time to explore? Better results? Efficiency is a buzzword these days. This isn’t always articulated in articles.
Something I’ve done recently was take an older piece of work: a finance calculator. It was originally designed before AI tools were as widely available, and so there’s a huge chunk of that experience that I could only truly understand once it’d been built with real data. What happens in the background when a slider is changed? How does one design for cases where the time between a value being changed and seeing a result is 2, 5, 10 seconds? Those questions never really come to mind when you’re designing in Figma.
But with AI, and bringing your exact designs to life with MCP, those questions do come to mind. And once they do, it feels really magical. As a designer, I’m now no longer just designing form elements. I’m considering the tech that goes on in the background, and I’m identifying design opportunities at every point.
Efficiency will always shout the loudest and appear to be the most enticing when it comes to AI, but for me it’s the level curiosity that it enables that’s more important.
Awesome. I’m dating myself here, but I played around with my first Commodore computer in the 80s, writing code to design animations with colored pixels. I loved it. I wasn’t a coder, but it gave me an appreciation of how logic worked with creative expression.
Do you feel this is an emerging role, or does every designer need to know these skills moving forward?
I love that! And no, I don’t think every designer needs these skills. The way a product designer utilises AI may be entirely different from how a service or content designer does, and that’s fine. But as someone who sits in the product design space, if you have curiosity around the technical side then it’s something I’d actively encourage. It goes such a long way in how you communicate and collaborate with others.
Right. And I think by engaging with these tools, you get a better appreciation of where things are not up to snuff. As you highlight, if you put junk in, you’ll get junk out.
What types of conversations are you having with the technical teams now? Seems like there are all kinds of new things to talk about. At least on our team, it’s a very exciting time.
It actually reminds me of an article I read recently from someone who’s contributed here before: Kevin Muldoon’s “Why Engineers Can Say ‘This Is Wrong’ and Designers Can’t”. Design often sits in a place where we can’t just say no, so you learn to ask a lot of questions and dig into the reasoning behind decisions. Why does someone see it that way? How do we align our thinking? Lately, my conversations with technical teams have been exactly that: I’m asking more questions than ever, even the ones that feel a bit silly to ask. And the response has been great too.
Even this week, a lot of my questions have been around managing API delays, the example earlier about what happens in the background when an input is changed, whether code from Cursor is good enough for devs to use or not, how devs can leverage prototypes I’ve made with AI. These are questions that were never even in my field of view a couple months ago.
This is great. For learners, this curiosity can take you far. For a subset of team members though, this has become a short term living hell. This transition has not been easy for everyone as there is a level of learning fatigue.
In addition to the learning, the feedback loops required to create great products takes a lot more back and forths. Communication, funny enough, is HUGE right now. It always has, but it seems even more so. Any tips for design teams on engaging the technical side?
One of my biggest mantras is to involve your dev team as early as possible. Invite them in on your brainstorming sessions, hear them out if they bring ideas to the table, challenge their ideas, and help them become advocates for what you design. They’re the ones who bring our ideas to life in the end. It’s easy to only bring in your dev team when they’re needed, to only show them ideas once they’re refined. But I think you miss out on so much opportunity when you work that way.
I want to thank you for sharing your ideas with us Beth. It’s inspiring to hear about your journey- keep pushing us forward! We will keep the thread open for others to jump into the conversation.
Thanks for sharing @bethanygilleeney! This one’s a little outside of my depth as a researcher, so I’m curious: is the MCP meant to solve the problem where you design something beautiful, and then the engineer gets ahold of it and starts pointing out issues in actually building it into the product?
