Skip to content
SUPPORT SYSTEM
UI/UX & Product Design

Interfaces designed for the work being done

We design software the way it will be used: on the third screen of a busy day, in Arabic as well as English, by someone who has done this task four hundred times. Wireframes, interface, design system and a handover developers can build from.

Design that survives contact with engineering

A design that looks beautiful in a presentation and cannot be built, or can be built but not maintained, has cost you money rather than saved it. We design inside the constraints: real content lengths, real error states, real permissions, real loading, and three languages including one that reads right to left. The process starts with the work, not the screens. Who does this task, how often, what do they already know, what happens when they get it wrong. Then the flows, then the wireframes, then the interface, then a design system with tokens and components rather than a folder of one-off artboards. We hand over in Figma with the states annotated and the spacing on a scale a developer can implement without guessing. Where we also build the software, the design system and the component library are the same thing rather than two documents drifting apart.

Key benefits

What this changes for your business.

Fewer support tickets

Most support load is an interface problem. Designing the confusing step properly is cheaper than staffing it.

Faster to build

A design system with real tokens and components means the second screen costs a fraction of the first.

Accessible by construction

Contrast, focus states, keyboard paths and labelling are decided in design, where they are cheap to change.

Designed in three languages

Layouts tested with Turkish word lengths and Arabic right-to-left flow, not translated after the fact.

What we deliver

The things you actually receive.

  • Discovery and user flows

    Who does what, how often, and where the current process actually breaks.

  • Wireframes

    Structure and hierarchy agreed before anybody argues about colour.

  • Interface design

    Every state that will exist in production: empty, loading, error, permission-denied, too much data.

  • Design systems

    Tokens, components and rules — the thing that keeps screen forty consistent with screen one.

  • Interactive prototypes

    A clickable flow for user testing or for showing an investor, before the flow costs engineering time.

  • Developer handover

    Annotated states, a spacing scale, and tokens that map to code rather than to a mood board.

Core capabilities

The engineering disciplines this service draws on.

Product discovery
User research
Information architecture
Wireframing
Visual & interface design
Responsive design
RTL & multilingual layout
Accessibility (WCAG)
Prototyping
Design system governance

Technologies we use

The stack we would reach for, and what each part is for.

Figma

Where the interface is designed, reviewed and handed over — one file the design and the build both refer to.

Tailwind

A utility-first styling system that keeps a design consistent across a large codebase without a growing pile of bespoke CSS.

React

A component library for interfaces with a lot of state — dashboards, editors and anything that updates while you look at it.

Vue.js

A progressive interface framework that can be added to one page of an existing application rather than requiring a rewrite.

TypeScript

Static types over JavaScript. On a codebase several people maintain, it turns a class of runtime bugs into compile-time ones.

Technology adoption

Technologies in this stack are publicly documented as being used by organisations including those below.

GitLab

Vue.js

Source

Slack

TypeScript

Source

These organisations are named as documented users of the technologies listed. They are not clients of Vertex Arc, and their inclusion does not imply any relationship with or endorsement of Vertex Arc.

Industries we serve

Sectors where this service tends to fit well.

  • SaaS
  • FinTech
  • Healthcare
  • Education
  • E-Commerce
  • Professional Services

Our delivery process

How an engagement runs, from first conversation to ongoing support.

  1. Discovery

    We work out what the software has to do, who uses it, and which constraints are real. The output is a written scope, not a proposal.

  2. Architecture

    Data model, boundaries, integrations and infrastructure decided and agreed before anybody writes application code.

  3. Design

    Flows and interface, including the empty, error and permission states that decide how the product actually feels.

  4. Development

    Built in reviewable increments against a conventional structure, with tests around the parts that would be expensive to break.

  5. QA & security

    Functional testing, performance checks, and a review of authentication, authorisation and dependency risk before launch.

  6. Launch

    Deployment, monitoring, and a period of close attention while real traffic finds what staging did not.

  7. Continuous improvement

    Patches, upgrades and new work through the support system, so the product keeps being maintained rather than quietly ageing.

Use cases

What this looks like as a finished product.

Redesigning a working product

Keeping what your users already know while fixing the parts that generate support load and drop-off.

Designing a new product

From the first flow to a design system, so the build starts from something specific rather than from a description.

Building a design system

Consolidating a product that grew screen by screen into components a team can build against.

Why Vertex Arc

Designers who know what is expensive to build

We flag the interaction that will cost three weeks while it is still a rectangle on a page.

Every state, not just the happy one

Empty, error and permission states are designed. Otherwise a developer invents them at 6pm.

Arabic is designed, not translated

RTL layout, mirrored navigation and an Arabic type stack are part of the design file, not a later ticket.

We can build it too

Design and engineering in one team means the handover is a conversation rather than a document nobody reads.

Frequently asked questions

Can you design without building it?
Yes. Design-only engagements end with a Figma file, a design system and a handover session with your engineers, and we stay available for questions during their build.
Do you do user testing?
When the decision warrants it. For a five-screen internal tool, talking to the four people who will use it is better value than a formal study. For a public product with a conversion target, we run structured sessions.
We already have a brand. Do you work within it?
Yes, and usually we extend it. A brand guideline covers logo, colour and type; a product needs a spacing scale, component states and a dark mode, and we add those to what you have rather than replacing it.