About the Author:
Peter Deltondo is a Product Designer turned Product Founder who spent the last decade leading teams, Co-Founding Heyo, a design and development agency, and Co-Founding products, including Eventrise and Keyvo. The list of clients he’s worked with includes Figma, Adobe, Discord, Facebook, Merck, and Toyota. In his free time, he can be found in a river fly fishing or spending time with his family in the great outdoors.

Most projects that go wrong went wrong in the first budget conversation, and usually because everyone in the room was too optimistic. The budget was too low to get things done right, but the client hoped it would stretch, and a well-meaning product designer or agency hoped they could figure out a way to make it work. In the end, they couldn’t.

I believe the budget conversation is the first piece of design work on any project. Get it right and the project is set up for success. Get it wrong and no amount of talent or optimism can fix things.

I tell clients our rates before I ask for their budget

If I ask a client for their budget and then float a number back, how do they know I didn’t just anchor to whatever they said? They don’t. And that suspicion, even when it is wrong, poisons the relationship before a single screen gets designed. Every future conversation about scope now has a little voice in it asking whether the agency is optimizing for the client and the project, or for the paycheck.

So after I learn about their project needs, I go first. Here is what we would charge to accomplish this project, here is the scope that covers, here is how many designers and/or developers it takes and how long is needed to get this work done. Most importantly, it’s a realistic number that we fully believe is achievable, not a pipe dream best case scenario. Cautiously realistic. The number we would actually bet on.

I’ve had many clients tell me that was the moment they decided to move forward. Not the portfolio, not the case studies. The moment they realized we were not playing games with them.

People talk about pricing as a sales problem. It’s a trust problem, and trust is what actually closes.

I’m not a fan of value-based pricing

I know that’s a hot take in agency circles, but here’s how we think about it. We value our work at a weekly rate. It’s a premium rate for premium quality work. The only question is how many weeks it takes to successfully complete the work at our desired level of excellence. We can explain our reasoning for our time and budget, and it has nothing to do with how big the client is or how important the project or outcome is to them. There’s a tried and true formula to it, not a made up “I think I can get the client to shell out this much.”

A client can check our math. It checks out.

What that trust is actually worth

I’ll never forget when a longtime client of ours came to us with a project that should have been started weeks prior. If it got started ASAP, it still had a chance. Their back was against the wall, and it was a good sized project with lots of work to do. We made clear where our concerns and risks were with the scope based on the time available, and we were realistic with what could get done. We quoted around $400k. We won the project.

What they said next was the most important part, and I think one of the reasons why we still work with this client today: “Everyone else knew how desperate we were and tried to take advantage of us. The next lowest bid we got was $2M. In no world is this a $2M project. Everyone here knows that.”

Then they told us why they keep coming back, and it wasn’t just the work we do. It was that we were honest with them, that they could count on us to be a true partner, and that we never tried to take advantage of them. That’s the reputation that has their teams asking to work with us again and again. I can assure you, we’ve done way more work over the years with this client than anything we would have gained by value pricing them on that one project.

Most of our clients here at Heyo are long term or repeat customers. That trust has to be earned from the first sales call, and the budget conversation is where it starts.

The budget is the brief

The beauty of quoting the work and placing the budget alongside it is that any change in the client’s budget changes the scope of the project. We can’t magically get twice as much done at the same budget, but we can focus on a smaller scope of work with less time and budget. Sometimes it’s our job to help the client figure out how to get the most out of less. The line we won’t cross is cutting so far that less no longer gets them anywhere. If a client sees a return on the work, big budget or small, they come back. That’s the easiest way we’ve found to earn repeat clients over the years.

Some of the questions we might ask to help gain focus and clarity on the right scope for them include:

• What has to be true on launch day for this to count as a win? Not the full vision, the launch day version.
• If we could solve only one problem for your customers, which one would actually move the business forward?
• Which of these features are here because a competitor has them, and which are here because a customer asked for them?
• What could ship in a second phase without anyone noticing it was missing on day one?

The answers reorder the scope almost every time. A company came to us a while back wanting a full product redesign: new UI, new flows, the whole thing. Before we touched a screen we spent time on the actual problem, and the problem was that most users were dropping off in their first session, long before they ever reached the flows we were being asked to rebuild. The interface wasn’t the issue. Onboarding was. People weren’t sticking around long enough to see the screens the client wanted redesigned.

So we told them to pump the brakes on the redesign. Fix onboarding first. Observe, learn, adapt. Later on we continued in a second phase to revamp the product based on what we learned.

That is an uncomfortable thing to say to someone who walked in ready to pay for something bigger. But it cost them less, it mattered more, and it is the reason they came back to work with us again.

Quick and right are not opposites. Quick and cheap are.

There is real value in getting to market fast, and I don’t want to pretend otherwise. Every month a product isn’t live is a month of customer feedback you don’t have and revenue you didn’t collect. Speed matters, and any agency that treats “we need this soon” as a red flag has forgotten what it is like to run a business.

The problem is that “quick” almost always arrives bundled with “cheap,” and those are different asks. A small scope built properly can be quick. A full scope built halfway can’t, because the half you skipped is the half that breaks the first time real users show up. It is the auth flow nobody tested, the edge case nobody designed, the database that was fine at a hundred users and falls over at ten thousand.

The honest version of speed is a smaller, finished thing. Not a bigger, unfinished one. When a client tells us they need to be live in eight weeks, our first question isn’t whether we can do it. It is what the eight-week version of this product looks like, and whether that version is worth launching. Usually it is, and usually it is smaller than what they came in with.

Sometimes the answer is no

This is the part agencies don’t like to talk about.

If a budget can’t produce a result that changes anything for the client, taking the project anyway isn’t generosity. The client spends the money, gets something that doesn’t move the needle, and the main thing they learn is that hiring an agency was a bad bet. You didn’t help them. You just found a polite way to take their money.

So we say no to work we can’t move the needle on. That includes budgets that are too low for the outcome the client actually needs, and it includes projects where the client wants a thing built that we think is the wrong thing to build. Both are hard conversations. Both are cheaper than the alternative.

There are two exceptions we take seriously.

The first is a smaller first project. When the full thing is out of reach today, we will often propose a narrower engagement that proves the fit and solves one real problem. If it works, it earns the second project. If it doesn’t, everyone found out for a fraction of the cost.

