A Comprehensive UI/UX Design Guide to Designing Digital Products Around the User

Most digital products are unsuccessful not due to bad coding; but rather, they are unsuccessful because a user opens the product, does not know how to continue using the product, and ultimately leaves the product. The space between what a product development team creates and how a user can utilize the product is the reason UI/UX design was created. This guide explains how this process operates, how to execute the process cost-effectively, and why many product development teams fail in their execution of this process.

The way a digital product looks and acts, so that users may accomplish their goals with minimal frustration, is shaped by UI/UX design. User Experience (UX) encompasses all aspects of the user's experience with the product: who the users are, their intentions, and the quality of their experiences throughout the entire process. User Interface (UI), on the other hand, represents the visual aspects of the product: layout, typography, color, buttons and other components, along with the various states that can occur within the product.

The reason why it is difficult to differentiate between these two terms is that they usually appear in tandem. However, you can use this simple trick to help you separate them.

If you have an attractive screen over a complicated flow, then you are still creating a complicated product. If you have a well-thought out flow that has a poorly designed visual, you will lose users' confidence before they can experience what makes your product so great.

Because sketches are less expensive to create than to make changes to after they're in production, and people make snap judgments. User-centered design allows for testing of assumptions with real users both prior to and during the building process, as opposed to making changes to the live code once it has been launched.

Users show you just how unforgiving they will be with speed. According to research conducted by Google, if a page takes more than three seconds to load, 53% of all mobile visits to that page are abandoned. Nobody reports this to anyone; they simply exit the site, and you see the results of their decision in your analytics as an unexplained decline in conversions.

The main reason for doing a business case is generally about reducing the number of people who abandon their sign-ups/checkouts, reducing the number of customer service requests that are received, and having to redo less of your work since you got it right the first time.

• Simplicity rather than complexity: When a person must pause to interpret what an icon or label represents, the design has somewhat failed.
• Repeatability: Same way to do things, same appearance, same location. A shared component library helps achieve repeatability.
• Feedback: Each time a user interacts with a feature or submits information, they need to know if their action was successful.
• Accessibility: Designing for accessibility doesn't mean adding on; it means designing with contrast, text size, keyboard support, and screen reader labels. We should use WCAG 2.2 as our baseline for design.
• Minimal cognitive effort: Display the current information required; conceal all other data; and avoid making users recall previously viewed information on each screen.

A great process is a closed-loop system, not a hand-off. At Hadrus Digital, we utilize "The Hadrus Method" — Diagnose, Architect, Build, Compound. These stages were named by us, however, they should be familiar to anyone who has developed and released a product.

Start with the issue, not the screen. Speak to stakeholders regarding their objectives, speak with a few of your actual users, review the support mailbox, and identify the areas in your analytics that users are dropping out. The resulting product is a plain language description of the issue that all parties agree on. If you cannot describe the issue in two sentences, then you are not prepared to begin designing.

Now you will develop the structural elements of your site: User Flows, Information Architecture, Wireframes, and the basic components of your design system (Type Scale, Spacing, and Color Tokens). At this stage in the process, your wireframes should be "ugly". It is beneficial for them to be "ugly", as it prevents discussion regarding the specific hue of blue that will be used until after the initial development has occurred.

The end-to-end user experience, including all of the buttons that can be clicked, as well as the specifications required for the developers to create it, is complete. At this point, the designers and engineers have likely had communication; however, if they are still making introductions when the handoff occurs, that is too late. There will be a greater amount of time saved through naming components consistently across both the design and the code than with any other plug-in.

Most guides don't go beyond this point. At this time, you have launched your product, so you are now testing it with real users; reviewing the data collected through analytics; conducting short-term experiments; and incorporating your findings into your design system. With each round of testing/reviewing/experimenting/incorporating, you will be able to do more for less cost, and the next round will be better than the last. Launching a product is a milestone on your journey toward success, not the end of that journey.

No lab is necessary; five discussions with individuals that match your target audience should reveal many of the larger issues. The Nielsen Norman Group has been making the same claim for years concerning small numbers of usability tests. Those five conversations should be supplemented by other low-cost sources you currently use such as session recordings, analytics data, support tickets, and competing product teardowns (two to three).

A common error is waiting until all the research has been completed before starting. Instead of waiting for perfection in your research, start with a limited number of participants, make improvements based upon your findings and then do the next group.

A design system provides a common, reusable set of components, rules, and guidelines for maintaining a consistent user experience (UX) as products grow. Most likely, a design system will be needed sooner rather than later, particularly when there are multiple designers or developers working on the product, or if the product is being released on multiple platforms.

Templates can be great for getting started quickly; however, they can limit your ability to stand out from other brands. Our post, "UI/UX Design vs. Generic Templates: Why Custom Design Systems Win," discusses some of the advantages and disadvantages associated with using templates.

Choose which performance measures you will use before you create the system, not after. Examples of common performance measures include:

• Task Completion Rate – Are users able to complete the primary actions?
• Time on Task – How much time did they spend completing the tasks?
• Drop off: where does a user exit the conversion process?
• The System Usability Scale (SUS) is a 10-question questionnaire that has been designed as a method for assessing the usability of a product or service. The SUS is scored on a scale from 0 to 100.
• Support Volume: Do I see many of the same questions over and over?

Numbers let you know what is wrong; watching people use the product lets you know why it's wrong.

• Designing based on the opinion of your team as opposed to what you know about how people use your product.
• Skipping the research process due to "knowing who your customers are."
• Treating accessibility as a final check rather than an initial design requirement.
• Polishing only the first screen of the app; ignoring errors, empty states, and loading states.
• Hand over a completed design, and then do not return to that design once the product launches.

The frequency of your need for design will determine which option is best. An in-house team is appropriate if you constantly require design work that supports the core of your product. However, if your design needs occur occasionally (such as a new product launch, a complete redesign, or a design system development), then a design studio provides senior level expertise at a reduced cost than hiring someone full-time. Agencies also utilize studios as "white label" partners to supplement their existing staff. Regardless of the route you choose to pursue, ask to observe how the design team interacts with development teams rather than simply reviewing examples of completed designs.

Costs and timelines are determined by the size and complexity of your project; therefore, you should question any cost/timeline estimates provided prior to discussing your project's specific requirements. A simple audit can usually be completed within 2 weeks. A complete product design including a design system typically takes several months.

When you find a user flow that is critical to the success of your product (such as sign-up, checkout, or onboarding), pretend you've never used the application before. Then use the application. Document every single time you pause while using the app. The list of times you paused represents the initial design brief for that user flow.