Before we used Framer to build websites, we worked with React and the animation library then called Framer Motion. That background shaped what we wanted from a visual tool: control over how a design behaves as well as how it looks.

The library is now called Motion, and it operates independently of Framer’s website builder. Our experience with it made us interested in the relationship between design and interaction, and in how closely those decisions could be made.

Framer’s appeal was the opportunity to work on more of that relationship within the environment where the website takes shape. A layout could be assessed alongside its responsive behavior. An adjustment to a component could be reviewed in the context of the page around it.

For us, that changed where some of the design work happened. Questions that might otherwise wait until implementation could become part of the conversation earlier, while the direction was still taking form.

Bringing behavior into the design process

A website is encountered through actions as well as images. A visitor opens a menu, follows a link, waits for media, or moves from a project overview into its details. Each action affects how the design is understood.

A layout therefore needs more than an attractive arrangement at a selected screen width. It needs to remain understandable when the available space changes, when a person uses a different input method, or when the content varies.

Working closer to implementation makes these relationships easier to examine during design. In preview, we can look at how a component responds and decide whether its behavior supports the page. A transition can be judged alongside the content it connects, with attention to whether the movement helps someone follow the experience.

The aim is to make those decisions while they can still inform the wider design. A component that needs a different hierarchy at a smaller width may also reveal something useful about its structure on a larger screen.

Building around content that will change

A project card can look convincing with a short title and a carefully chosen image. The same card still needs to work when the title takes three lines or the next image has a different composition.

These variations are part of the brief. Real content gives the team something substantial to assess: whether a hierarchy remains clear, whether an image has enough room, and whether repeated elements still feel related.

Framer’s page types support different parts of this work. Design Pages provide private canvases for exploration and mockups. Web Pages form the published site, while CMS Pages use shared templates for collection content.

The distinction between a template and its content has consequences for design. A template should make different entries feel part of the same website without assuming that every entry will contain the same amount of information.

Content structure deserves attention early. If a page depends on information that is difficult for the team to supply or maintain, the difficulty will return with each update. The design needs to account for both the visitor reading the page and the person preparing its content.

Giving custom code a clear purpose

Some briefs need behavior beyond the visual editor. Framer’s Code Components use React to extend what a site can do, including components that appear on the canvas, in preview, and on the published website.

That keeps development knowledge relevant to a visual workflow. The team still needs to decide what should be custom, how it will fit with the surrounding components, and what maintenance it introduces.

Start by defining what the visitor needs to accomplish and what the interaction must communicate. That gives the team a basis for deciding whether custom behavior improves the experience.

A custom component also needs to work when its content or context changes. If it presents a list of services, for example, adding an item or changing a title should not make it difficult to use. Its purpose should remain understandable as the website develops.

The platform choice needs the same attention. A portfolio organized around projects has different requirements from an application handling complex user data. Integrations, content management, and ongoing responsibilities should inform the decision before production begins.

Designing for the team after launch

A website continues to change after the design team has finished the initial build. New work is added, services develop, and someone needs to revise a page without rebuilding its layout.

That makes the editing experience part of the project. A visually convincing site can still be difficult to maintain if its structure is unclear or routine updates depend on specialist intervention.

A useful handoff should explain where content belongs, which elements are shared, and what a change is likely to affect. Custom components need enough context for the next person to understand their role. The team should also know when an update calls for a design or development review.

These considerations help define what a successful build needs to deliver. The people maintaining the website should be able to make ordinary changes with a reasonable understanding of the system they are using.

Finishing the work in the browser

A visual editor can make a design easier to assess during production. The published website still needs a deliberate review.

Content needs checking across a range of screen sizes, including the widths between the layouts that received the most attention during design. Navigation should remain understandable with a keyboard. Forms and links need to behave as intended, with useful feedback when something requires attention.

Media and motion deserve their own review. An image-heavy page needs consideration for loading time, while animation should support the content and account for people who prefer less movement. These are decisions about the experience itself.

For us, Framer brings more of those decisions into contact with the design process. Its value becomes clearest when that access is used carefully: to examine real content, resolve awkward behavior, and leave the next editor with a structure they can understand.