The second is portfolio work. Sometimes a project is in a space we want to be in, or with a team we want to work with, and the budget is below where we would normally go. We will take that work. But we take it as a business decision, priced deliberately, with everyone on our side knowing why we said yes. What we won’t do is take it at a discount and quietly resent it, or take it and cut corners to make the number work. The client should know which kind of yes they are getting.

Redoing it is the most expensive version of the project

This is the pitfall from the top of the article, the too-low budget everyone hoped would work out. Here’s the math on it.

When a project has to be rebuilt, you pay for the work twice. That part is obvious. What is less obvious is everything else not on the invoice. You pay for the months between the first version and the second, when the product was live and not working. You pay in the users who tried the first version and are not coming back for the second, because people don’t give products many chances. You pay in your own team’s morale, because nobody wants to rebuild something they suspected was going to break the first time.

This is the whole reason we describe Heyo as the crew that builds your brand, product, and website right the first time. It isn’t a slogan about perfectionism. It is a statement about which version of the project is actually cheaper and leads clients to the best chance of success for their brand or product. The answer is almost never the one that skipped steps to hit a number.

The cheapest project is the one you only have to build once.

Realistic is a two-way street

Being realistic about budget isn’t only the agency’s job.

Our side of it is telling clients plainly what their number buys, even when the honest answer is smaller than what they walked in hoping to pay for. It is saying no when no is the right answer. It is putting the second phase in the conversation on day one so nobody tries to cram it into the first.

The client’s side is bringing an honest number, an honest deadline, and a willingness to hear what those two things can produce together. The clients we do our best work for aren’t the ones with the biggest budgets. They are the ones who told us the real number early and let us design around it.

Both halves of that are rarer than they should be. When they show up together, the project usually works.

The number does not change the work

Here is what I keep coming back to after all these years.

The budget was never the problem. Small and large budgets have produced work we are proud of and helped our clients succeed and grow. What decides it is whether both sides knew, before anything started, exactly what the number would buy and what it would not.

Say the number first. Treat it like a brief. Build the smaller thing properly instead of the bigger thing halfway. Say no when you can’t help. And put the second project on the table while you are still scoping the first.

That isn’t a pricing strategy. There is no “slick” sales or gift of gab. Just be real and honest. It is how you end up being the agency a client calls back.

Have a project you want to chat about? Let’s chat.

About the Author:
Anthony Dutcher is Founding Partner at Vix Media Group, a Denver-based agency working across healthcare, technology and media. His team is deliberately split between agency and in-house backgrounds and runs its own infrastructure, so it has sat on both sides of the brief. He believes research should decide the design, not decorate it.

A behavioral-health website we refreshed did not need a dramatic new look. It needed a better way for people to find the right care.

The visible changes were modest. The structural work was not: we added 80-plus content pages across services, locations, conditions, and outcomes evidence. We simplified the navigation and standardized calls to action.

More content. Less navigation friction. That is a more interesting design problem than choosing a new hero image.

At Vix Media Group, I want every redesign to protect what already brings people in and make the next step clearer. Today, that means thinking about Google, AI-assisted discovery, and the person who still has to decide whether to contact the business.

1. Give the redesign a business brief, not just a visual brief.

The behavioral-health project is a useful distinction between a visual refresh and a structural rebuild. They are not the same scope, and the screenshot does not tell the whole story.

Expanding the content library while simplifying navigation addresses two different needs:

• Search visitors need a page that matches a specific question.
• Website visitors need a clear route through the business, not an inventory of every page it publishes.

For a care provider, those questions can start with a condition, a treatment, or a location. Putting all three into one general page makes the visitor do the sorting. Putting every answer in the main menu creates a different problem.

The job is to give useful answers their own destinations, then organize those destinations into a site people can understand. Our SEO strategy and design decisions have to work from the same map.

Does adding more pages improve SEO?

Not by itself. A page earns its place when it answers a distinct need with useful information. A location name swapped into otherwise identical copy is not the same thing as meaningful coverage. The 80-plus pages describe the scope of this project, not a target for every business.

2. Simplify the interface without thinning the information.

A cleaner interface should make the content easier to use, not make the business harder to understand. In the healthcare refresh, simplified navigation sat above an expanded content library. Standardized calls to action provided a more consistent next step.

The live site makes that distinction concrete: visitors can explore services and conditions, check insurance information, and find provider credentials without treating the homepage as the entire website.

This is where good web designers earn their place. A heading identifies the subject. Spacing separates an answer from the next question. A repeated button treatment makes the next action recognizable. The page can be calm without being empty.

One change was more revealing than a new color palette: we corrected a provider’s professional title across key pages and added a credentialed bio to a service page. Accuracy is part of the experience. A beautiful layout cannot compensate for describing the professional incorrectly.

Where should FAQs go?

Put an answer beside the decision it supports. Coverage questions belong near insurance information. A question about the first appointment belongs near the inquiry step. Do not bury every useful answer in an accordion at the bottom just because the template has an FAQ section.

3. Preserve the route from search to the right page.

A redesign starts with an inventory of existing value. Before changing a URL, I want to know what searches reach it, what relevant links point to it, and what visitors do after landing there.

The same logic applies whether the project adds a substantial content library or mainly updates its presentation. Keep a useful address unless there is a good reason to change it. When it must move, map it to the closest relevant replacement, not automatically to the homepage.

My launch checks, which a web developer should be able to walk through with you, follow the visitor’s route:

• Confirm that important pages load and can be indexed.
• Test permanent redirects and update internal links to the final destinations.
• Check canonical URLs, sitemap entries, and production indexing settings.
• Submit a test inquiry and confirm that the team receives it.
• Verify that analytics records the intended action, not just a pageview.

Can a relaunch avoid every traffic dip?

No agency can promise that. Google’s site-move guidance anticipates ranking fluctuations as changed URLs are recrawled and reindexed. A launch needs a baseline and ongoing monitoring, not a promise that the graph will never move.

4. Separate useful demand from impressive-looking traffic.

The number to protect is not always the largest number in the report. A popular news story and a service page that produces inquiries do different jobs.

