Portfolio presentations are a typical step in the product design interview process, and with them comes a common set of pitfalls that can make good work difficult to assess. I’ve seen these patterns across years of portfolio presentations, and the good news is that they are possible to overcome.

But first, a reminder of why portfolio presentations are an important part of the interview process. They serve as a way for hiring managers and interviewers to understand your design thinking, craft, collaboration and communication through real examples. For the candidate, it’s an opportunity to show off your talents and get people excited to work with you.

Use your words wisely

It’s important to set context for your work so the interviewer can understand the problem you were solving and why it was important. A mistake I have seen people make is spending too much time setting context and taking too long to get to the work. The interviewers need just enough to understand the why behind the work. Clearly explaining the business context, the user problem, and why it matters now is often enough context. And speaking of using your words wisely, avoid jargon where possible. Too much jargon can make your story hard to follow if you rely too heavily on it. Use plain language and explain any jargon if it’s part of your story.

Show your part in the team’s story

The tricky thing about product design case studies is that interviewers are trying to evaluate your individual work and how you worked with others. It’s a fine balance. Some common mistakes here are unclear ownership or little to no explanation of collaboration. Talk about how you worked with your product manager or engineer to make decisions. Did you get feedback from a partner that changed your work?

This can get especially tricky when leading others. You do want to talk about your team’s work, but we also want to know what your specific contributions were.

Let us into the messy middle

I’ve seen case studies spend too much time on process or walking through a product, and too little time showing the messy middle, iterations, and trade-offs. Describing a familiar process like the “double diamond” doesn’t explain how it helped this particular project. Similarly, initiating a workshop or design sprint is only part of the story. Explaining what changed as a result is the useful detail. A designer is expected to explore and try different things and then iterate before arriving at a final design. Seeing what you explored, how you narrowed down your options, and why you chose a direction helps the interviewer understand how you use your craft to solve problems with others.

Make it easy to follow

Dense slides, reading from a script, and poor time management are things that can detract from the storytelling you are being evaluated on.

Aim for “one idea” per slide. If you find yourself trying to fit paragraphs of text onto a slide, ask yourself what point you’re trying to make. Could an image also communicate the same idea? You’ll also be speaking during this, so what’s on the slide just needs to anchor the audience in what you’re saying.

Presence and delivery are different for everyone. Reading a script word-for-word can make it feel less conversational. Starting with brief talking points will allow for a more natural delivery. Practice, practice and more practice will help you tell your story more naturally and manage your time. Interview prep guidance will give you a sense of how much time to allot for content and for questions. Time yourself practicing, or record a video, so that you can get through your content with enough time to answer questions.

In closing

Make it easy for the audience to understand what you contributed, who you collaborated with, why you made the decisions you did, and what you learned from the result. And remember, show off your talents and get people excited to work with you.

Portfolio Presentation Pitfalls was originally published in Thumbtack Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Change one word in a button label and you can move a conversion rate. Content Designers do this every day. “Cancel subscription” hits differently than “End membership.” “Delete” feels heavier than “Remove.” Tiny tweaks, massive shifts. We obsess over single words because we know a word is never just a word; it’s a promise about what will happen next, and a cue for how afraid to be about it.

Too bad the tech industry’s biggest, most consequential naming decision didn’t get that same scrutiny. In 1955, a term went out into the world with no usability research, no A/B test, no Content Design review. Seventy years later, that term is still generating a level of public dread that no other category of software has ever produced. Nobody is losing sleep over “cloud storage” or “relational databases.” But people are absolutely losing sleep over “artificial intelligence.”

My daughter is one of those people. She raises a lot of good points about the pitfalls of AI, particularly the massive amounts of electricity and water it can require. As an aspiring artist, she’s also concerned about style mimicry and the devaluation of human creative labor. The hype around artificial intelligence has convinced a lot of people that it will either save everything or destroy everything. After all, isn’t that what we imagine extreme intelligence should be capable of?

The name itself is a significant part of the issue. And it was avoidable, because at the moment it was coined (as is often the case), better names were sitting right there on the table.

A name is a mental model, whether intended or not

Every product name ships a small, implicit theory of what the thing is. Call something a “wallet” and people expect it to hold money and close. Call something a “feed” and people expect a stream that never really ends. Names aren’t just labels; they’re the first — and sometimes only — mental model a user ever forms.

“Artificial intelligence” ships a theory too: this is a mind. Not a tool, not a process, not a very large spreadsheet; a mind, artificial in origin but a mind nonetheless. Once you hand someone that theory, it’s difficult for them to reason about the system like they might about a calculator. Instead, they start thinking about it more like a person or the intelligent, science fiction machines they’ve seen in movies. That’s anthropomorphism, and it’s not a side effect of how we talk about AI, it’s baked into the noun itself.

Why does this matter? Because Content Designers know that the fastest way to create anxiety is to hand someone a mental model that implies more agency, unpredictability, and capacity for judgment than the system actually has. “Intelligence” does all three at once. It suggests the system is weighing and deciding. It might even suggest the system has needs and wants of its own. None of that is what’s happening under the hood, but the name insists otherwise, and once a mental model is set, it’s brutally hard to unset with a footnote.

