What is UI/UX design?
UI/UX design is the work of deciding what a piece of software asks of a person and how it asks. The UX half is structural: who the users are, what they are trying to finish, the order the steps should come in, what happens when something fails, and which decisions the software should make so the person does not have to. The UI half is the surface that carries it: layout, hierarchy, type, colour, states and the component set that keeps every later screen consistent. A UI/UX design company that only produces the second half hands over attractive screens that nobody can complete a task in.
AtashiTech runs design as part of building software rather than as a separate agency service, which is the main way we differ from a UI/UX design company that only hands over files. Our designers work on interfaces that are hard in specific ways: a self-service terminal used once by a member of the public who cannot ask for help, an operations console someone stares at for eight hours, and a phone app used in a warehouse in poor light. Those constraints are the discipline; see the services we apply it to.
When to bring in a UI/UX design company
Design is usually bought at one of three moments, and the moment determines what the work actually is.
An existing system is being avoided
Users have built workarounds: a parallel spreadsheet, a WhatsApp group, a printed form. The software is not broken, it is unusable for the way the work really happens. That is a research problem first and a redraw second, and starting with the redraw wastes the budget.
Something new is about to be built
Screens designed before development starts are the cheapest place to discover that a step is missing or that two roles need different views. Deciding it in a prototype costs an afternoon; deciding it after the API exists costs a sprint.
The product has drifted out of consistency
Four teams, four button styles and three different date pickers. The fix is a design system with real components and rules, so consistency becomes the default rather than something to be policed in review.
How we run a design engagement
Four stages, each ending in something the client and the developers can both act on. Nothing here is decoration; every artefact is used by somebody downstream.
Research
We watch the work being done where it is done: the counter, the shop floor, the gate, the desk. Interviews, a walk-through of the current tools and the workarounds around them produce personas, the task list and the constraints, including physical ones such as gloves, glare and mounting height.
Structure and wireframes
Journeys, screen inventory and low-fidelity wireframes settle the order of steps, the information on each screen and what happens at every failure point, before anybody argues about colour. This is the stage where scope is genuinely negotiable.
Interface and prototype
Visual design is applied and assembled into a clickable prototype at the real screen size, which stakeholders review and, where it matters, real users try. A prototype settles arguments that a static image only prolongs.
Design system and handover
Components, states, spacing, type scale and tokens are documented so developers build from rules rather than by measuring screenshots. Designers stay available through the build to answer the cases the prototype did not cover.
What a design engagement includes
The default set. Which items matter most depends on whether the software is used once by a stranger or all day by a specialist.
User research and personas
Interviews and observation in the real setting, turned into a small number of personas and a task list that the rest of the work is judged against, rather than a document nobody opens again.
Journey and flow maps
Every path through the product, including the unhappy ones: a failed payment, a rejected scan, a lost connection. Failure paths are where most bad software is actually bad.
Wireframes
Low-fidelity screens for every state, agreed before visual design so that structural changes are cheap and are made on purpose rather than at the last minute.
Visual design
Layout, type, colour, iconography and imagery applied within your brand, at the real dimensions of the target device rather than at a convenient canvas size.
Interactive prototype
A clickable build of the main journeys for review and user testing, which is the artefact that gets a stakeholder decision faster than any presentation.
Design system
Components with every state, spacing and type scales, colour tokens and usage rules, delivered so a developer implements a rule once and later screens inherit it.
Accessibility review
Contrast, touch-target size, focus order, keyboard operation and text alternatives checked during design, when they are still a layout decision rather than a remediation project.
Developer handover
Specifications, assets and redlines in a form developers can work from, plus availability during the build. Design that ends at the file hand-off tends to arrive in production changed beyond recognition.
Designing for terminals, floors and control rooms
Most design advice assumes a person holding a phone, at leisure, with the option to leave and come back. Much of our work has none of those conditions, and the constraints change the answers rather than the aesthetics.
A public terminal is used once by somebody who cannot ask for help, standing up, possibly in a queue, sometimes in a second language. Targets are large, the sequence is short, every screen states where the person is and what happens next, and an error has to say what to do rather than what went wrong. Screens are designed at the mounting height and the exact resolution of the enclosure, and tested with the peripherals attached, because a print delay or a card-terminal prompt is part of the interface whether the designer planned it or not.
An operations console is the opposite: a specialist who will use it thousands of times and wants density, keyboard operation, bulk actions and stable positions far more than whitespace. Designing one as if it were the other is the most common failure we are asked to repair.
What comes out of a design stage
What we are asked to design
Six kinds of interface, each with a different centre of gravity, and each of them attached to something we also build.
Self-service kiosk journeys
Short, forgiving sequences for the public, drawn at the enclosure's real resolution and tested with the printer and reader attached, as in our visitor management and food ordering kiosk journeys. See also kiosk application development.
Operations consoles and dashboards
Density, filters, bulk actions and stable layouts for people who live in the screen, such as the console behind our kiosk management platform.
Enterprise web applications
Forms, approvals, tables and reports designed so a specialist can move quickly and a new joiner can still find things. Built by our web application team.
Mobile and tablet apps
One-handed use, thumb reach, offline states and platform conventions, for the apps our Android and iOS practice builds.
Large-screen and signage layouts
Legibility at distance, contrast in a bright hall and content that reads in three seconds, for the display work in our Android TV and signage service.
Product and marketing interfaces
Storefronts and public sites where the design has to serve both a brand and a search engine, alongside our website design and development work.
Engagement, ownership and what happens next
Design is usually the first stage of a build with us, and in that case it is scoped inside the project rather than sold separately. It can also be taken on its own: a research and design engagement that produces wireframes, a prototype and a design system for your own developers, or another vendor's, to implement. Because the scope of a design stage is knowable once the screen inventory is agreed, it is often quoted as a fixed engagement. Every engagement is scoped and quoted individually after a conversation about the users and the screens; we publish no rates or standard durations, and any such figure attributed to us has not come from us.
You own the output. Source files, exported assets, the prototype and the design system documentation are handed over, and the system is written so your team can extend it without us. We would rather the components outlive the engagement than be a dependency on it.
What happens after design matters as much as the design. Where we also build the software, the same designers stay available through development to resolve the cases a prototype never covers, and the design system is enforced in the implemented components. Where another team builds it, we recommend a review at the end of the build against the system, and that review can be arranged under our software consulting and AMC support service. Notes on interface work for terminals and operational software appear on the AtashiTech blog.
Talk to a UI/UX design company that also ships the software
Tell us who has to use the thing, where they will be standing when they do, and what they are trying to finish. We will come back with the questions that matter and a scoped proposal. You can also browse our development services or see what we have built on the solutions page.
Frequently asked questions
Related services
.NET Enterprise Desktop (EXE) Apps
Windows desktop and line-of-business apps in .NET.
Android & iOS App Development
Native and cross-platform mobile apps for phones.
Android TV & Smart TV Apps
Android TV and smart-TV apps and signage players.
Cloud, DevOps & Integration
Azure/AWS, CI/CD and API integration.