I have seen this tension in our legal-sector work. A major redesign did not restore the site’s previous traffic level, and a history of high-volume news publishing complicated the picture. A new interface was not, by itself, a recovery strategy.

That experience changes the questions I ask before a refresh. Which page types lost visibility? Which visitors had a reason to hire the business? What changed in publishing, tracking, or search demand around the launch?

The healthcare project’s content expansion and standardized calls to action belong together for exactly this reason. Discovery needs a destination, and that destination needs a useful next step. More pages and more visits are not the finish line.

5. Make room for AI discovery without abandoning the fundamentals.

AI assistants are already a measurable entry point into websites we manage. Across a commercial building-products portfolio, we counted 757 sessions attributed to ChatGPT in GA4 reporting from August 30 through September 28, 2026. Of those, 449 were engaged sessions: visits that met GA4’s criteria for time spent, pages viewed, or a key event.

The behavioral-health site recorded 15 sessions from identifiable AI sources in the same 30-day window. That smaller number matters: the opportunity exists, but its scale varies by business.

These are referral observations, not proof that a redesign caused the visits or that every recorded action became a qualified lead. The practical response is to measure the channel and examine what visitors find when they arrive.

Does AI search require a separate kind of website?

My starting point is a site that explains the business exceptionally well. Clear services, accurate credentials, useful answers, connected pages, and accessible content help the reader regardless of the source of the visit.

For Google’s own AI features, Google says the existing SEO fundamentals still apply. That is not a universal recipe for every assistant. It is a useful correction to the idea that AI discovery requires abandoning the fundamentals that make a website useful.

6. Judge the relaunch by the journey it supports

After launch, put search visibility, landing-page traffic, and verified inquiries beside one another. Break them down by source and page purpose. That is why I see website development as more than getting pages live: the inquiry still has to reach the right team.

For the behavioral-health refresh, the story is not a dramatic aesthetic reinvention. It is an expanded content library, simpler navigation, clearer professional information, and a more consistent path to contact. Those decisions shape how the site works long after the homepage reveal.

A redesign should make the business easier to understand and easier to reach. The best proof is not how different the homepage looks.

Before your next relaunch, can you trace a real customer question from the search result to the right answer and a working next step?

About the Author:
Nicolas Solerieu is a product and brand designer at Expo, working across product, web, and brand identity. Previously at GitHub and Opendoor, he’s interested in software, the web, and the strange craft of arranging rectangles for a living.

You can’t one-shot an app. The capabilities are on the table, and mature frameworks and skilled LLMs are within reach. Chances are you’ve used vibe-coded software, and noticed differences. The obvious flaws are disappearing. What remains is subtler: the gap between an AI-generated app that works and one that feels considered.

1. Build a Brand System for Your AI-Generated App

Good product design blurs the edges between brand and product. Ask an LLM, even in plan mode, and it will improvise a branding kit to suit its own needs. Even in tools like Claude Design, where you can provide a base kit, it will still create brand artifacts of its own. Illustration should be consistent, and colors and layout should create a visual continuity from marketing to product, guiding users along the way.

The various touchpoints require different fidelity. Marketing is usually higher fidelity while products tend to be more minimal and rely on color and icons alone. Infusing a product with personality and a distinct style is almost an art. It requires care, attention, and taste: human qualities that can only be amplified, not outsourced.

A brand is also a living entity that flexes beyond the system an AI can understand: employee swag, micro events, an internal sports team, fan art. These are where a product’s personality shows up in ways no brand kit specifies. Think of a brand as the set of artifacts that breathes life into your product. A simple motto is a good way to keep this in mind: “small screens, big moments.”

2. Replace Default Icons and Generic AI Illustrations

Most LLMs pull icons out of their preferred library, or invent them with SVG and CSS. Without specific direction, the result is often generic. 90% of the apps I saw use Lucide icons. It’s solid and covers most cases, but at this scale, it’s becoming the obvious default. You can do better and easily. The same goes for illustration. Certain styles and obvious quality flaws can erode trust quickly.

3. Use Purposeful, Restrained Animation in Your App UI

LLMs greatly ease the production of animation. They tend to go hard on the same attributes since CSS and SVG make them most accessible, and shaders are also more prominent nowadays. The downside is that interfaces can accumulate motion before anyone has asked for it. It happens to me all the time with all my frontend design skills loaded up by default. Animation is rarely improved by quantity. More often than not, restraint and purpose are needed on the human side to improve the quality of outcomes.

4. Test on Real Devices to Make Your Mobile App Feel Native

You may have noticed a strong enthusiasm for products that “feel native.” This feeling often boils down to performance and familiarity. Design is the experience, and ease and speed are a big part of it. Only a human can truly feel that quality, so test, test and test again. Your firsthand experience with each ecosystem matters.

Simulators help here, too. When an agent can launch your app in a simulator, tap through flows, and test what it built, a typically painful part of the process becomes visual and collaborative. You can watch it work, spot what feels off, and steer it in real time. It speeds up the loop, but it doesn’t replace the device in your hand, so keep testing on real hardware before you call it done.

5. Enforce Design System Consistency and Visual Hierarchy

All of the above is well and good, but what often betrays a UX is inconsistency across the whole UI. LLMs are getting better at sticking to a design system, but as anyone who has worked in this industry knows, having a design system guarantees nothing. The wrong component or primitive still ends up in the wrong place. Systems are flexible, and LLMs will be only as flawed as humans.

That’s why the visual basics still need a human eye. LLMs are getting better at checking them, but human taste remains the best judge. Great visual design guides the eye so information feels effortless to digest. Contrast and visual hierarchy make the most important details pop first. Alignment and proximity keep related pieces grouped so the layout feels orderly rather than chaotic. Whitespace gives elements room to breathe, creating a balanced design that feels clean, clear, and intentional.

6. Plan Migrations and Involve Users and Partners Before You Prompt

Design sits at the intersection of operations, engineering, marketing, and infrastructure. Great design is often the direct product of a purposeful blend of those priorities, and that’s hard to convey to LLMs, which either wait for precise instruction or take (sometimes wild) guesses. 

Some scenarios, like migrations, are more straightforward. Others require more planning and handholding. Porting over your web app to mobile? Going native? These can seem like perfect tasks for AI but often result in many edge cases. Careful review via simulators and platform knowledge goes a long way. It’s never just a design matter. I’d encourage you to think about the contingencies and holistic drivers.