The tech industry has renamed the problem before

Content Design has a rule of thumb: when a label creates the wrong mental model, you don’t explain the confusion away, you rename it. The tech industry has actually followed this rule many times. It just didn’t end up applying it to one of its most talked-about terms.

When early computers hit the market, they were called “electronic brains.” That made a basic payroll machine sound like a rival mind. Audiences rejected it. IBM saw the issue and course-corrected. They swapped in the word “computer,” which originally just meant a human clerk doing math by hand. The machine didn’t change. The mental model did: from thinking rival to fast clerk.

The same kind of shift happened with robots. Terms like “automaton” and “mechanical man” suggested a soulless imitation of a person. “Robot,” from a Czech word associated with forced labor, reframed the machine around what it did rather than how closely it resembled a human.

Something similar happened with AI in the 1980s. Early commercial systems were marketed as “expert systems,” but “expert” suggested a level of human-like reasoning and common sense the technology didn’t actually have. When those systems collapsed, much of the underlying technology lived on under less loaded terms. Ideas once associated with “expert systems” and “artificial intelligence” were increasingly described as enterprise software or databases, which are more bland and accurate terms to describe computing tools. The technology sounded less threatening once the language stopped inviting comparisons to human intelligence.

Every fix shares one move: swap a word implying a mind for a word implying a mechanism, and the fear follows the label, not the technology.

So why do we still call it “artificial intelligence,” especially when people have tried to replace it? When the name was introduced in 1955, other researchers suggested less dramatic alternatives, like “automata studies” and “complex information processing,” but those names never caught on. Part of the reason was practical. John McCarthy wanted to distinguish this new field from cybernetics, a competing area of research already associated with Norbert Wiener. “Artificial intelligence” gave McCarthy’s work a distinct identity and helped it stand out to researchers and funders. A more technical name probably wouldn’t have had the same effect.

The pattern happened again. During the funding slowdowns of the 1970s and 1990s (known as the “AI winters”), many researchers strategically avoided the term “artificial intelligence.” They used terms like “informatics” and “knowledge-based systems” instead because “AI” had started to sound toxic and unrealistic.

Later, as the technology improved and attracted more investment, the value of the name changed. “Artificial intelligence” sounded bigger, more ambitious, and more exciting than a technical description of how the systems actually worked. Once the term became useful for attracting attention and money, there was no longer incentive to replace it with something more precise.

The naming failures didn’t stop at the top-level term

Once you start noticing it, a lot of the language around technology seems designed to make machines sound more human. When an AI system gives a false answer, we call it a “hallucination,” a word normally associated with psychosis, or in other words, the human mind. When layers of math adjust numbers called weights, we call the system a “neural network,” which makes it sound more brain-adjacent than spreadsheet-adjacent.

The same thing happens outside AI. “The cloud” makes data centers full of hot servers and high electricity bills sound dreamy and weightless. “Smart” can make devices that collect and process data sound more capable than they are. “Algorithm” can make business decisions sound purely mathematical. And “copilot” suggests a helpful partner rather than software that may eventually take over more of the work itself.

These names aren’t meaningless. They shape how people understand technology. How much they trust it, fear it, or let it make decisions for them. And the people who choose those names often benefit from the way we interpret them.

What this means if you actually do this work

No matter the name, many of my daughter’s concerns would still remain. The environmental costs are real, and the technology is already changing how work gets done across industries. But a more realistic name might change how we think about what these systems are for. Companies might be less eager to talk about replacing people if the technology were framed as a tool for helping people do their work. A name like “knowledge-based systems” would sound less magical, but it might also set more realistic expectations.

The lesson isn’t “rename AI now.” That ship left the harbor around 1955, and no Content Designer alive is winning that fight. The more useful lesson is that naming isn’t decoration added to a product after the fact. A name is often the first piece of UX someone encounters, and one of the most durable. It shapes what people expect, what they trust, and what they fear long after the rest of the product has changed.

If a Content Designer had named AI, we’d be panicking a lot less was originally published in Thumbtack Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

A behind-the-scenes look at how Thumbtack’s content design team turns a 30-minute meeting into a real partnership.

When I started out in the tech industry in another company, I held my first content design office hours session and it was a disaster. Wet behind the ears and eager to be helpful, I walked into what was supposed to be a brief advising session. I walked out with homework.

We know these meetings all too well: In an attempt to be helpful, you offer your expertise; they hand you a stack of unfinished drafts for a project due Friday. You spend two hours reverse-engineering what the drafts were even supposed to do, send back something polished with a thoughtful note, and never hear from them again.

That’s not office hours. That’s an unreasonable Devil Wears Prada assignment Miranda would have handed to one of the Emilys. And some office hours still work this way.

At Thumbtack, they don’t.

Office Hours here is a relationship between the company and the content design team. It’s an ongoing conversation between our internal partners who, for those 30 minutes, are also our customers. As our discipline changes shape and our team takes on more AI prompt engineering and model design, we’re still just as invested in strong content design and strategy. Office Hours at Thumbtack may be a content designer pairing up with a product designer on Claude Design, or working through a prompt evaluation artifact with our engineer and applied science partners. Sometimes we meet with a whole team of product partners looking for content expertise on a specific project. The guestlist may differ from week to week. But one thing remains consistent — as our company evolves, so does the need for content design.

