Bespoke website
design services
in Westwood

A bespoke design is usually presented as a set of wide desktop mockups. Then development starts, and somebody asks what the page looks like on a phone. If the answer is to squeeze the desktop design, the result will be a site that looks custom on one screen and generic on all the others.

The practical question is how many widths get designed by hand. Designing every possible size is impossible. Designing only one leaves too much to chance. Most custom sites settle on three: a phone around 375 pixels wide, a tablet or small laptop, and a large desktop. Everything in between is handled by rules.

Those rules matter as much as the mockups. How does a four column grid collapse? Which images crop, and around what point of interest? Does the navigation turn into a menu button at a fixed width or when the items stop fitting? Writing these decisions down turns three pictures into a design that works at any size.

Phones deserve a proper design rather than a rearranged desktop. Content order may change. A long comparison table might become a set of cards. A large decorative image that sets the mood on a wide screen can push the headline below the fold on a phone, so it may need a tighter crop or a different image altogether.

Very wide screens are the forgotten end. On a large monitor, text lines stretch until they are hard to read and small layouts float in a sea of empty space. Setting a maximum width for text and deciding what backgrounds do beyond it keeps the design intact.

Typography should scale with the screen. Headings that look confident on desktop can dominate a phone, and body text sized for a phone looks timid on a large display. Fluid type sizes that grow between a minimum and a maximum solve this without dozens of separate settings.

Touch changes interaction design. Hover effects carry no meaning on a touch screen, so anything important revealed on hover needs another path. Buttons need a comfortable tap size, and links placed close together in running text need enough spacing that a thumb can hit the intended one. Forms on phones benefit from the right keyboard type for each field, a numeric pad for phone numbers and an email keyboard for addresses.

Before approving the design, review it on real devices as well as in a browser window dragged narrow. Colours, text sizes and spacing feel different in the hand.

A design brief lists the pages everyone can picture: home, about, services, contact. The site will also produce screens that nobody mentioned in the kick-off meeting. If they are not designed, the developer fills them in with defaults, and the custom look ends abruptly at the edges.

The 404 page is the obvious one. A visitor lands there through a broken link or a mistyped address. A good 404 page admits the problem in a line, offers a search box and links to the main sections. It keeps the site header and footer. It does not need a joke, although a little warmth does no harm. Keep it short.

Search results are next. If the site has search, the results page needs a layout that shows titles, a short excerpt and the type of content. It also needs a state for no results. That state should suggest other spellings or popular pages rather than a blank area.

Then come the pages that forms create. What does a visitor see after sending a contact form? A plain line of text at the top of the same page is easy to miss. A dedicated confirmation screen can say when to expect a reply and what to read meanwhile.

Legal pages come next. They are long, plain and often ugly. Privacy policies and terms still carry the site header and use its type styles. A readable layout with a table of contents and sensible line length costs little and signals care.

Archive and category pages, author pages, pagination controls and the cookie banner all belong on this list too. So do maintenance screens and password pages for staging sites, if a client will see them. Email templates count as well. The order confirmation that lands in an inbox is part of the design.

The simplest way to catch these is a checklist agreed before design begins. Each item gets either a designed layout or a written rule saying which existing layout it borrows. Nothing is left to the default theme. The checklist also gives the developer a clear definition of finished, and it gives the client a way to confirm that every visible screen was actually reviewed before launch.

These screens take little time to design once the system exists. Leaving them out takes longer, because each one comes back later as a separate request.