The same goes for the people involved. You might have heard “don’t ship your org chart.” While a great app is a set of features, UX is the sum of all things, too many things to truly list in one blog post. Points of friction, and human shortcomings often materialize in the experience. Talking to your users, and your relationships with project partners and vendors, are an invisible yet obvious part of the design process that LLMs can’t fully replace. Sometimes they even introduce a new kind of friction.

7. Design for Error States, Empty States, and Accessibility, Not Just the Happy Path

The modern product designer is not someone who starts from a blank canvas but an “Editor-in-Chief” who curates, prunes, and directs AI outputs. More like a webmaster of the 2000s than a 2016 product designer. Steering and QC is more important than ever to avoid the “Happy Path” Trap: LLMs excel at ideal user flows, but product design happens in the margins. AI frequently ignores error states, zero-data screens, dynamic text wrapping, role-based views, focus & accessibility requirements, loading indicators, and all too often, container alignment. Brand remains the wild west, and it should. That’s where the beautiful complexity of design shows.

Polish is when persistence and taste meet the craft of design. AI elevates the floor so anyone can build software, and human craft is what raises the ceiling. Since tools are becoming generalists, perhaps designers need to become generalists (again) too. 

About the Authors:
Garik Avetisyan, Davit Gabrielyan, and Anastasia Saroka are co-founders of Flexy Global, a design and development partner for startups and global enterprises. Garik built and successfully exited a consumer app used by millions. Davit brings 15 years of experience leading complex projects and operations at international companies including Orange (France Telecom) and Coca-Cola Hellenic. Anastasia, Design Director at Flexy Global, brings experience designing products for large corporations and startups in the fitness industry. Together, they explore how better design systems and development practices can help teams build complex technology more clearly and efficiently.

On a recent enterprise software project, we were working with a Figma file that needed to support both traditional developer handoff and AI-assisted development. One section alone contained dozens of screens documenting a single part of the product.

Each screen made sense on its own. The difficulty was understanding how they belonged together.

For the designers and developers who had worked on the project for months, much of that context was already familiar. We knew which screens represented the starting point, what action caused each change, which states were alternatives, and which details were still under discussion.

A coding agent coming to the file had none of that background. An individual screen did not provide enough context to explain the complete behavior, while the full canvas introduced too much unrelated information. We needed a way to organize the relevant frames, states, and decisions around a single interaction so they could be understood and used more effectively in AI-assisted development. That need became the basis of our Box Design System.

What is the Box Design System?

The Box Design System is our method for organizing complex product behavior into bounded sections of the Figma canvas. Each box contains the screens, states, transitions, annotations, and implementation context needed to understand one part of the product. This makes the file easier for people to navigate while also preparing its structure for AI-assisted development.

In the enterprise platform we were designing, navigation alone included several connected behaviors. Users could interact with a floating bar, select assets, explore the map directly, or move through a hierarchy. All of these actions occurred within the same broader interface, but they did not belong to the same flows.

Placing every screen in one large sequence would have made the file look complete while leaving its logic ambiguous. Instead, we grouped related states into separate boxes such as “Floating Bar,” “Select Assets,” “Direct Map Exploration,” and “Hierarchy.” Each box represented one coherent part of the experience.

At first, this was a way to make a complicated canvas easier for people to navigate. As AI agents became part of the development workflow, the boxes gained another purpose: they created clearer units of context for implementation.

Here are four principles that shaped the system.

1. Organize boxes around behavior, not pages

A page is a visual container. It is not always a useful development boundary.

One page may contain several independent interactions. A single interaction may also extend across panels, overlays, menus, and several screen states.

In our project, selecting an asset and exploring the map took place within the same primary interface. Visually, the screens shared most of their structure. Functionally, however, they represented different behaviors.

Treating them as one group would require a developer or agent to determine which changes belonged to asset selection and which belonged to map exploration. That distinction was obvious to the team because we had discussed it repeatedly. It was not necessarily visible in the pixels.

We therefore organized the boxes as a hierarchy rather than treating every box as an equal unit. The system has three levels:

• Feature boxes represent a complete product capability, such as Navigation.
• Flow boxes sit inside the feature box and separate interactions such as “Select Assets” and “Direct Map Exploration.”
• Screen-state boxes sit inside each flow and name the specific action or state shown on every screen.

This structure allows someone to move from the broader feature to an individual flow and then to the exact screen behavior without losing the relationship between them. It also means that an implementation task can be scoped around the behavior the team needs to build, rather than every element visible on the page.

2. Make each box understandable on its own

A useful box should not require a guided tour from the designer who created it.

Someone opening the file should be able to understand what the interaction does, where it begins, and what changes as the user moves through it.

That does not mean duplicating every piece of product documentation inside Figma. It means including enough context to remove the most consequential ambiguity.

Depending on the feature, a box may contain:

• The default or entry state
• The action available to the user
• The resulting state
• Expanded and collapsed variations
• Selected, disabled, empty, loading, or error states
• Short notes explaining behavior that cannot be understood visually
• References to existing components or patterns

This self-contained structure matters for human teams, especially when people join a project late or return to a feature after several weeks. It matters even more for coding agents.

An agent does not have the memory of the workshop where the interaction was discussed. It does not know which Slack message changed the requirement or which visual difference was intentional. It can only work with the context it is given.

If critical information sits somewhere else on the canvas, remains buried in a comment thread, or exists only in the team’s memory, the agent must infer what is missing.

And inference is where avoidable mistakes begin.

3. Make interactions and transitions visible

Individual screens show different interface states, but they do not always explain how the user moves between them.

In our design files, we use simple arrows to connect an interaction with the screen or state it produces. If clicking a button opens a sidebar, we connect that action to the designed sidebar state. If an interaction takes the user to another screen, the arrow shows exactly where they will arrive.

Not every interaction needs this treatment. Adding arrows to simple or obvious actions can create unnecessary visual noise. They become particularly useful when one screen contains several possible interactions, each leading to a different state or part of the flow.

For someone who has worked on the product for months, these relationships may already feel obvious. Developers and AI agents do not necessarily have that context. Without a visible connection, an agent may recognize all the individual screens but still misunderstand which action produces which result.