When I started leading this effort, we rebuilt Office Hours around a few core ideas. The first round of feedback we collected made the gap clear: people valued the sessions, but the long wait to get a slot with a content designer and starting from scratch each time made it hard for our colleagues to get help exactly when they needed it. So we changed how we ran things.

Here’s how we make it work:

1. We take time to understand the recurring content themes. We spend a lot of time in Office Hours simply listening to what questions keep coming up and what people expect from our team. This helps us understand how to frame suggestions and where to step in to offer feedback. We listen as colleagues sort out the problem and we come to conclusions together.
2. We help people show up ready to get unstuck, not just get copy. The more context someone brings, the more ground we can cover in 30 minutes. We encourage colleagues to send documents in advance (a draft, a Figma link, a Loom) along with the constraints they’re working within and the edge cases they’re worried about. We also make sure our partners know: it’s not about arriving with a perfectly finished ask and leaving with ready-to-use copy. It’s about arriving prepared to think something through with us.
3. Sometimes we just roll up our sleeves and write strings together. Good old-fashioned pair writing is still important. It’s quick. It’s scrappy. And it’s exactly what some partners need. We show them how to use our content design Figma plugin and what prompts work best when using our Claude skills or customized GPT. We share tools and resources so they don’t feel stuck after the session is over.
4. We consult — we don’t adopt the koala. Our goal is to help partners leave with next steps, options, templates, or a clearer decision, without taking on ongoing ownership ourselves. People come in with a koala on their back, and they leave with the same koala, just hopefully lighter and easier to carry. Every so often, a project comes our way that we realize needs more content attention. Instead of leaving our partners hanging, we take these meatier projects to our content design team and decide who may have the bandwidth to contribute, either as an advisor or an embedded team member.
5. We treat every session as a chance to learn, not just a one-off fix. I revamped our sign-up process to collect more useful context upfront, and built a feedback system to gather data after each session. I also used Claude to help organize the themes, projects, and topics surfacing across sessions. We found that not only were people pleased with the partnership they were getting from Office Hours, but they wanted more! They found the content support they received useful. But more importantly, they appreciated the customer experience we gave them. They left feeling good about their next steps. We listened, we leaned in, and we learned.

We ask partners to come prepared, treat sessions as working time instead of just kickoffs, and pay closer attention to the patterns across sessions. The proof is in the numbers. In our most recent round of feedback, every single respondent rated their experience a 5 out of 5. All of them said they got the feedback they needed, and all of them said they’d return.

This kind of tracking shapes how we work, and how the company runs. The patterns we’ve identified across sessions (where teams get stuck, what they keep asking for, where the demand is heaviest) are becoming real evidence for how our team prioritizes projects. Office Hours isn’t just where we show up for a half hour, pick up a quick project, and go off to our content cave to write copy. It’s helping us see, with real data, where content design is needed most. And just as important, it’s turning one-off sessions into real relationships with the colleagues we work alongside.

Office Hours: How We Show Up for Our Internal Customers was originally published in Thumbtack Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Writing is such a human act. I mean, beyond the obvious — that only humans do it (that we know of! For now!). But even when we know the rules and structures of grammar and often work within them, we also manipulate them to suit our needs. We break rules to make writing sound better, more realistic, more understandable. Knowing when to bend or break rules is an intuition. To me, it’s what gives writing a soul. It’s a little dance between my brain and my pen, and it’s something you can’t teach an LLM. So, to be completely frank, the idea of using LLMs to write made me so nervous at first. I had a hard time accepting that AI use was, whether I liked it or not, going to be a reality of my job.

My first experience grappling with this issue arose out of working closely with our Search Engine Optimization team. Google updated its algorithm guidelines, so websites can’t get ahead using sly, spammy techniques anymore. Gone are the days of dumping a bunch of linked keywords in your site’s footer. Unscrupulous people figured out how to game the algo to boost their rankings, so Google changed the game. Content, if you’ll forgive the terrible joke and worse use of slang, must now E.E.A.T. — that is, it needs to display Experience, Expertise, Authoritativeness, and Trustworthiness. Yes, websites need to be crawlable by bots, but at the end of the day, Google rewards high-quality, authentic, and reliable content that is genuinely useful to humans.

The problem was this: any given website might have hundreds, or even thousands of service pages. These are the pages you land on when you search for something and click a result. If I search for “plumbers in Mystic, CT,” I’ll be able to find a unique Thumbtack URL. Ideally, that will land me on a unique experience, tailored to my specific needs and geography. Now, multiply that by the thousands of possible jobs that I could search for, and any given city or zip code. Then, add to it, the idea of testing different content themes to see what might help people hire a pro faster. It really doesn’t take long before you’re looking at literally one million pieces of content that need to meet Google’s content quality framework and our quality bar .

