Designing for the Client After Handover

One of the most important decisions in web development happens before much code is written or a final page is assembled: deciding what the website needs to become after launch.A visually strong site can still be the wrong solution if the platform behind it does not suit the way the business intends to use it. A marketing team publishing content regularly has different requirements from a company that needs a focused product site. A portfolio does not need the same content structure as a service business, and a website I continue maintaining myself can be organised differently from one that will eventually be handed over to somebody else.That is why I do not treat Figma, Framer and WordPress as competing answers to the same question. They solve different parts of the web-development process, and choosing between them is part of the architecture of the project.

The visual design matters, but so do content ownership, maintainability, responsive behaviour, hosting, future development and how much technical knowledge the person receiving the site should realistically need.

The platform decision starts with the brief

Before choosing a delivery platform, I want to understand what the finished website actually has to do.If the project is highly visual, changes relatively infrequently and depends heavily on interaction, presentation and rapid design iteration, the requirements point in one direction. If the client expects to publish articles regularly, manage several content areas internally or wants a familiar CMS that can be supported by a broad development ecosystem, the requirements point somewhere else.Making that distinction early prevents the technology from dictating the website.

It also changes how I use design tools.

Figma is valuable when I need to resolve visual hierarchy, page structure, typography, interface relationships and the overall design language before implementation. At that point I am solving the communication problem: what needs prominence, how information should be grouped and how a user should move through the experience.Once that design has to operate as a real website, another set of concerns takes over. Components have to respond to unpredictable content. Navigation has to work across different screen sizes. CMS structures need to remain manageable. Motion has to support the interface rather than distract from it, and decisions that looked good in a static layout have to survive real browser behaviour.This is where the implementation platform becomes part of the design decision rather than something chosen afterwards.

Framer works well when design and implementation need to stay close

Framer has become an important part of my web workflow because it keeps the distance between visual design and the working website relatively small.

Responsive behaviour, CMS content, reusable components, interactions and animation can all be developed while working directly with the interface that will eventually be published. That makes it particularly effective for product sites, portfolios, landing experiences and other projects where presentation and iteration speed carry a lot of weight.HK Lab Studio itself has required that kind of flexibility.

The site has grown beyond a simple portfolio into a larger digital product environment containing a store, product pages, a blog, demonstrations, external integrations and several different content types. Maintaining consistency while those areas evolved required more than designing individual pages. It meant thinking about reusable components, CMS structure, responsive behaviour and how changes in one area affected the rest of the site.That same thinking became even more important when I developed PlaySignal as a commercial Framer template.

PlaySignal moved the design problem beyond my own workflow

There is a significant difference between designing a site that I will continue maintaining and designing a template that another person is expected to take apart, adapt and make their own. With PlaySignal, I could no longer rely on knowing why every decision had been made.

The project needed a clear internal structure. Components had to be reusable rather than merely convenient in one particular layout. Responsive behavior had to accommodate content I had never seen, and sections needed enough flexibility to support another brand without losing the design principles that made the template work in the first place. That changes the way seemingly small decisions are evaluated. Naming matters because somebody else will eventually navigate the project. Component boundaries matter because a change in one place should not unexpectedly damage another. Content areas have to tolerate longer titles, shorter descriptions and different images. Mobile layouts need to be intentionally designed rather than treated as compressed versions of the desktop page. A commercial template also needs an appropriate balance between control and flexibility.

If the structure is too rigid, the buyer spends their time fighting the original design. If everything is completely unrestricted, the system stops providing much value as a template. The useful middle ground is to establish a strong visual and structural framework while making the areas most likely to change straightforward to edit.PlaySignal reinforced something that now influences most of my web work: reusable design is less about creating more components and more about deciding where consistency should be protected.

WordPress addresses a different client requirement

There is a different class of project where visual editing speed is not the only priority.For many business websites, the CMS itself is part of the handover. The client may want to publish content internally, add pages over time, work with an existing WordPress hosting environment or keep the project compatible with an ecosystem that another developer can support later.WordPress remains difficult to ignore in that context because it is already deeply established in the commercial web environment.That does not make it the automatic choice for every project, and I do not approach it that way.

The benefit is having another appropriate delivery option when the project calls for a familiar CMS, greater hosting independence or a content model that will continue growing after launch.

Modern WordPress also provides a much more integrated site-building environment than the older model of treating the theme as little more than a fixed visual layer. Block themes, templates, patterns and global styles create an opportunity to build a coherent design system while still giving the site owner practical control over their content.

That was the basis on which I approached Nexora.

Nexora was designed as a website system, not a homepage

The objective with Nexora was not simply to create another attractive SaaS landing page.The homepage needed to establish a strong visual identity, but it also needed to belong to a complete website architecture.That meant treating the About, Features, Pricing, FAQ and Contact pages as part of the same design system rather than secondary pages assembled after the main work was finished. The blog archive and individual article layouts needed equal consideration because a content-driven business will spend far more time publishing into those areas than editing its original hero section.Navigation, footer structure, responsive behaviour, interaction states and accessibility also had to remain consistent across those different contexts.Even the 404 page formed part of the system.

