The domain shapes the design. In FinTech the priorities are trust and error prevention, which means confirming amounts, explaining fees and making irreversible actions feel irreversible. MedTech needs clarity for people who may be tired or unwell. IoT products have to show device state truthfully, including when a device is offline. And LegalTech tools are judged largely on how well they handle long, dense documents.<\/p>\n
Research that changes decisions<\/h2>\n
Before we draw anything, we look at what the product needs to achieve for the business and for the people using it. Research is only worth doing if it can change a decision, so we size it to the questions that are really open.<\/p>\n
- \n
- Stakeholder interviews surface goals, constraints and the business rules that will shape every screen, and our business analysts document them as we go.<\/li>\n
- Interviews with a handful of users from each main audience focus on what they do today rather than what they say they want.<\/li>\n
- Existing evidence often shows where people get stuck before we run a single session. Analytics funnels, support tickets, app store reviews and sales call notes are all worth reading.<\/li>\n
- A heuristic review of your product and your competitors separates the conventions users expect from the patterns worth rethinking.<\/li>\n<\/ul>\n
What comes out is short and practical: the main user groups, the tasks they need to complete, the assumptions still to be tested and a prioritized list of problems. We write it so the whole team will actually read it.<\/p>\n
Flows, information architecture and prototypes<\/h2>\n
We design flows before screens. A user flow maps every step, decision and branch in a task such as signing up, adding a payment method or inviting a teammate. It’s the cheapest place to find missing steps, dead ends and permission problems, and it shows engineers early on which states they’ll need to support.<\/p>\n
![\"A](\"https:\/\/inferne.com\/blog\/wp-content\/uploads\/2026\/09\/ui-ux-design-flows-900x600.webp\")
<\/figure>\nInformation architecture comes next: what lives where, what it’s called and how people move between sections. For content-heavy products we use card sorting to learn how users group things. Tree testing then checks whether they can find them in a proposed navigation, before any visual design exists.<\/p>\n
Then come wireframes and prototypes, deliberately in that order. Low-fidelity wireframes keep the discussion on structure instead of colors. Clickable prototypes in Figma let people experience the flow on a real phone or laptop. When the interaction itself is the risk, as with a gesture-heavy mobile screen or a data grid with thousands of rows, we prototype in code, because a static mockup can’t tell you how it will feel.<\/p>\n
Throughout, we design with real content and with every state a screen can be in. That includes empty, loading, partial, error, offline and no-permission states, very long names, and translated text that runs longer than the original. Products tend to break in exactly these places, and designing for them costs far less than patching them later.<\/p>\n
Usability testing and accessibility<\/h2>\n
We test designs with real users before they’re built and again after launch. Small rounds with a handful of participants are enough to expose the serious problems, and several quick rounds between iterations teach you more than one large study at the end.<\/p>\n
- \n
- Moderated sessions<\/strong>, remote or in person, where participants work through realistic tasks and think aloud.<\/li>\n
- Unmoderated tests<\/strong> for quick checks on a specific screen, label or piece of copy.<\/li>\n
- First-click and tree tests<\/strong> for navigation and naming questions.<\/li>\n
- Post-launch evidence<\/strong> from funnel analytics and, where your privacy policy allows, session recordings with sensitive fields masked.<\/li>\n<\/ul>\n
We treat accessibility as part of the design rather than an audit at the end, with WCAG as the reference. In practice that means sufficient color contrast, visible focus states, touch targets sized for real thumbs and labels that VoiceOver and TalkBack can announce. Layouts have to survive larger text sizes, and motion has to respect the reduced-motion setting. Accessible products are easier for everyone to use, and in many markets accessibility is a legal expectation as well.<\/p>\n
Design systems and the handoff to engineering<\/h2>\n
A design system is the shared vocabulary between design and engineering. It has tokens for color, typography, spacing, radius and elevation, a library of components with their variants and states, and guidance on when to use each. It keeps a growing product consistent and makes new screens faster to design and build.<\/p>\n
![\"Design](\"https:\/\/inferne.com\/blog\/wp-content\/uploads\/2026\/09\/ui-ux-design-design-system-900x600.webp\")
<\/figure>\nWe start from the platform, following Apple’s Human Interface Guidelines and Material Design where users expect native behavior, and let the brand come through in color, type, illustration and tone. The identity from our branding work<\/a>, or your existing one, becomes tokens rather than hard-coded values. That’s what makes dark mode, theming and accessibility fixes manageable later. Components in Figma map one-to-one to components in code, be they SwiftUI views, Jetpack Compose composables or React components.<\/p>\n
All of this has a cost. A full design system is real overhead, and an early product that changes shape every week doesn’t need one. For an MVP we set up tokens and a small core of components, then grow the system as patterns repeat.<\/p>\n
Many of the gaps between an approved design and shipped software open up at the handoff, so we make the handoff continuous:<\/p>\n
- \n
- Engineers review flows and prototypes early, while changes are cheap, and flag anything costly or risky on a given platform.<\/li>\n
- Every screen is annotated with its behavior: states, transitions, validation rules, error messages and the analytics events to track.<\/li>\n
- Business analysts turn flows into acceptance criteria, and our QA testers check builds against them.<\/li>\n
- Designers review builds on real devices before release, and visual defects get logged like any other bug.<\/li>\n<\/ul>\n
- Unmoderated tests<\/strong> for quick checks on a specific screen, label or piece of copy.<\/li>\n
- Moderated sessions<\/strong>, remote or in person, where participants work through realistic tasks and think aloud.<\/li>\n