Reviewing User Interfaces

Lara Aigmüller

Posted in How We Work , Portfolio

One of my favorite things to do is clicking through websites and apps and finding bugs and problems. (I do this regularly, even if I don't want or need to, but it seems, the web is pretty broken these days. 🫠) Experience taught me that clients are not happy to hear when their products are not working well (and to pay for this information), so unfortunately, this is just a small part of my day-to-day work. 😄

Nonetheless, I had the pleasure of creating UI/UX (user interface/user experience) audits for some companies already. The goal was to investigate an existing product and note everything that caught my attention (in a negative way). We agreed on a fixed timeframe in advance to stay within the available budget. Sometimes, we defined a specific user journey or a dedicated part of the product I should have a closer look at.

In this article, I’d like to share my approach on how I create such reports, what I focus on and how I structure my findings.

The first impression

When I open a site I’ve never seen before, I first have a look around and try to get an overall impression—see what it is all about. Often, my mind is instantly generating questions. That can be overwhelming sometimes. 🤯

So in the beginning, my work feels a bit unstructured because my head goes like this:

  • Oh, there are images, let’s see if there is an alternative text as well.
  • There is animation everywhere, what if the user prefers reduced or no motion at all, are these settings taken into account?
  • The font sizes don’t look well-balanced, and there is a box where the text just does not fit.
  • Oh no, I can scroll horizontally, what could be the problem here? Ah, there is an embedded video that is too wide…
  • I see different shades of the primary color, I guess that’s not intended.
  • There are a lot of links and buttons on the page, are they accessible via keyboard?
  • The layout in this section doesn’t feel right, let’s have a look at the code and see how this works on smaller viewports.
  • There is text on top of a header image I can hardly read, and the light text color below has too little contrast.
  • There are different navigation levels, but I don't get how they are connected.
  • and it goes on and on…

When I start interacting with the page, for example, by following the navigation, I think about content hierarchy as well as interactive states of elements, accessibility, and more.

I resize the browser window to see how the page behaves on different viewport sizes. Additionally, I open the same pages on a tablet and my smartphone.

Structuring my thoughts

As soon as I find strange or broken things, I take screenshots or screen recordings and change the filename to something that later helps me remember why I took it in the first place. Additionally, I create a document where I add unstructured notes, sometimes with references to these screenshots and recordings.

After letting the first impression settle, I start with a first version of an outline for the final report. The structure depends on the focus of the report.

These are sections and topics that I always try to cover:

  • Content hierarchy: Do I understand the navigation and how pages are connected? Do I find things where I expect them to be? Is the content on a page well-structured by using sections and headlines?
  • Colors and typography: Are colors used consistently? Is the color contrast good enough (accessible)? Is text readable?
  • Interaction: Do I recognize interactive elements? What happens when I hover over items with the mouse? Do items have focus states? Can I access interactive elements via the keyboard? How is interaction implemented for touch devices?
  • Layout and responsiveness: When resizing the window, does the content still look good, or are there places on the page where the layout breaks?
  • System state and user feedback: When interacting with the site or app, do I always know what's going on?

When there are certain pages and/or user journeys (e.g. a checkout process) that I should investigate, I start the final report with these and list all issues I could find. I summarize recurring problems in their own section. In the end, I usually add everything else I stumbled upon and try to structure it either by feature or by category (e.g., all problems related to colors, interactive states, layout, …).

The big three: recurring problems

Most of the problems I usually find in all sites and apps I test can be added to one of these three categories:

  • Inconsistency
  • Layout and responsiveness
  • Accessibility

Inconsistency

When a product grows and new features are added, and when several designers and developers work on the same application, it's unavoidable that inconsistencies are introduced. This could be different colors for the same thing, different styles for the same component in different parts of the app, different icon styles, different font weights, different wording, and so on…

The reason could be that when new features are built, outdated/old code is copy-pasted as a starting point for something new and so these legacy snippets never disappear from the codebase. Another common problem is when one product is actually a combination of two or more different applications that are not perfectly aligned when it comes to styles, components, and patterns.

Layout and responsiveness

I've never audited an application that looked great on all viewport sizes I tested. There are often issues with horizontal scroll bars that should not be there, items that have set fixed dimensions and break the layout when there's not enough space for them, content that covers other content because of z-index issues…—I could go on here for some minutes.

One reason for these problems is when applications grew over time without refactoring of styles and layouts via newer and more modern CSS features. Often when new features are built, layout and styling code are simply added on top; a good starting point would be to look at the bigger picture first and maybe even remove older code to build something more robust and responsive from scratch.

Accessibility

Fortunately, this topic gains more and more visibility, especially because of laws and regulations like, for example, the European Accessibility Act (EAA) which took effect at the end of June this year in Austria as "Barrierefreiheitsgesetz".

Many people still believe that accessible websites and applications are for blind people using a screen reader, but it’s much more than that! Without going into much detail here, (because this could be a blog post on its own) let me clarify something essential: making a product accessible means making it better for all users. Everyone benefits from good accessibility. ✨

When I create a UI/UX audit, I always stumble upon issues with accessibility, which are most likely also problems with user experience. The most common are: missing/useless alternative texts and labels for non-textual content, animations without the option to stop them, bad color contrast, small text and small click targets, and no focus states for interactive elements.

The final report

Ultimately, amidst screenshots, screen recordings, unstructured notes, structured notes, my head is spinning… there’s so much more to discover, but the time limit has been reached and a report needs to be written, summarizing all findings.

I start with a general introduction and the initial requests and goals of the client. In the beginning I summarize the most severe problems I encountered. I continue with features, views, and user journeys and describe issues I had. These not only include UI problems but also strange or broken behavior of, for instance, a checkout process and forms or a navigation pattern I don’t understand. Following that, a collection of different issues, structured by components or topic.

The cherry on top: when obvious or when the patterns and problems are not too complex, I even add suggestions for improvements and how bugs could be fixed. Not only do I take screenshots of the UI, but I also look at the code in the browser’s developer tools and highlight broken HTML or CSS code I could find. 🍒

Let’s make the web a better place

You need some help with the user interface of a website or application? You are not sure whether your product is accessible? You need fresh eyes from outside the development process, someone who is unbiased and looks at certain features with a clean slate? Let me know, I’d be glad to help making the web a better place and a little bit more accessible. 😉

Any thoughts or comments?

Say hello on Mastodon or contact us via email or contact form!