Combined with the box hierarchy, these connections make both the structure and sequence of the experience easier to follow. The boxes show which screens belong to the same feature and flow, while the arrows explain how users move between them. It is a simple practice, but it reduces how much developers and agents need to infer from the designs.

4. Give the AI agent a bounded unit of context

AI coding tools can now access much more than a screenshot. When connected through tools such as the Figma MCP server, an agent can retrieve structured design information, visual references, variables, components, and layout data from a selected part of a file. However, in AI-assisted development, access to more information does not automatically lead to a better understanding of what needs to be built.

An isolated frame may leave out the surrounding states required to understand a behavior. At the other extreme, a large page or full canvas may introduce unrelated screens, unresolved concepts, and several versions of the same feature. The Box Design System creates a practical middle layer between these two extremes.

Instead of asking an agent to “build this page,” a developer can direct it toward a bounded interaction containing the relevant states, transitions, and supporting context. This gives the agent enough information to understand the intended behavior without requiring it to interpret the entire product.

The boundary of a box does not need to match a single code component. Some boxes may translate into one component, while others may involve several components and application states. The box is there to define the product behavior being implemented, not to dictate the final code architecture.

The quality of the generated code still depends on the codebase, prompts, design-system implementation, and the agent’s access to existing components. Figma also recommends semantic naming, variables, Auto Layout, reusable components, annotations, and Code Connect to improve consistency. The boxes complement this infrastructure by organizing those elements into a coherent piece of product behavior that the agent can understand and act on.

What boxes cannot solve

A clean Figma canvas cannot compensate for an undefined product.

If the team has not decided how an interaction should behave, placing its screens inside a box will not resolve the underlying uncertainty. It may simply make that uncertainty easier to see.

That is still valuable.

When related states are placed together, inconsistencies become more visible. The team may discover two competing versions of the same behavior, an exception with no recovery path, or a state that was discussed but never designed.

Boxes also do not replace the platform’s design system. While the main design file uses boxes to organize screens, flows, and product behavior, the design system lives in a separate Figma file containing the shared components, variants, and variables used across those designs.

The design system does not need to follow a box-design hierarchy, but it should be structured and detailed enough for agents to understand exactly what they need and where to find it in the file. Clear naming, logical grouping, and consistent component structures help both developers and AI agents find and reuse the correct elements. Without that structure and the corresponding code, an agent may understand the intended behavior while still selecting the wrong component or creating unnecessary one-off elements.

The box defines the scope and behavior. The design system defines how the interface should be constructed. The codebase defines how it must function in production.

Why Figma file structure now matters for AI-assisted development

For years, design-file organization was often treated as an internal concern. A tidy file was easier to navigate, easier to hand off, and kinder to the next designer who had to work in it.

That is no longer the full story.

As design files become direct inputs to AI-assisted development, their structure begins to influence what an agent understands, what it overlooks, and how much it must infer.

The canvas is no longer only a place where the team presents the final interface. It is becoming part of the system through which software gets built.

Our box-based approach began with a practical need: make a complicated enterprise product easier to understand. Its value grew when the same structure helped divide that product into clearer units for implementation and review.

The boxes themselves are not the innovation. The clarity they create is.

Components define what the interface is made from. Frames capture individual moments. Boxes explain how those moments belong together and what the team is trying to build.

In a development process increasingly shared with AI agents, that context is no longer optional documentation.

It is part of the product.

About the Author:
Aaron Swinton is the Founder and CEO of MAVRK Studio, where he handles business strategy, client partnerships, and the agency’s growth. He has experience in brand building, venture investing, fundraising, and operations, and he uses it to help CPG brands launch and grow.

Most consumer packaged goods (CPG) launches don’t last. Somewhere between 70% and 85% fail, and it’s rarely because the product was bad. 

More often, the launch itself is the problem. There’s a logo from one shop, packaging from another, a website from a third, and nobody owning the whole picture. Along the way, teams end up testing the new product instead of the consumer need, the category, or the retail plan. 

An integrated CPG launch strategy fixes that by lining up product, brand, packaging, eCommerce, and marketing in one plan. That’s the idea behind MAVRK’s 90-day launch system, where Day 90 means “shelf-ready and launch-ready.” 

Why Most CPG Launches Fail (and How a 90-Day Plan Fixes It)

• Fragmented vendors: Brand, packaging, and digital are split across separate teams, and nobody owns the whole launch.
  The Fix: One team building all three in parallel.
• Unvalidated positioning: Design starts before anyone has confirmed demand, price, or the competition.
  The Fix: Validate all three before design begins.
• Weak execution: Wrong labels, bad dimensions, and missed retailer requirements derail a good product.
  The Fix: A week-by-week calendar with owners, approvals, and checkpoints.

One honest note: 90 days is the target, and it assumes timely feedback. Plan a few extra days for each round of revisions.

Inside the 90-Day CPG Launch Plan

Our plan runs on six overlapping workstreams instead of one long list of tasks. Across them, the work moves through four phases: foundation, build, pre-launch, and launch. 

• Weeks 1–2, Validate & Position: the product and launch strategy
• Weeks 2–4, Build the Brand: identity and messaging system
• Weeks 3–7, Design for the Shelf: compliant, retail-ready packaging
• Weeks 5–10, Build the Launch Engine: website, eCommerce, email capture
• Weeks 7–11, Create the Content: photo, video, social, launch creative
• Weeks 9–12, Get Shelf & Launch Ready: sales materials and retail readiness 

It all lives in a week-by-week calendar with clear owners, approvals, and go/no-go checkpoints. Because the workstreams overlap, packaging and photography can share one creative brief, and creator outreach can start before creative is finished. 

Weeks 1–2: Validate and Position

Prove Demand Before You Launch a CPG Brand

Design is the fun part, so it’s tempting to start there. But a CPG product needs category validation first: is the need real, where does the price sit, and who are you up against? 

The right research depends on how much the brand has already decided. For a brand with a clear product and launch direction, we review the category, competitors, and audience to sharpen its positioning before design begins. If the opportunity itself is still open, a deeper Opportunity Sprint can come first.

Depending on the scope, that work may include:

• A shelf and competitor review to understand the category and identify gaps
• Customer research and interviews to test assumptions and hear how people describe the need
• An assessment of the audience, differentiation, and best channels for launch

