UI issues example

In this comprehensive example, you will see how a lack of attention to consistency, context and simplicity can affect a user's overall experience. Watch the video to learn more. 

This next example shows — in one illustration — many spacing and alignment issues, as well as additional problems. In this example, at least three central principles — consistency, context, and simplicity — appear to have been ignored.

Before we break down the UI issues, let’s understand what’s happening from a UX perspective. This is a reasonably simple workflow that involves one user and a Pega system. The system provides a service from U+Bank to the bank’s customers. The user is a treasurer for a company that is a customer of U+ Bank. This is a non-technical user.

The general workflow is: The Pega system detects a possible issue with a payment. The Pega system notifies the treasurer of the possible issue and directs the treasurer to review the payment. The treasurer chooses to approve the payment or stop the payment.

From a UX perspective, the critical pieces are providing a notification method that will reach the treasurer and has enough pertinent information to motivate the treasurer to quickly review the possible issue, and which can immediately link the treasurer to the review screen. We should provide multiple notifications, certainly one notification within the treasurer’s portal, and at least another via email, phone, or other methods outside the treasurer’s portal.

We’re not going to focus on the design of this email, but the essentials we’ve covered in this module — proper alignment and spacing, correct layout, and content order — apply to any use-case, including email. You’ll notice that the critical data related to this payment is clearly shown, and there is a clear primary action which links to the dashboard of the treasurer portal.

On the treasurer dashboard, we should now see a clear call to action — and we do at the top of the screen. By clicking on one of the Review buttons, we get to our example UI.

The first thing I notice is the use of the modal, which is odd. A modal should be used to present a critical action to a user, which also blocks the use of the rest of the app until the action is completed. There are no obvious actions to take here. Until an obvious action is added to this UI, presenting read-only data in a modal ignores the principle of consistency, as it is not consistent with standard usage. Even if not in a modal, this UI needs a primary action. 

Because the UI is embedded in a modal, the UI is quite squished. The context of the size of the modal has been ignored. Could the content in the sidebar move underneath the transaction details?

Notice a block of content in the sidebar is meant to show “articles viewed," but that doesn’t appear to have anything to do with this workflow.

It should be removed. Indeed, it’s not clear that any of the content in the sidebar is necessary.

Removing the sidebar helps with the squished transaction data. 

I see many issues with headings. There’s no primary heading on the modal, which is critical for the user to understand the context of this UI.

As we’ve covered, the title of a modal is the equivalent of the title of a page, and so should be capitalized as such. 

That said, this workflow, if launched from the portal dashboard, should not present in a modal at all. Let’s take it out of the modal.

I see a lot of spacing problems. We often see spacing problems with embedded sections of UI, which I suspect this is. The embedded UI—shown here—has quite a bit of spacing around it and is embedded in another UI, which also has spacing. This incorrectly doubles the spacing in the final experience. 

Best practice would be not to use any spacing—or a heading for that matter—on any UI which will be embedded. It’s better to think of the embedded UI as “only the data” and not to include final presentation elements such as card styling or headings.

We can redesign this UI to be both easier to read and understood, and also tighter, allowing the user to see more information without additional mouse or keyboard work. 

One option would be to move the data to a tabular structure, making it easy to scan (and sort, filter). This assumes that the treasurer needs to compare data such as the amount of the transactions. We would need to research this workflow and learn whether data comparison like this is really necessary, or helpful. While this display is tighter, it does demand that the user checks the table heading to analyze the data, rather than showing information inline.

If we do present this as tabular data, we need to make sure that numbers and their corresponding column headings are correctly justified.

We now need to add actions, which were missing from the start. 

This could work but might need better protection from a hasty error. In which case, we should add an additional step to confirm the user’s choice. This also is necessary if additional user choices are needed.

We could present this same data in non-tabular form. This version of the design is less compact but might be more consistent with the surrounding web portal, and squeezes a bit more data into each transaction. It also adds a clear explanation of why the payment was flagged, and — possibility — better highlights which transaction is the problem. Notice how the explanation can be hidden, thus giving more room for the transaction data, if the user prefers.

In either version of the design, we’ve radically improved the experience.

We’ve now covered how we identify frequently encountered UI issues, and how to address them.

It’s up to all of us to focus on the quality of the software we deliver. Great user experience is not just the domain of UX professionals; it’s everyone’s responsibility to see issues and to address them.

Check your knowledge with the following interaction.