Web design judged on what it does, not how it looks

Web design covers the interface and the experience: how a page is laid out, how someone moves through it, and what makes them act. MBGDesk designs in wireframes first, reviews at real device widths rather than one desktop mock, and hands over a design system rather than a set of flat images.

A website design is usually presented as a picture of a homepage. That picture answers almost none of the questions that matter: what the page does at 360 pixels wide, what the form looks like with three validation errors showing, what the empty state says, and whether the colour carrying the primary action has enough contrast to be legible.

Designs approved as desktop images tend to break in three predictable ways. Text that fitted the mock overflows once real content arrives. States nobody drew — loading, empty, error, long name, missing image — get improvised during development. And the visual hierarchy that looked clear at 1440 pixels collapses on the device most visitors actually use. There is a fourth, quieter failure: a design approved without a system behind it. Every subsequent page becomes a new design decision, made by whoever is available, and the consistency that made the original look considered erodes within a few months.

Who this is for

When this work makes sense

  • Businesses whose current site converts poorly despite reasonable traffic
  • Companies with no consistent visual system across their pages and materials
  • Teams commissioning a build who need the design resolved before development starts
  • Products where the interface is the service, not a brochure for it
  • Organisations that need the design handed over in a form their own developers can build
How to choose

Questions worth asking any supplier

Are designs reviewed at real breakpoints, or as one desktop image? Most traffic arrives on a phone.

Does the design include the unglamorous states — empty, loading, error, long content? Those are where builds go wrong.

Is colour contrast measured, or eyeballed? An accent colour that fails contrast is a legal risk and an accessibility failure.

Is the output a design system or a set of pictures? Pictures cannot be extended; systems can.

Does the designer understand what the developer will build, or is the handover a translation exercise?

What you get

Deliverables

Wireframes for every distinct template, agreed before visual design begins

Interface design at mobile, tablet and desktop widths

A design system: colour tokens, type scale, spacing, components, states

Measured contrast ratios for every text and background pair, against WCAG AA

Interaction and state specifications, including empty, loading and error

Developer handover with tokens and component specifications, not flattened images

Built with

  • Figma
  • Design tokens
  • WCAG 2.2 AA
  • Responsive layout systems
  • Component libraries
How we work

Process

Design work inverts the usual order: structure before surface. Wireframes are signed off before a single colour is chosen, because arguing about layout while looking at a finished-looking design is almost impossible. Visual design then applies the system to the agreed structure, and every screen is reviewed at three widths before approval.

The standard nine stages — discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement, continuous improvement — apply to every project. The paragraph above is what differs for this one.

Pricing

What moves the number

Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:

  • Number of distinct templates, not number of pages — twelve service pages sharing one layout is one template
  • Whether a design system already exists or is being created
  • How many states and edge cases each interface needs specified
  • Whether the work includes a brand identity or applies an existing one
  • Rounds of revision, and who has sign-off authority
  • Whether you need prototypes for user testing
Comparison

Template, custom design, or design system

Premium template

Fits: Early-stage businesses needing a credible presence quickly and cheaply

Limits: Your site resembles every other buyer of that template; layout constrains your content rather than serving it

Custom design

Fits: Businesses whose site is a primary sales channel and needs to fit their actual content

Limits: Longer and costlier; needs your time in reviews

Design system

Fits: Organisations producing pages continuously and needing consistency across teams

Limits: Highest initial investment; only pays back at volume

Proof

Case studies

No published design case study yet. We would rather show nothing than present unattributed work or mock projects as client outcomes.

MBGDesk operates from 4 offices — India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.

Questions

Frequently asked questions

What is the difference between web design and web development?

Design decides what the interface is and how it behaves. Development builds it. We do both, but they are separate stages with separate sign-offs, because approving a design and approving a build are different decisions.

Do you design in Figma?

Yes, with design tokens rather than loose styles, so what a developer receives is a system with named values instead of a set of measurements to copy by hand.

Can you redesign our site without rebuilding it?

Sometimes. If the existing content model is sound and the templates are separable from the content, a reskin is possible. If content is embedded in page templates, redesign and rebuild are effectively the same job.

How do you handle accessibility?

Contrast is measured rather than assumed, focus states are designed rather than left to the browser default, and heading hierarchy is part of the design. It is cheaper to design accessibly than to retrofit it.

How many revision rounds are included?

We agree the number before starting, along with who has final sign-off. Unlimited revisions with an unclear decision-maker is the most common way a design project overruns.

Will the design work on mobile?

It is designed at mobile width first for content-led pages. We review at eight widths from 360 to 1920 pixels before sign-off, so nothing is discovered at build time.

What exactly do we receive at the end?

A design system rather than a folder of images: colour and spacing tokens with names, a type scale, every component in each of its states, and the layout rules at each breakpoint. The difference matters at the first change request — with images, a new page means a new design; with a system, your developer assembles it from parts that already exist.

Can you work with our existing developers?

Yes, and it is a common arrangement. The handover is built for that case: tokens as named values rather than measurements to read off a screen, component specifications covering states, and a short working session so the team can ask the questions that always come up once building starts.

What if we do not have brand guidelines?

Then the design work establishes the parts the website needs — colour, type, spacing, tone — without pretending to be a full brand exercise. That is a different and larger piece of work, and we will say so rather than quietly charging for a logo review.

Related

Talk to us about this

Tell us what you are trying to build and we will come back with scope, approach and an estimate.