UI/UX and product design
Interface and product design for software people use all day — websites, applications, dashboards and mobile.
- Dashboard design
- Mobile UI/UX
- Prototyping
- Design systems
- Accessibility
- Customer portals
- Code
- UXD
- Class
- C · Under 6 months
- Engagement
- TYPICAL 1-3 MONTHS · DESIGN SPRINT
- Stages
- 04
- Deliverables
- 06
- Sections
- 06
Overview
Design for internal software is a different discipline from design for a landing page, and treating them the same is why so many enterprise applications look modern and remain unusable. Software someone operates for seven hours a day should be dense, fast to scan, keyboard-driven and boring in the specific way that expert tools are boring. We design for that, we prototype before anyone builds, and we test with the people who will actually use it. Beacon Education Trust’s admissions dashboard cut the time to complete a review from nine minutes to three, mostly by removing things.
Benefits
05 pointsPrototypes tested with real users before a line of production code exists — the cheapest place to be wrong.
A design system rather than a set of screens: tokens, components and states, so the twentieth screen costs a fraction of the first and stays consistent.
Accessibility designed rather than remediated. Contrast, focus order, target size and error handling are decided at design time, where they are free.
Every state drawn, including the ones that get skipped: empty, loading, error, permission-denied, and the record with a name three times longer than the mock.
Design files that a developer can build from without a meeting — spacing, behaviour and breakpoints specified rather than implied.
Workflow
04 stagesUnderstand the job
Interviews and observation with the people who will use it. For internal tools, we time the current task — that number is the target the design has to beat.
Structure before surface
Information architecture, task flows and low-fidelity layouts. Arguments about colour are cheap and arguments about structure are expensive, so structure is settled first.
Prototype and test
An interactive prototype tested with five to eight real users. Five is enough to find the majority of usability problems and small enough to run again after the fix.
Design system and specification
Tokens, components, states and the rules that govern them, documented so the build does not have to guess and the next feature does not restart the conversation.
Deliverables
06 items- Design files covering every screen and every state, with spacing and behaviour specified.
- Interactive prototype of the primary flows.
- Usability test findings with recordings, ranked by severity.
- Design system: tokens, component library and usage rules, in a form developers can consume.
- Accessibility annotations — focus order, labels, contrast ratios, target sizes.
- Before-and-after task timings where an existing tool is being replaced.
Questions
03 entriesYes, and normally we should. We take the brand as given and build the product design system underneath it — brand guidelines rarely specify a data table, a filter panel or a validation state, and that is most of what an application is.
For a straightforward internal form, no. For anything a team uses all day, or anything a customer chooses to use, the design pass pays for itself in rework avoided — a change to a prototype costs an hour and the same change after release costs a sprint and a migration.
By deciding what decision it supports and removing everything that does not serve it. Dense is fine — expert users prefer density — but undifferentiated is not. Hierarchy, tabular alignment and restraint with colour do more for a dashboard than any chart library.
Book a consultation
01 locationsComplete IT, software and AI solutions
- Indore, India