The goal is to make the key decisions early, so the brand, packaging, website, and launch content can move forward with a shared direction.

For instance, take our work for REALI. We redid branding, packaging, web design, social media and directed their go to market into colleges & gyms vs traditional retail. They’ve since gotten into 30+ stores in 5 months.

From Consumer Language to a Clear Promise

Research only helps if it turns into a promise people understand. Your positioning is that bridge, and it shapes everything after it. 

A positioning section of your launch plan should include:

• Frame of reference (the category you’re competing in)
• Target consumer
• Key benefit
• Reason to believe
• A promise and brand story in real consumer language
• A one-line concept statement everyone can defend 

These decisions ripple into recipe choices, pack size, pricing, channels, and the retail pitch. 

Weeks 2–4: Build the Brand

Positioning tells you who the brand is for. Now it needs a look and a voice people recognize. 

• Naming exploration, checked for trademark, domain, and social handles early, ideally in week 2 
• Logo, color palette, typography, and core visual language
• A brand voice brief: three personality words, plus “we are / we are not”
• A documented brand system: promise, personality, voice, messaging pillars, visual direction 
• A brand guidelines doc, even a single page, so every vendor works from the same reference 

Weeks 3–7: Design for the Shelf

Packaging, Compliance, and Operations

Plenty of launches stumble at the execution layer: wrong labels, bad dimensions, missed routing guides, or claims that don’t comply. 

This phase turns your positioning into a full SKU architecture, label system, and production files. 

Your packaging and operations checklist:

• Front-of-pack hierarchy, with a clear benefit
• Nutrition and regulatory compliance
• GTIN/UPC and case pack structure
• Co-packer alignment, lead times, and freight
• Retailer documentation confirmed before launch 

A quick shelf test: does it stand out at thumbnail size, and would a creator want to hold it? 

Retail-ready doesn’t mean retail-first. Build a few months of online sales (or community) proof before pitching buyers. 

Weeks 5–10: Build the Launch Engine

Website, eCommerce, and Email

Even retail-first brands need a strong digital engine for education, storytelling, lead capture, and proof for buyers. In Weeks 5–10, we build a conversion-focused website, eCommerce setup, store locator, and email flows.

• The Rice Cream: branding, packaging, web design, and launch content built to tell the product story and drive early interest.

• REALI: eCommerce-ready web design and launch messaging aligned with packaging and photo/video. 

What your plan should include:

• Landing pages and lead magnets
• A pre-launch waitlist
• Abandoned-cart flows and post-purchase emails 
• A pre-launch email list goal of 500+ subscribers 

Weeks 7–11: Create the Content

Photo, Video, and Social

Content turns a launch plan from strategy into visible momentum across social, email, and paid channels. In Weeks 7–11, we produce product photography, lifestyle imagery, recipe or usage content, and launch videos. 

Folkland’s social launch campaign shows what consistent visuals and storytelling can do. 

The Rice Cream and REALI paired photo, video, and social content that matched their packaging and websites. 

Map content to each phase:

• Pre-launch: teasers, behind-the-scenes, a countdown series 
• Launch: reveal content, how-to clips, UGC prompts, retailer-specific creatives 
• Post-launch: put more behind what worked, and feed real customer content and reviews back in

Creators can support each phase of the launch, from early product introductions to launch-day content and customer reviews. Depending on the brand, we may build a broader affiliate program where creators earn a commission on sales, or work with a smaller group of carefully chosen influencers to reach a specific audience.

Weeks 9–12: Get Shelf & Launch Ready

Go-to-Market Execution: Launch Week to Post-Launch

Build your launch calendar across pre-launch, launch, and post-launch, with inventory, media, and in-store support all lined up. 

In launch week, point every channel at one clear call to action, concentrate spend in the first 2–4 weeks, and check velocity and feedback daily. 

We treat the first 90 days in market as a commercial test, with success metrics and go/no-go or pivot points built into the plan. 

Track:

• Velocity: how fast the product sells
• Repeat rate
• ROAS: return on ad spend
• Email opt-ins 

When a message or creative performs well, we put more budget behind it and use what we learn to brief the next round of creators. When results are weak, we review the data, adjust the approach, and shift spend toward what’s working.

Alongside the launch, the sales side gets ready with a retail pitch built on your online sales data, plus sales materials and retailer documentation.

Growing After Launch: Community and Revenue

A strong launch strategy connects to a growth plan. It doesn’t stop at Day 90. MAVRK Grow picks up where launch leaves off. 

• Community growth: organic social, content, email, creator activation, and IRL activations. 
• Revenue growth: paid media, performance creative, and conversion optimization to scale what worked. 

Early signals, like top creatives, strongest audiences, and best regions, feed straight into performance campaigns. 

Putting It All Together: A 90-Day Checklist

• Days 1–30: validate, position, name, and build your brand identity and guidelines
• Days 31–60: packaging, online store, photography, creator outreach
• Days 61–90: content, email list, ad setup, soft launch, creator launch day, public launch 

The steps that prevent failure: validation, coherent branding, retail-ready packaging, a digital launch engine, and aligned marketing. We swap a pile of vendors for one accountable team. 

Your next step: audit your current launch plan against this checklist, or sketch your own 90-day roadmap before you talk to designers, agencies, or co-packers.

You can also talk to us about your brand’s starting point and launch goals, and we’ll help you work out what your first 90 days should look like.

About the Author:

Zlatina Petrova has spent 13 years shaping brands and digital products across Silicon Valley and Europe. As Founder and Design Director of Brandly, she works with tech startups, VCs, global brands and government institutions including work on Bulgaria’s national design system. Her work sits between branding, product design and UX/UI, with a belief that design should do more than look good: it should help businesses grow, products work better and brands mean something to people.

When Brandly started, clients weren’t buying the company. They were buying the people behind it. I already had a solid reputation of my own: I had led product design at an LA-based startup, worked as a creative director in Florida, and won one of Europe’s most prestigious design awards.

The media were dying to interview me. Nobody was dying to interview Brandly. Same with the clients. They trusted me first, and the company second. Trust lived in the founder before it lived in the brand. This is the core of effective executive personal branding. Only later did Brandly accumulate enough history, language, and systems to carry that trust independently.