Realistically, it’s impossible to handcraft that much content and keep it updated over time. At the same time, publishing thin, templated content just to fill space would have undermined E.E.A.T and everything we care about: search performance , brand integrity and user trust. Each page represents someone with a real need and potentially urgent problem who is deciding whether to trust Thumbtack. It’s not just abstract traffic. And the problem is a logistical one: we don’t have enough writers or time to meet that kind of scale. During our team’s first experiment using AI in this way, we generated about 10,000 pieces of content that took 3 writers several months to review.

As a result, we started asking ourselves whether we could build an end-to-end LLM system that handled this responsibly. Not just a text generator, but a system that could generate content at scale. A system that could evaluate content against a set of specific criteria, rewrite anything that didn’t meet the mark, and use learnings from the evaluation and experimentation results to improve the prompt. The goal was to support future content generation, and I’ll be honest, this question made me nervous.

From anxiety to architect

What was left for the writer, if the machine could write? That’s the question that haunted me when we started talking about this end-to-end system. The industry is in the middle of a major change, and no one knows how things will look in five years. And despite owning three different tarot decks, I still can’t predict the future. I can only look at the problem in front of me — a million pieces of content that had to clear a real quality bar, and not nearly enough hands to write them.

So I picked at the one lever I actually had: if I couldn’t out-write the volume problem, maybe I could out-design it. Instead of wondering who I was if I wasn’t the one writing, I started wondering what I actually had to offer a system like this — pattern recognition, editorial judgment, fifteen years of knowing when a sentence is technically fine but somehow still wrong.

If AI was going to carry part of the load, it needed real guardrails. I envisioned a content framework flexible enough to hold up across thousands of pages, tone and constraints spelled out in specific terms to actually operate on and didn’t just “sound right.” This also looked like sentence-length ranges, banned filler phrases, a checklist mapped straight to E.E.A.T. itself, and editorial judgment translated into prompts. Not to mention, evaluation criteria that went past gut feeling and into something we could actually score a page against. We tested outputs, adjusted the prompts, and tested again.

None of that happened in isolation. Rather than reviewing work after the fact, I partnered closely with Applied Science and Engineering to build the system alongside them. We looked at performance data together, and built in loops for revision. My job stopped being “edit thousands of paragraphs” and became “tune the machine that writes the first draft of all of them.” It’s a totally different skill, and one that I didn’t have when we started.

One of the hardest parts for me to grapple with is that teaching a system what good writing looks like means you can’t just rely on feel — you have to name what you mean. I still have a hard time putting into words when something sounds good or feels right. Working with the AI system forced that out of me. I had to break “good” down into decisions specific enough that someone — or something — could repeat them. Doing so made me more precise about tone, more deliberate about structure, and more conscious of the actual tradeoff between “unique” and “scalable” in a way I’d never had to articulate before.

It also made me more strategic. My job shifted away from writing content directly on designs, and turned into designing a system that could solve a business constraint responsibly, without lowering the bar to get there. And slowly, the guardrails started working: pages that used to bounce back from review due to sounding thin or generic were clearing the E.E.A.T. bar on their own, more often, and without a writer’s hands. AI didn’t replace the writer in me, it leveled-up my skills.

The quality question

The quality isn’t perfect. Not yet, and maybe not for a while.

AI output can be solid — sometimes surprisingly so — but it’s not consistently excellent, and it doesn’t reliably catch nuance the way a careful human does. That used to feel disqualifying to me. If it’s not as good as what a good writer would produce by hand, shouldn’t we just wait? Or, at a minimum, should we be so reliant on it?

For better or worse, AI is here, and it’s part of our workflow now. We don’t have the option to ignore it. What it actually gives you, in a way traditional editorial work never could, is speed of iteration. You can ship, measure, adjust the prompt, tighten the structure, add a guardrail, and try again — all in the time it used to take to manually polish one round of drafts.

The quality gap isn’t a wall, it’s a moving target, and it’s one we’re closing a little more with every cycle — because with every cycle, we’re getting sharper too.

Working with the robot

I still care about writing. I love projects where I get to look at designs and think about the actual words on the page, and I never use AI in my personal writing. But I’ve come around to thinking that craft, at scale, isn’t only about the sentence, it’s about the system producing it. Working with AI didn’t make me less of a writer; it turned me into more of a strategist, pushed me into deeper collaboration across teams, and forced me to think past the page and into the process behind it.

My anxieties didn’t vanish overnight, but the more I worked with AI, the more my anxieties changed shape. I went from feeling scared to feeling curious about what I could actually build, and empowered to do it because I have the tools. I stopped worrying about the robot getting smarter, because I realized I didn’t have to compete with it — I could design with it instead.

The Content-at-Scale Conundrum was originally published in Thumbtack Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

This piece was originally published in Life @ Thumbtack.

At Thumbtack, we built a Rolling Research program to scale access to user insights without sacrificing quality. What started in 2024 as a pilot program to increase research capacity, has evolved into a core pillar of our product development insights engine.

In 2024, Nicole Bacchus, our Sr. Director, Research, partnered with research agency, Measuring U, to help Thumbtack pilot a new program to help product builders learn from customers at velocity: Rolling Research. Rolling Research is a lightweight, high-velocity program that enables product teams — especially those without dedicated research support — to get fast, high-quality answers to user questions. Teammates submit a request, we triage projects regularly, and run a quick research project.

