Designing how it works before deciding how it looks
UX design decides how a product is structured and how someone moves through it. UI design decides what that structure looks like. MBGDesk works in that order, and specifies the states most designs omit, empty, loading, error, long content, because those are where builds improvise.
Interface design is usually judged on a homepage image, which is the least informative artefact a design process produces. It shows one screen, at one width, with content chosen to fit. It says nothing about how someone gets to that screen, what happens when the form is wrong, or what the page looks like when the customer's company name is forty characters long.
Designs approved as pictures fail in predictable places. The flow was never mapped, so a user reaching step four discovers there is no way back to step two. Real content overflows the boxes that fit the placeholder text. Nobody drew the empty state, so a new user's first screen is a blank table. Error states get invented during development by a developer under time pressure, which is how error messages end up saying 'An error occurred'.
When this work makes sense
Questions worth asking any supplier
Is the flow mapped before screens are drawn? Screens without flows produce dead ends.
Are empty, loading and error states specified, or left for development to invent?
Is the design tested with real content, including the longest realistic values?
Does the designer understand what is expensive to build? Designs that ignore that get negotiated down during development.
Is there research behind the decisions, or is it taste? Both have a place, but they should be distinguishable.
Deliverables
User flows for every significant task, including the paths backwards
Information architecture. What exists, what it is called, and how it nests
Interface design at mobile, tablet and desktop widths
Every state specified: default, empty, loading, error, success, and long content
Interaction specifications covering what happens on each action
Accessibility built in, focus order, contrast, labels, keyboard paths
Developer handover as tokens and component specifications rather than flat images
Built with
Process
Flows are mapped and agreed before any screen is drawn. It is a deliberately unsatisfying first deliverable, boxes and arrows rather than something that looks like a product, and it is where the expensive structural mistakes get caught. Once a design looks finished, people critique the colours; a flow diagram invites the question of whether the sequence makes sense, which is the question worth asking early.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
UX only, UI only, or both
UX only
Fits: Teams with visual design capability who need structure and flows resolved
Limits: Someone still has to make it look like something
UI only
Fits: Products whose structure is settled and whose appearance is the problem
Limits: Applies a surface to a flow nobody has questioned
Both
Fits: Most projects, the structure and the surface inform each other
Limits: Longer process with two distinct sign-off points
Case studies
No published UX case study. Design outcomes are meaningful only with before-and-after completion data, which requires client permission we do not have.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
What is the actual difference between UI and UX?
UX is how it works: what steps exist, in what order, and what happens at each. UI is how it looks and feels at each of those steps. A product can have excellent UI and poor UX, attractive screens arranged in a sequence that does not make sense, and the second is the more expensive problem to fix.
Do we need user research?
It depends how much you already know and how much is being assumed. If you speak to customers regularly and understand where they struggle, research may confirm what you know. If the team is designing from internal assumptions about an audience nobody has spoken to, it is worth the time.
Why start with wireframes instead of designs?
Because structure and appearance are different decisions and reviewing them together means neither gets proper attention. People discuss colour when shown a finished design; they discuss sequence when shown a flow. Separating them gets both questions answered.
How do you handle accessibility in design?
Contrast is measured rather than judged by eye, focus states are designed rather than left to the browser default, and heading hierarchy and labels are part of the specification. Designing accessibly costs very little; retrofitting it after build costs considerably more.
Can you work with our developers?
Yes, and the handover is built for it, named design tokens rather than measurements to read off a screen, component specifications covering every state, and a working session so the questions that always surface during build get answered early.
What if we disagree with the design?
Then the reasoning should be examinable. Every significant decision should have a stated rationale, a flow simplified because of a drop-off, a layout chosen because of content length, so disagreement is about the reasoning rather than about taste. Where it genuinely is taste, you decide; it is your business.
How long does design take?
It scales with the number of distinct flows and states rather than the number of screens. Twelve pages sharing one template is a small job; three templates each with six states is a larger one than it looks.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.