Services / Product Design
Product Design
We design software for the people who use it for eight hours a day, including clinical staff, dispatchers, property managers, and buyers. The measure is whether the work gets faster, not whether the screens win awards.
Systems we have designed
Delivered products rather than capability claims. The case studies carry the details.
- Clinical and practice management
- Property and building management
- Operational dashboards and reporting
Technology
How the design work is delivered
Design and prototyping
- Figma
- Interactive prototypes
- Design tokens
- Component libraries
Research and validation
- User interviews
- Workflow mapping
- Usability testing
- Current-state audits
Accessibility
- WCAG 2.1 AA
- Keyboard operation
- Screen reader support
- Contrast auditing
Handoff to engineering
- Annotated specs
- React and Angular component mapping
- Tailwind CSS
- Implementation review
Most of the software we design is not consumer software. It is the system a clinic runs appointments on, the screen a dispatcher watches all afternoon, the interface a property manager uses to log a work order. In that context design is measured by how quickly experienced people get through their work, and by how few mistakes the interface invites. Decoration is beside the point.
Our process starts by learning the operation. We interview the people who will use the system, watch how they work today, map the flows including the edge cases, then prototype and test before development begins. That order matters commercially as much as it does for usability, since a flow corrected in a prototype costs a fraction of the same flow rebuilt in code.
Because we build the systems we design, the handover is not a stack of files and good luck. The same team carries decisions through to production and reviews the finished screens against the design. What you keep at the end is a documented design system in Figma, so the next release extends the product rather than reinventing it.
What product design does for an operational system
Fewer steps in the daily work
We map the workflow before designing screens, then remove the clicks, the duplicate entry, and the switching between systems that consume the day.
Interfaces per role
A dispatcher, a finance lead, and an executive need different views of the same system. Designing per role beats one screen that half satisfies everybody.
Validated before development
Clickable prototypes tested with real users, so scope and flow are confirmed while changes are still cheap.
A design system you keep
A documented component library in Figma, so the product stays consistent as it grows and future work does not restart from scratch.
Accessible by default
Contrast, keyboard operation, and screen reader support designed in from the start, which matters for regulated sectors and for anyone using the system in poor conditions.
Our product design process
- 1
Discovery and Research
Learning the work before proposing an interface.
Stakeholder Interviews
Understanding the business goals, the constraints, and what a successful outcome actually looks like.
User Research
Talking to the people who will use the system daily, and watching how they work today.
Current State Audit
Reviewing existing flows and locating the friction before redesigning anything.
- 2
Information Architecture
Deciding structure before appearance.
User Flows
Mapping every path through the system, including the edge cases and error states that get skipped.
Content Hierarchy
Establishing what information matters most in each context and when it should surface.
- 3
Prototyping and Testing
Confirming the design while changes are still cheap.
Wireframes
Fast, low-fidelity screens for exploring layout and flow options.
Interactive Prototype
A clickable Figma prototype for usability testing and sign-off.
Usability Testing
Real users completing real tasks, so friction is found before development begins.
- 4
Visual Design
Detail in service of the task.
Interface Design
High-fidelity screens with your brand applied across color, typography, iconography, and motion.
Design System
A complete component library and documentation your engineers can build from without guessing.
- 5
Developer Handoff
Specifications precise enough to build from.
Annotated Specs
Spacing, states, responsive behavior, and interactions documented for every component.
Implementation Support
We stay involved during development to review builds against the design before differences become bugs.
Why RothTech
Design is the cheapest place to fix a system and the most expensive place to skip. Every flow confirmed in a prototype is a flow that does not get rebuilt in code. Because we also build the systems we design, the handover is not a document thrown over a wall. The same team carries a decision from research through production, and stays involved to check that what shipped matches what was agreed.
Frequently Asked Questions
Yes, design is available as its own engagement, scoped and quoted before you commit. Cost is driven by the number of distinct roles and flows in the system rather than by screen count, since a system serving four roles takes more research and more design than one serving a single role. Where design runs into a build we deliver, the two are quoted together and the design phase reduces the build cost.
Both, and redesign is the more common request. It usually starts with an audit of the current flows and the complaints your team already knows about, then targets the highest friction paths first. Several systems in our case studies were redesigns of software the business had outgrown rather than new products.
A documented design system in Figma, high-fidelity screens for every flow including error and empty states, an interactive prototype, and annotated specifications your engineers can build from. If another team is doing the development, that package is written to be handed over cleanly.
A permanent senior team in Osijek, Croatia, with designers who work alongside the engineers who build these systems. The same people are available later when the product grows and the design system needs extending.
We design to WCAG 2.1 AA by default, covering contrast, keyboard operation, focus states, and screen reader support. It is a requirement in regulated sectors, it reduces legal exposure, and it makes systems easier to use in the poor lighting and awkward conditions where operational software often gets used.