The MeasuringU program was a resounding success — it accelerated decision-making and helped teams make smarter decisions at key moments in the product lifecycle. The pilot also proved the appetite was real — product builders want to stay close to users in lightweight ways.

In 2025, Katie Hansen, brought me aboard to bring the program fully in-house, with the goals of increasing the velocity, depth, and impact of our insights. Spoiler: it was another resounding success!

If you’re trying to increase research velocity without sacrificing quality, your team should consider investing in Rolling Research. To help you make that decision, here are some highlights of what makes our program work so well and how we got it off the ground.

Research: from light speed to warp speed

Making the transition to an internal program was straightforward. It started with pointing project-rich product teammates to a Google Form, which collected basic information about their research questions, segments, stimuli, timelines, etc..

To build momentum, we did a roadshow for different departments across Thumbtack to re-introduce exactly how to engage with the program and share how we could help answer their pressing questions.

From then on we’ve been all gas, no brakes! 🚀

The core philosophy & how we work

Our overarching approach is simple: hear we’re needed, show up, help our teams learn, and move on. Lather, rinse, repeat! 💆 🫧

Here are select highlights of how we operate:

• Clear intake, rituals, and scope: We manage intake through a simple Google Form, triage projects every Friday, and keep everyone aligned via a dedicated Slack channel. This initial intake is key to early project definition, and determining if we can take on the project or need to defer. Projects typically take two weeks or less to complete, with new project kickoffs on most Mondays.
• Flexible methodologies: We typically emphasize remote, moderated, in-depth interviews and user tests, but we do all sorts of activities! Depending on the need, we have utilized everything from storyboard testing to design concept testing, card sorts to cognitive walkthroughs, and in-product surveys to micro-diary studies.
• Keep stakeholders informed: To ensure our product teams stay connected to the data without overwhelming their schedules, we offer daily Slack channel share-outs to surface work-in-progress insights. For those with more need to dive into detail, we also share our “superstar sessions,” where we highlight exemplary participants so even the busiest stakeholders can easily dip in and observe representative sessions.
• Flash findings: Instead of heavy, time-consuming decks, our primary output is a “Flash Findings” document featuring an executive tl;dr and direct answers to the core research questions. This document serves as our foundation, and from there additional artifacts are a breeze to build.

Moments we’re proud of from 2025

Rolling Research (RR) has become a decision-making accelerant. By embedding closer to product development, we help teams reduce uncertainty faster and make sharper decisions. A few moments we are especially proud of last year include:

• Protecting user trust in onboarding: We tested a “mock lead” tutorial designed to let new Thumbtack pros practice responding to customers before spending money. RR uncovered a critical risk early: the mock lead looked too real, causing pros to worry they would be charged a lead fee. Because we caught this early, the team was able to immediately pivot to visually distinguishing “training mode” from real opportunities.
• Refining the service page vision: We wanted to understand which pieces of information on a pro’s profile actually built trust for homeowners. RR revealed that homeowners heavily rely on quantifiable metrics and often skim long “about” paragraphs as marketing jargon. More importantly, we uncovered specific information gaps that, if addressed, could meaningfully strengthen homeowners’ trust in the experience. This allowed the team to reorganize the page structure to prioritize upfront availability signals, concrete timelines, and surface those missing pieces of information we identified.
• Identifying barriers to new job types: We wanted to understand what was holding pros back from adopting a new type of job. RR quickly identified that the single largest barrier was that these new jobs had a set price and didn’t allow for negotiation. Pros told us this removed their ability to diagnose unforeseen variables on-site, which acted as a financial deal-breaker. This finding reinforced a core marketplace truth for our product teams: mandatory, rigid workflows erode trust, and we win when our platform amplifies a pro’s capabilities, rather than constraining them.

The results

The data tells a clear story: Rolling Research has become a high-velocity, high-trust insight engine. In the first nine months of running our fully in-house program, we achieved:

• A 75% increase in project volume
• 21 studies across 15 teams
• 94% CSAT score from our stakeholders

If your team is considering a Rolling Research program, we highly recommend it. And if you set this up for your own team, we’d love to compare notes or learn how others are scaling research in similar ways.

Inside Thumbtack’s Rolling Research program: How we built a high-velocity insight engine was originally published in Thumbtack Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

For the Content Design team at Thumbtack, our work heading into 2026 looks very different from what it did a year ago. Our core skills haven’t changed, but how we apply them has.

We’ve moved from writing product content ourselves to primarily designing AI systems that generate it for us — roughly 25 to be more specific, many of which were 0–1 features developed over the course of the whole year.

For our small team of 5, we’ve learned how to navigate a new challenge this kind of scale has introduced. Generating content with AI is easy. Generating content that’s accurate, useful, on-brand, and predictable with AI is not.

Bridging that gap became our focus in 2025. It’s what led us to formalize what we call content engineering.

What we mean by content engineering

Content engineering = content design + prompting strategies + evaluation.

