UX research
Interviews, task analysis and observation in the environment where the work actually happens.
In plain terms
Design that survives contact with production.
Business software is rarely used in comfortable conditions. It runs on a second monitor, in a noisy room, at the end of a shift, sometimes with gloves on. Design decisions that ignore this do not fail loudly — they fail through workarounds, side spreadsheets, and training costs nobody attributes to the interface.
We start with users and their working context. Who does what, under what pressure, with which tools already in place. Screens come after that, and they come with their edge cases: empty states, degraded connectivity, errors the operator did not cause.
When the product requires it, we deliver a working design system — components, states, tokens and documentation. Your developers can build from it and extend it independently.
What we do
From research to design system.
Information architecture
Navigation, task flows and content structure, settled before any visual work begins.
UI design
Screens, states and edge cases for web, mobile and embedded displays.
Design systems
Components, tokens and documentation, delivered in Figma and in code.
Accessibility
WCAG 2.2 criteria, keyboard paths, contrast ratios and focus states, verified rather than assumed.
Prototyping & testing
Clickable prototypes, usability sessions, and iterations measured against a task, not an opinion.
In figures
A tooling-backed product design practice.
FigmaSingle design source
UX/UIResearch to interface
TokensShared with code
WCAG 2.2Accessibility baseline
Frequently asked questions
Everything about RDMC product design & UX/UI.
Do we need developers on our side?
No. We can hand over Figma files with a documented design system, or work directly in your codebase alongside RDMC developers. The choice depends on who will maintain the product afterwards.
Can you redesign an existing application?
Yes. We begin with the current product and its users before proposing anything — a redesign that ignores existing habits creates more friction than it removes. Work can be staged screen by screen, without freezing your roadmap.
Do you cover mobile and embedded displays?
Yes. The constraints differ — screen size, input method, glare, latency, gloves — and they are treated as design inputs rather than adaptations made at the end.
What do we own at the end?
The design files, the design system, and its documentation. No proprietary format, no dependency on RDMC to keep the product moving.
Complementary services