That may seem minor when compared with the main marketing pages, but those details reveal whether a template has genuinely been designed as a complete website or simply arranged to produce an attractive demo.The aim was to make Nexora useful as a starting architecture for an AI or SaaS business rather than provide a screenshot that happens to run inside WordPress.

The design system had to work with WordPress rather than around it

A deliberate decision in Nexora was to avoid making a paid page builder a requirement for reproducing the supplied design.Additional plugins can absolutely be appropriate when a project requires specific functionality, but I did not want the basic presentation of the theme to depend on another commercial layer before the site owner had even started working with it.That meant leaning more heavily on native WordPress capabilities.

Templates, block patterns and global styles became part of the architecture rather than additions made at the end. This also required decisions about which parts of the design should remain controlled and which should be easily adaptable.That balance is important.A CMS should give the owner meaningful control over content, but exposing every structural value simply because it can be changed is not necessarily good product design. Too much unrestricted control can slowly destroy visual consistency; too little makes routine editing unnecessarily dependent on the developer.The goal was therefore not maximum configurability.It was controlled flexibility.I wanted the parts a business is likely to update regularly to remain accessible while keeping enough of the underlying design system intact for the site to retain its character.

Responsive design has to survive real content

One of the recurring mistakes in web design is treating responsiveness as a final viewport check.I prefer to deal with it as a system behaviour.

The important question is not whether a page looks correct at one desktop width and one mobile width. It is whether the layout continues to behave properly when content changes, cards wrap differently, headings grow, navigation becomes constrained and interface elements compete for limited space.This became particularly important across both PlaySignal and Nexora because neither template could assume the supplied demo content would remain unchanged.That requires more than reducing font sizes.

Spacing has to collapse intelligently. Grids need sensible breakpoints. Interactive targets have to remain usable on touch devices. Text needs enough room to grow without colliding with neighbouring elements, and desktop interactions cannot be allowed to become awkward mobile behaviour simply because the viewport changed.For me, that is part of template architecture rather than final-stage polishing.

A clean installation is part of the product

The development environment can also hide problems remarkably well.

After working on a site for long enough, the correct pages already exist, navigation has been configured, settings have been adjusted and content has gradually accumulated around the design. From inside that environment, everything can appear complete.That does not necessarily represent what the customer receives.

This is where my software-development and web-development workflows overlap quite strongly. I do not consider the development environment itself sufficient proof that a packaged product is ready.Nexora therefore needed to be tested from the perspective of a fresh installation.

The core pages became part of the setup logic, with safeguards to prevent them being unnecessarily recreated. Homepage and posts behaviour had to be accounted for, and the packaged theme had to establish a meaningful starting point without depending on configuration left behind in my own local environment.The principle is the same one I apply when preparing software releases: test the version being delivered, not merely the environment in which it was built.

For a template, installation is part of the user experience.

Hosting should remain an infrastructure decision

I developed and tested Nexora locally because I wanted the theme itself to remain independent from a particular hosting provider.That separation matters in professional web work.

The design layer, CMS and infrastructure each solve different problems. If those concerns become unnecessarily coupled, future changes become harder than they need to be.A client may ultimately choose Hostinger or another managed WordPress provider because managed hosting can simplify SSL, backups, caching, updates and other operational concerns. Another client may already have infrastructure they want to retain.The theme should remain capable of operating correctly in either situation.I prefer the hosting decision to be driven by traffic requirements, support expectations, budget, administration and the client’s existing environment rather than by limitations introduced into the website design.

Keeping those layers separate also makes future migration and maintenance easier.

PlaySignal and Nexora solve the same handover problem differently

Building PlaySignal and Nexora on different platforms made the similarities between the projects more obvious than the differences.Both products needed a design system that another person could understand. Both needed responsive behaviour that would survive content changes. Both required decisions about where flexibility was valuable and where consistency should be protected. Both had to be tested as products rather than judged only inside the environment where they were originally created.

The difference is in what happens after handover. With PlaySignal, the next person continues working inside Framer, where the visual structure and implementation remain closely connected.

With Nexora, the handover extends further into CMS administration, publishing workflows, installation, WordPress conventions and hosting choices.That is why I would not describe either platform as the better web-development tool.

They are different delivery strategies.

For visually driven projects where design, interaction and publishing need to remain tightly connected, Framer can be an excellent fit.For projects where content ownership, CMS familiarity, long-term publishing and hosting flexibility carry more weight, WordPress can be the stronger choice.Figma remains valuable further upstream when the problem still needs to be solved at the visual and interface level.The professional decision is knowing where each belongs.

Affiliate disclosure: HK Lab Studio earns a commission if you subscribe through this link, at no extra cost to you.