• Content design: understanding users, context, constraints, and voice
• Prompt strategy: shaping model behavior through structure, examples, and language
• Evaluation: defining quality and enforcing it at scale

Like any design process, content engineering isn’t linear. It’s a loop: clarify → design → test → evaluate → adjust → repeat. The key difference from traditional content design is that you’re no longer producing final copy. You’re designing a system that does.

How it’s playing out in practice

Across all of these features, a few lessons have held true:

It all starts with classic content design.
Before writing a prompt, we explore what the ideal content should be the old-fashioned way (in Figma and with users). This content then becomes the examples we feed the model as well as the backbone of our prompt engineering strategy — unlocking strategy around persona, structure, and even complex logic.

Design inputs as carefully as outputs.
As the old adage goes, “garbage in, garbage out.” In other words, great outputs require the right inputs. Identifying ideal content helps surface the data needed to personalize it. This “context engineering” step is critical — and one content designers should be deeply involved in.

Plan for iteration.
Prompts are finicky. What works in one project may fail in another. Examples can outperform written rules — or cause hallucinations. Over time, you learn how to iterate well by recognizing common model failure patterns.

Set a minimum quality bar.
Without a clear quality bar, prompt iteration becomes endless. Conveniently, the bar is hiding in plain sight. We use the ideal content we put together to inform the strategy to develop our evaluation criteria. Then, we hold ourselves accountable to them because the same standards we apply to human-written content apply to AI-generated content as well.

Know where humans matter most.
LLMs struggle with nuance and competing priorities. Strategic judgment — especially balancing user and business needs — has to come from content designers. Models can execute well only when humans have strategised well.

What we’re carrying forward

Across projects, the pattern is clear: ideal content shapes model behavior, evaluation drives quality, and prompts are design artifacts. Content engineering isn’t about writing faster — it’s about building systems that scale responsibly, behave predictably, and meet the same standards we expect from human-written content.

The work is demanding, but the impact is real — and we’re excited to keep improving our practice in 2026.

Content Engineering lessons we’re taking into 2026 was originally published in Thumbtack Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

The rise of generative AI isn’t just reshaping the interfaces we design for. It’s redefining the very nature of our work. As AI becomes more deeply embedded in the products we build, we’re no longer just writing for humans. We’re shaping the systems that generate the words themselves.

This shift is giving rise to a new layer of practice: Content engineering.

If that phrase feels unfamiliar, you’re not alone. But chances are, if you’re a content designer working on AI-powered experiences, you’re already doing it.

So, what is content engineering?

At its core, content engineering is the systems-level practice of designing, structuring, and governing AI-generated content experiences. It draws on everything we already know how to do as content designers — but applies it to dynamic, model-driven systems instead of static surfaces.

This work shows up in a variety of ways, including:

• Designing prompts that guide model behavior in service of product goals
• Structuring modular content frameworks that support AI-generated variation
• Encoding brand, accessibility, and ethical standards directly into outputs
• Reviewing model responses with a lens on tone, accuracy, bias, and risk
• Defining taxonomies, tokens, and structured inputs to drive consistency
• Collaborating with applied scientists to align model training with UX intent

It’s complex, multi-dimensional work — and it’s work that requires content designers. Not because we’re the only ones who can write prompts, but because we’re uniquely equipped to balance language, systems, ethics, and user experience.

Prompt design is only part of the picture

A common misconception is that AI content design begins and ends with prompt writing. But prompts are just one piece of a much bigger system. They’re deeply contextual — shaped by model architecture, user intent, product flows, and more.

Designing an effective prompt isn’t about crafting a perfect sentence. It’s about understanding how the model interprets that sentence, how outputs vary across edge cases, and how to make the entire system more predictable, transparent, and trustworthy.

That’s why reviewing AI-generated content isn’t a final polish or a handoff task. It’s a continuation of the design process. When we evaluate model output, we’re really evaluating how well our system is functioning — how aligned it is with user needs, product strategy, and experience quality.

Without insight into how a prompt was structured or what the intended behavior was, AI content review is guesswork. You’re testing a system without seeing the wiring underneath.

Content engineering in practice

While we might not always use the term “content engineering” in our day-to-day conversations, its presence is already deeply felt across AI-native product design.

It’s the reason why a single paragraph of AI-generated content can take weeks of iteration — because thoughtful prompt tuning, pattern design, and risk mitigation take time.

It’s the work behind the scenes when content designers partner with machine learning teams to shape tone, clarify model confidence, and ensure that AI outputs don’t just function — they communicate.

And it’s the hidden scaffolding we build when we define reusable prompt patterns, create scalable review frameworks, or develop structured vocabularies that help models output more relevant and coherent responses.

These aren’t edge cases. They’re the foundation of how AI-powered experiences are built.

Why this matters

Content engineering isn’t just a trend. It’s a capability. One that every team working with generative AI will need — and one that content designers are uniquely positioned to lead.

Because at the end of the day, generative AI doesn’t eliminate the need for content design. It expands it.

It pushes us to work at a deeper level of abstraction. To think more like system architects. To lead with even more rigor in how we design for clarity, trust, and inclusivity.

It challenges us to treat language not just as output, but as infrastructure.