In that transition, one truth became obvious: people don’t experience companies first. They experience people.

In the early stages, a founder’s personal brand is not a vanity project sitting next to the company brand. In a founder-led business, it is often the first interface through which people decide whether your company deserves attention at all.

Before they understand your product or mission statement, they are asking much simpler questions:

• Do I trust this person?
• Do I believe what they believe?
• Do I want to listen to them?
• Do I want to work with them?

The personal brand becomes so closely attached to the company that the founder eventually becomes the bottleneck for trust. If they step away, clients become nervous. If they move on to something new, the company suddenly feels different. If they want to sell the business, part of its value is still sitting inside one person’s relationships, reputation and way of thinking.

The founder’s real job goes far beyond visibility. The job is to turn personal conviction into something the company can eventually carry without you. Here is how the founder shapes the brand around them, and how that personal equity eventually becomes company equity.

Establishing Brand Identity and The Founder’s Role In Corporate Branding

Inevitable brands rarely begin as systems. They begin as conviction. Before there are guidelines, culture decks, and campaigns, there is usually one person who sees something that does not yet fully exist.

That person has to believe in it long enough for everybody else to catch up.

This is what I mean by devotion. Not founder mythology, and definitely not “hustle culture.” I mean feeling the brand deeply enough to sense when something strengthens it and when something quietly weakens it.

In the beginning, you notice the wrong tone in a sentence, the product that makes money but weakens positioning, or the impressive partnership that simply does not belong in the world you are building. Over time, your instinct teaches the rest of the organization what the brand actually is.

When the founder cares deeply about the details, employees start making better decisions without constant approval. What started as one person’s conviction slowly becomes something shared.

If the founder carries the brand internally, the personal brand makes that worldview visible externally. But this is where many founders get personal branding wrong.

Your personal brand is not a diary of everything you think, eat, or do. It is the clearest public expression of the parts of you that give the company meaning: your judgment, beliefs, standards, taste, expertise and way of seeing the world.

The public version of you should still be true. Just edited. You do not need to publish every private detail to feel human; you just need to make the part of you that explains the company legible to others.

Takeaway: The founder shapes the brand from the inside first. Personal branding makes that worldview visible from the outside.

Core Value Alignment and Strategic Brand Development for B2B Founders

There is a strange ritual happening in branding workshops everywhere, including plenty of B2B brand strategy consulting sessions we’ve run ourselves. Someone opens a Miro board. Everyone gets virtual sticky notes. Forty-five minutes later, almost every company on Earth discovers its values are innovation, integrity, excellence and customer-centricity.

If your competitors can copy your values without changing a word, they are not your values.

Real values are inconvenient. They come from your experience: the managers you never wanted to become, the moments that made you proud, the clients you instinctively protect, and the compromises you refuse even when money is on the table.

This is where founder branding begins. Not with “What should I post about?” but with “What do I believe so strongly that it repeatedly changes my decisions?”

Founders encode their values into the company whether they intend to or not. Those values dictate:

• Who gets hired
• How fast the product ships
• Whether difficult conversations are had
• What the company quietly tolerates

Repeated decisions become culture. Culture becomes user experience. Experience becomes reputation. Reputation becomes a brand.

Try building a founder value map. Take five important moments from your professional life, especially the frustrations and failures. Ask: What did this teach me that I now believe very strongly?

Look for repetition. You may discover that five apparently unrelated stories express the same principle. “Care” is not a value until it changes how you price projects or communicate bad news. A brand becomes credible when values create visible trade-offs.

Takeaway: Your founder brand should be built from beliefs with consequences, not values that simply look good on a wall.

Thought Leadership Strategy and Elevating Your Executive Personal Brand

Founders often tell me they “should be posting more.” I’m not convinced.

The internet does not urgently need another founder sharing seven lessons from waking up at 5 AM. What people need from experts is not more content. They need judgment.

A strong founder brand gives people a sense of how you think, what you challenge, and what matters to you before they ever buy.

A brand identity designer can post: “Five branding trends for 2026.” Or they can say: “Most early-stage companies redesign their visual identity too early, because the real problem is they haven’t decided what they want to be remembered for.”

The first gives me information. The second gives me perspective. Perspective is invaluable in businesses where clients buy trust: consulting, law, venture, architecture, or complex B2B software. A case study tells me what you did; a point of view tells me how you’ll think when we hit a problem neither of us has seen before.

A true thought leadership strategy begins with three questions:

• What do I believe?
• What observation made me believe it?
• What do I do differently because of it?

A belief that never changes your behavior is just positioning copy. For example, we believe brand consistency shouldn’t depend on designers policing assets. So, what do we do differently? We treat governance and contribution rules as part of the design itself, not an afterthought.

Now, you aren’t just claiming expertise; you are showing how it changes your work.

Takeaway: Don’t use your personal brand to prove that you are visible. Use it to make your thinking visible. 

Brand Cultivation and Hiring for Corporate Brand Alignment

Who is helping you build this thing?

Customers experience your brand through a salesperson, support agent, designer, freelancer, and sometimes a vendor. Every one of them translates the brand through hundreds of micro-decisions. A brilliant person who repeatedly makes choices that feel wrong for the company can weaken the brand more than an average logo ever will.

The best teams develop a shared instinct. They know which compromise the company will make and which it won’t. They know when something is technically correct but still not right.

You can call this cultural fit or brand alignment. The outcome is what matters: the person amplifies the signal rather than introducing static.

This must influence hiring. Assess skill, but also ask questions that reveal taste and judgment:

• Show candidates real scenarios.
• Ask what they would protect when time runs out.
• Ask what they refuse to compromise on.

Look at your existing team with the same honesty. Who strengthens the brand? Who is excellent at their job but consistently pulls the company toward a different identity? Alignment cannot be ignored forever.

Takeaway: Skills determine whether someone can do the job. Alignment determines whether they strengthen the brand while doing it.

Enterprise Brand Architecture: Scaling from Founder to Corporate Entity

As the brand grows, the founder’s role changes. Early on, trust travels through the person. Clients use your reputation as a shortcut to decide if the business is credible. But growth demands a new question: where should that trust travel next?

This brand equity transfer is crucial. Brand architecture dictates how much of the founder’s reputation transfers to the company, how much remains with the founder, and which new offers borrow from either.

