UI/UX Design

UX (user experience) is about how easily a product helps users get their task done. UI (user interface) is the part of that experience you see on screen: layout, color, typography and components. A checkout screen shows the distinction best.

The number of steps, what the error message says and where a user whose card is declined goes next are UX decisions. The button color, field alignment and font size are UI decisions.

If the flow is wrong, a beautiful screen will not fix it. If the flow is right, a cluttered screen still costs trust. That is why the two are handled in the same process. Large teams may split the roles, while in small teams a single designer covers both.

User experience design defines which problem the product will solve and the steps a user takes to complete a task. UX design work starts with user interviews, product data and a competitor review.

Its outputs are structural rather than visual: information architecture, user flows, wireframes and content priority. A good flow covers not only the happy path but also errors, empty states, unauthorized access and abandoned actions.

These states raise the most questions during development. Digitruva writes them into the flow map from the start, so developers do not have to make decisions at their screens. On a live product, improvements based on user behavior inform the next steps.

A wireframe is a screen's skeleton before visual design. It shows what content goes where and which functions take priority, without any color or typography decisions. A prototype links screens together so the product can be tried out as if it were in use.

A low-fidelity prototype can be made from wireframes, while a high-fidelity prototype in Figma comes close to the real interface. The real difference is the question each one answers. A wireframe shows what should be on the screen, and a prototype shows whether the user can complete the task.

Digitruva tests core tasks with users on the prototype and shares the findings before development starts. This order matters because changing a flow after the code is written costs more.

The W3C's WCAG 2.2 contrast criterion requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text at level AA. Large text is roughly 24 pixels and up, or about 18.7 pixels and up in bold.

Under the non-text contrast criterion, interface elements such as form field borders and icons also need 3:1 against adjacent colors. Under the target size criterion, click and touch targets must be at least 24 x 24 CSS pixels at level AA, with exceptions such as sufficient spacing.

Under the keyboard criterion, functions must also be usable with a keyboard. These criteria should be tested in the design file before anything moves to code, because contrast problems usually come from the color palette. Focus and error states should be drawn separately too, or they end up being guessed during development.

Mobile app design differs more in context of use than in screen size. Users act one-handed, in short bursts and often on an unstable connection.

So primary actions go in easy-to-reach areas, form fields are cut down and what happens when the connection drops is designed in. iOS and Android each carry their own conventions. Apple's Human Interface Guidelines and Google's Material Design guidelines define navigation and component patterns.

Instead of copying the same screen to both platforms, the shared structure is kept and platform differences are adapted. Permission requests and notifications are part of the flow too. If the interface belongs to a site that presents the company, the work falls under corporate website design.

The best time to set up a design system is after the visual language has been approved on the core screens, not from the very first screen. A design system is the shared source where color, typography, spacing and components are gathered in one place along with their rules, and building a full library up front is usually premature.

At that point, recurring pieces are turned into components. For a product that has already grown, the existing screens are inventoried first, and different buttons that do the same job are merged.

In Figma, every component should have default, hover, focus, error and loading states defined. Digitruva hands the file to the development team with these states and measurements. If color and typography values come from an existing brand, interface consistency with your brand identity should be checked from the start.