Looking ahead

As AI continues to reshape our products, content engineering gives us the language to talk about the work we’re already doing — and the space to grow our craft in new directions.

It’s not about leaving content design behind. It’s about building on our foundation to meet the complexity of what’s next.

Evolving content design for the age of AI was originally published in Thumbtack Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Design is stretching in two directions. Some designers are moving closer to strategy, others are building more directly. Both paths are shaping the future of the craft.

I’m a Senior Product Designer at Thumbtack with over a decade of experience across startups and growing tech companies. Most of my time has been spent in embedded teams, where design, product, and engineering work closely to shape and ship products.

What’s stood out most over the years is how much the role of design keeps evolving. The expectations expand, even as the fundamentals stay the same.

Lately, I’ve been thinking about how design is changing, not just in tools but in how we work, what we own, and where we create impact.

At Thumbtack, design has always had room to grow. Recently that has meant deeper involvement in strategic planning, clearer problem definition, and ongoing training around modern tooling and AI. It’s the kind of support that pushes you to reflect.

I don’t think roles are dissolving overnight, or that every company is headed in the same direction. But I’ve noticed something: design is being stretched, reaching in two different directions.

A New Design Landscape

The traditional triangle of product, design, and engineering was built for clarity. Product decided what to build, design figured out how it should work, and engineering made it real.

That setup still works in many places, but it has never been the only model. Apple, for example, has long relied on design-led teams without traditional product managers, where direction emerges through tight collaboration between design and engineering. Elsewhere, design has played a more executional role, shaping the interface after strategy is set.

Those variations have existed for years. What feels new is how AI is amplifying them. It gives designers more autonomy, speeds up workflows, and reduces the need for formal handoffs.

Designers today can prototype, test, and even build experiences faster than ever. Some are designing and shipping. Others are shaping strategy and setting product direction.

Two modes of design are becoming more visible.

Strategic Operators define what should exist and why.
Creative Builders move quickly from idea to prototype to launch, often without a traditional handoff.

These aren’t job titles; they’re patterns. Most designers shift between both, but the lines are becoming clearer as AI reshapes what is possible.

“Designers today can prototype, test, and even build experiences faster than ever.”

Creative Builders: Designers Moving Toward Execution

Creative Builders take ideas from concept to implementation. They don’t just imagine what the product should be; they make it real. That might mean creating high-fidelity prototypes, stitching together no-code tools, or using AI to generate production-ready code.

The key is that they’re not waiting for a handoff. They’re working in the tools, inside the systems, often alongside engineering to push ideas forward.

At Intercom, for example, designers are expected to ship. They use AI-assisted tools and internal systems to build features and iterate quickly. In one case, the design team rebuilt Intercom’s public website almost entirely on their own, with minimal engineering support. They moved from idea to launch using AI and internal tooling to prototype and deliver the final result.

Other teams, like those at Notion and Linear, work this way too: small, fast-moving, and collaborative. Clear ownership often matters more than strict role definitions. AI accelerates that by helping designers generate layout-ready code, explore functional prototypes, and close the gap between design and execution.

This approach favors momentum. A working prototype invites sharper feedback. A live demo answers questions slides never could. When designers can build what they imagine, the product becomes tangible for everyone else.

Design, in this model, is not a step in the process. It is a thread that runs from idea to shipped experience.

A working prototype invites sharper feedback. A live demo answers questions slides never could.

Strategic Operators: Designers Moving Toward Strategy

Strategic Operators move upstream into problem framing, product vision, and long-term planning. Their work starts before any interface is sketched and often before a roadmap exists.

Julie Zhuo has shared about this shift. At her current startup, she is not hiring traditional product managers. She is hiring builders, people who can make things and define direction. That includes designers.

In her words, design is “creative, open-ended problem-solving.” It is not just visual execution. It is about asking the right questions, interpreting data, and shaping how a product evolves.

Strategic Operators take that to heart. They work closely with data, research, and stakeholders to define problems and outcomes, not just interfaces.

That is already happening at Thumbtack, where designers are contributing to strategic planning and product direction, bringing the same synthesis and storytelling skills they use in interface design to higher-level decisions.

Where This Shows Up at Thumbtack

Some of the most impactful design work here lately has had little to do with screens. It has been about creating clarity, shaping strategy, setting objectives, and charting the path to get there.

At the same time, we’re leveling up our tools and workflows. Ongoing design training and AI exploration make it easier to test ideas quickly, build sharper prototypes, and communicate with higher fidelity.

Together, these shifts in strategy and execution are opening space for designers to work differently.

The Space in Between

If designers can both define what to build and build it, what happens to the space in between?

That is where a lot of design has historically lived: interpreting requirements, making mocks, polishing for handoffs. That work still matters, but it may start to feel less central as the edges expand.

Some of the more mechanical parts of the job, like assembling UI for someone else’s roadmap, may slowly get automated or at least become faster and easier.

This is not about declaring anything over. But something is shifting, and it is worth noticing.

The most important thing may not be choosing one path, but staying curious about where design creates the most value.

A Small Example of the Shift

Writing this piece reflected that change.