Founders are tempted to capitalize on momentum. If people trust you, it’s tempting to endorse every new service or product you launch. Sometimes that is smart. Sometimes it is simply logo slapping. Accumulated trust should only travel where the promise and experience justify it.

Navigating this is why companies hire a specialized brand architecture agency, but you can start with three core paths:

• The Unified Brand: If a new offer delivers the same core promise and experience, it belongs inside a unified brand. The goal is to move trust away from the founder and deeper into the company.
• The Endorsed Brand (Brand Extension): If the experience belongs to the same world but the promise is different, it’s a brand extension. A visible association (“From the founder of…”) reduces perceived risk without pretending the new venture is just another version of the parent company.
• The Individual Brand: If the new offer has a completely different promise and audience, forcing the founder’s name onto it creates confusion. Founder equity shouldn’t be permission to attach the same reputation to everything.

The strategic goal is to make the founder an endorsement layer, not a permanent dependency.

Early on, use your personal brand. Let your name open doors and reduce risk. But simultaneously, the company must accumulate its own evidence: recognizable methodologies, systems, and a consistent experience.

The founder says, “This is what I believe.” The company proves, “This is how we operate.” Eventually, the customer concludes, “I trust this organization, even when the founder is not in the room.”

Many founder-led companies fail to reach this point, and Brandly was no exception early on. If the founder remains the ultimate source of reassurance, it becomes a massive problem the moment they want to step back, launch something new, or sell.

The best transition is gradual:

• Give visibility to your team.
• Turn personal know-how into company methodology.
• Move recurring ideas from your LinkedIn posts into the company’s language.
• Let clients form relationships beyond you.

Make the experience consistent enough that your personal reputation becomes the introduction, not the entire argument.

In maturity, the founder brand and company brand stop competing for attention and start endorsing each other.

Takeaway: In the beginning, the founder lends trust to the company. During growth, convert that borrowed trust into company equity. Use brand architecture to decide where that trust should compound, endorse, or stop.

People may buy the founder before they buy the company. That is not a weakness to hide; it is an advantage to design deliberately. But the founder’s real job is to build a world compelling enough that, eventually, people no longer need them standing at the entrance.

About the Author:
Vicente Reyes Montealegre, heads Afternow’s Brand and Web teams to guide SaaS companies, enterprises, and fast-growing startups in their digital journeys. The agency’s work spans strategy, brand, website, product and development, all under one roof, all connected to one vision.

Access to care was the whole point of Kinetik’s business. Non-emergency medical transport gets patients to dialysis, to chemo, to appointments they’d otherwise skip. So, the actual brief for this patient coordination platform design ran much deeper than logos and layouts. We needed to build a comprehensive product people could trust their care to.

The American healthcare system doesn’t make that simple. Riders, providers, and insurers all operate on different timelines and different systems, and getting them to coordinate can be exhausting for everyone involved, patients included. Kinetik exists to make that coordination actually work.

That’s a different problem than what most HealthTech faces. Kinetik’s users weren’t optimizing a workflow. Many were older, managing a condition, coordinating a ride they couldn’t afford to miss. Every decision, on the brand, the site, the products, had to hold up under that weight.

Warmth as a design compass in healthcare branding

We moved away from the clinical, high-tech blue and aqua gradients the old identity relied on. Most health tech platforms reach for a look that leans too much on the tech and not so much on what health means. It’s a common pitfall you’ll notice when browsing portfolios of even highly rated brand identity designers.

It makes sense because that is where innovation sat ten years ago. Today, we can argue that audiences are craving for digital experiences that feel tangible, genuine, with more texture and life in them.

The inspiration point started with a very concrete moment of Kinetik’s users journey: the feeling of looking out a window on a ride, watching the city go by as they travel to their medical appointments. That image is where the painterly, almost impressionistic illustrations of the urban landscape came from.

The palette followed the same instinct, pulled from the organic rather than the artificial: deep and vivid greens against gold, salmon, lavender, and a purple that reads like the last light of a sunset. Nothing else in the category looks like this.

Typography carries a similar weight. An elegant serif, used large, gives the brand a voice instead of blending into the next healthcare login screen. Used small, it steps back and lets the content do the work.

The photography direction stays close to that same idea, people in ordinary moments, at home, in the city, living their lives. Access to care isn’t confined to a hospital visit, it shows up in every part of someone’s day.

The refreshed logo carries this story as well. A capital K, drawn in one curved stroke, with a dot sitting at the end like a destination marker, because getting somewhere is what Kinetik actually does.

Structuring medical website navigation for complex audiences

The marketing site had one real problem before the rebrand: articles, case studies, and news all sat in one undifferentiated pile. We split it apart, and built the site’s structure and navigation around the three groups Kinetik actually serves: health plans, transportation providers, and state and government agencies, each with a clear path through the site instead of one menu trying to work for everyone.

The website does more than tell the story here. The same visual language that sets the mood on the landing page also gets used inside the product screen visualisations, to flag a trip, a claim waiting on review, or a step someone shouldn’t skip. Same system, pulling double duty: telling the story, and pointing at what matters.

HealthTech products solving opposite users at once

Inside the products, the same question got harder. Coordinators needed dense, fast interfaces, real-time visibility across thousands of trips, quick assignment, no wasted motion. Patients using the Kinetik Health app needed almost the reverse: large touch targets, few steps, a calm interface that doesn’t rush them.

That tension sits at the center of the patient app. Real-time tracking and recurring scheduling are genuinely sophisticated features. They had to live inside something simple enough for someone managing a visual or cognitive impairment to use without a second thought.

Contrast, focus states, type size, motion, none of it was a checklist item added at the end. It shaped the product from the start, proving exactly why companies must look beyond aesthetics when vetting UI/UX designers. Confusion on this screen costs someone their ride to treatment.

What it takes to build a healthcare product patients can rely on

The brand is the part people notice first, the color palette, the painterly illustrations, the typographic voice. It’s the part that makes Kinetik stand out on a shelf full of competitors that forgot about the people they’ll be affecting the most. That matters. But a harder, quieter work sits underneath: the architecture, the user flows, the structure that holds four different products together for four very different users. That work is the proof point, and the reason a patient with a ride booked for 7am can actually get there.