Enterprise UX/UI selection fails most often for one reason: the evaluation is built around visual portfolios, while the work that decides the outcome is research, information architecture, design systems, accessibility and the handover into engineering. A studio can produce beautiful screens and still leave you with a platform your teams cannot operate. This piece is about how to assess the parts you cannot see in a case-study image.
First, decide whether you actually need enterprise UX/UI depth. You do when the interface serves several audiences at once (customers, corporate clients, investors, regulators, internal teams), when the content is governed by more than one department, when the same design language has to hold across dozens or hundreds of templates, or when accessibility and multi-language support are contractual rather than optional. If your need is a single campaign page, most of what follows is over-specified for you — and a good partner will say so.
Research: ask what the partner does when there is no budget for a large study. Mature teams have a proportionate answer — stakeholder interviews, analytics and search-log review, support-ticket analysis, a task-based review of the current product, and a small number of moderated sessions with real users of the relevant type. Weak answers describe research as a fixed package regardless of context, or skip straight to wireframes. In our own audit work — for example the ongoing UX audit and improvement cycle we run for BPN — the value comes from repeating a defined review rhythm, not from one large discovery event.
Information architecture: ask to see a navigation model, not a sitemap picture. For an enterprise site the real question is how the structure survives growth: what happens when a new business line, a new country or a new content type arrives. A partner who has done this will talk about content types, ownership, URL strategy, and how the taxonomy maps to who maintains what. If IA is presented as a one-time deliverable rather than a governed model, expect drift within a year.
Interaction and UI design: look for evidence of states, not screens. Loading, empty, error, permission-denied, long-content, small-screen and high-zoom states are where enterprise interfaces break. Ask for a walkthrough of one complex flow — an application form, a document upload, a multi-step search — and listen for how edge cases were handled. A 31-field application form redesigned into a guided flow, as we did for Garanti BBVA Leasing, is a more useful conversation than a homepage hero.
Prototyping: the question is what the prototype is for. Prototypes that exist to win approval look polished and prove nothing. Prototypes that exist to reduce risk are rough, testable, and focused on the two or three decisions that would be expensive to reverse. Ask which decisions the prototype was built to settle, and what changed as a result.
Design systems: this is the clearest separator between studio and supplier. Ask whether the system is delivered as a design file, as coded components, or as both under shared naming; how tokens handle theming, density, language direction and accessibility contrast; who governs contributions after launch; and how a change reaches production. A system that exists only in a design tool becomes a museum piece the moment engineering starts improvising.
Accessibility: ask which standard and level the partner designs to, at what point in the process it is applied, and how it is verified. The credible answer names a target (WCAG 2.2 AA is the common enterprise baseline), places accessibility in design decisions rather than a pre-launch fix, and describes both automated checks and keyboard and screen-reader testing. Ask for a project where accessibility shaped the design, not one where it was retrofitted — our work on the Çelebi Aviation platform is an example of accessibility being treated as a design constraint from the start.
Design-to-code continuity: this is where most enterprise programmes lose their quality. Ask who implements the design, whether designers review the built result, how design and code stay aligned after launch, and what happens when engineering hits a constraint the design did not anticipate. Partners who design and build under one accountable team can answer directly. Partners who hand off will describe a process; press for what happens when the process fails.
Governance and evidence: ask how decisions are recorded, how change requests are priced and prioritised, who owns the backlog after launch, and what the working rhythm looks like in month eighteen rather than month two. Then ask for evidence that matches the claims — a named client relationship that has lasted several years, a case study with a described before-and-after, an award tied to a specific project and category, a reference willing to talk. Evidence beats adjectives every time.
Red flags worth taking seriously: a portfolio of visuals with no described problem or outcome; research described as a fixed package; accessibility positioned as a compliance add-on; a design system offered without governance; no named team, or a pitch team you never see again; unwillingness to discuss what went wrong on a past project; guaranteed rankings, guaranteed AI visibility, or guaranteed outcomes of any kind; and pricing that cannot be traced to scope.
A shortlist scorecard you can use directly. Score each partner one to five on: relevance of sector experience; research proportionality; IA and governance model; interaction depth on complex flows; design-system maturity and ownership; accessibility method and verification; design-to-code continuity; engineering and integration capability; post-launch operating model; and quality of evidence. Weight the criteria before you see the proposals, not after — that single step removes most of the bias that presentation quality introduces.
Where we fit, stated plainly: MadeByCat works best on enterprise platforms where design quality, engineering depth and long-term operation are the same conversation — regulated sectors, multi-brand and multi-site structures, accessibility-critical audiences, and organisations that intend to keep improving a platform for years. We are not the right partner for one-off campaign microsites, pure performance-marketing engagements, or teams looking for a low-cost implementation resource with the strategy already fixed elsewhere.
The final test is simple. Ask each shortlisted partner to explain, in their own words, what they would need to be true about your organisation for the project to succeed. The answer tells you whether they are describing your problem or their pitch.
Related pages on this site: enterprise UX/UI design, enterprise references and how the studio works.