I started with a loose idea about how design roles might be evolving, something I had not fully articulated. Working through it with an AI tool helped me test structure, refine ideas, and turn early thinking into something more concrete.

That is the shift in miniature. The tool did not replace the thinking; it extended it. It helped close the gap between a rough concept and a finished piece.

We are seeing the same thing in design: tools that make it easier to move from strategy to execution, from thought to artifact. The boundaries are shifting, and our ability to move through the process is expanding.

Design Is Shifting. Where Do We Go From Here?

Some designers are stepping further into strategy. Others are building and shipping more directly. Most are doing a bit of both, depending on the project, the team, and the tools.

What seems clear is that the role is changing. The most important thing may not be choosing one path, but staying curious about where design creates the most value and how we keep growing with it.

How is this showing up at your company? I would love to hear what you are seeing.

Fede is a product designer at Thumbtack exploring how design, technology, and strategy intersect.

Creative Builders, Strategic Operators, and the Future of Design was originally published in Thumbtack Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’ve all been there: a list of exciting product ideas, limited time, and even more limited experiment slots. In an ideal world, we’d A/B test every idea to see what really works. But the reality is that we don’t have the bandwidth to run every experiment we’d like to. This is where research can be our secret weapon.

If you think of A/B tests as the final proving ground, research can help us narrow down the contenders before we even step onto the field. By using different research methods, we can identify the most promising bets, understand where to focus our efforts, and reduce the risk of spending precious time and resources on ideas that might fall flat.

While foundational and tactical research may be familiar tools for understanding user needs and refining designs, those aren’t the only ways research can help. There are additional approaches specifically suited for prioritizing product ideas when A/B tests aren’t an option.

Let’s explore the research toolkit that goes beyond A/B tests, exploring methods that can help us prioritize our bets efficiently and confidently.

Survey experiments

What it is: Emailed surveys that incorporate controlled experiments within the survey itself.

How it helps: We can gauge reactions to different ideas or messaging and causally identify which concepts show the most promise, all without building a thing. They are great for narrowing down large lists of potential bets and gathering quantitative data quickly.

Example: Randomly assigning respondents to different concepts and comparing their responses on numeric scales.

Pros: Provides quantitative, causal data; can test multiple ideas in parallel; can garner insights from large, diverse user groups.

Cons: Designing robust survey experiments requires careful planning and expertise; limited to reactions to the presented concepts.

Concept testing

What it is: Evaluating early-stage ideas or prototypes with users to understand their reactions, expectations, and potential barriers.

How it helps: We can quickly rule out ideas that don’t resonate or refine concepts based on early feedback before investing in development.

Example: Showing users a storyboard or low-fidelity prototype and gathering qualitative feedback on their understanding and interest.

Pros: Helps rule out unpromising ideas early; provides actionable feedback to refine concepts; can identify potential barriers to adoption or usability issues.

Cons: Limited scalability.

Priority testing

What it is: A category of methods where users rate, rank, or sort different ideas or features based on importance, preference, or desirability. This could be done qualitatively or quantitatively.

How it helps: By understanding which ideas resonate most with our users, we can quickly identify the bets that are worth exploring further.

Examples: Card sorting exercises where users rank feature ideas based on what they find most valuable and MaxDiff analysis where users indicate their most and least preferred options via survey.

Pros: Flexibility to do qualitatively or quantitatively; provides clear prioritization signals based on user preferences; can test a large number of ideas.

Cons: Results are dependent on the quality of the options presented; users may not have a clear understanding of what they truly need; quantitative approaches require specialized statistical expertise.

Participatory design

What it is: A collaborative approach where users co-create solutions with the team.

How it helps: By involving users directly in the design process, we can identify which ideas align most with their needs and ensure we’re solving the right problems.

Example: Workshops where users brainstorm and sketch potential solutions.

Pros: Encourages innovation through collaboration; provides rich, qualitative data.

Cons: More time intensive than other methods.

These research methods empower us to prioritize product bets with confidence and clarity.

Beyond A/B tests: Using research to prioritize product bets was originally published in Thumbtack Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

This year, you’ll notice an exciting change in Thumbtack’s branding — we’re introducing a new font! Thumbtack’s brand team saw an opportunity to create a unique, custom font that would be exclusive to our brand. To bring this vision to life, we partnered with &Walsh, a branding agency.

Our updated font, Thumbtack Rise, blends clean, geometric shapes with subtle, humanistic touches, creating a look that’s both confident and approachable. Compared to its predecessor, Rise features small adjustments, like a gentle curl in the “y” and a taper in the “a,” making it feel warmer and more friendly — like a knowledgeable neighbor. This is the space we want to be in for the Thumbtack brand.

Rise will also feature additional font weights, giving us a versatile toolkit designed not just for today’s Thumbtack, but for wherever our brand may go in the next 5, 10 or even 15 years. With five distinct weights — ranging from light to heavy — Rise offers the flexibility we need for the future.

We’re excited about this update! Rise is a thoughtful visual refresh and most importantly ours for years to come.

Introducing our new font, Thumbtack Rise was originally published in Thumbtack Design on Medium, where people are continuing the conversation by highlighting and responding to this story.