How to conduct a design review?
Design reviews can interrogate an entire application or be restricted to a certain number of pages. The goal of a design review is to
essentially catalogue as many points of improvement as possible. This then allows the product owner to prioritise which items should be
fixed first. At WorkingMouse designers perform these reviews on request, but product owners and other members of the product team are quite
capable of performing the reviews independently to an extent.
Set up a review document
The first thing to do is set up a review document where findings and suggestions can be found in one central location. Make sure that it is
accessible for everyone in the team. A table or spreadsheet is the easiest way to achieve this. You will need the following columns at a
minimum: name (to identify the issue), description (to provide a summary of what the problem is), recommendation (an overview of how the
problem could be tackled) and priority (to address the urgency of the problem). It's also helpful to log when each recommendation was made
so that you can return to the document at a later point and take note of which items have had action taken on them.
Examine each workflow
Once you are ready to start reviewing, take the time to go through the application and examine the different workflows that are present in
the application. For example, you might have an intended path for the user to take from the login screen that goes to a dashboard and then
into a particular data set. You would then want to check that workflow to make sure that the UX still holds up. The same would be true for
any other workflows that exist in the app.
Inspect fonts for inconsistencies or accessibility issues
Accessibility is a topic which we have covered before in detail on the WorkingMouse blog and it is very important for most
public-facing applications. One of the most common things that can make or break accessibility are fonts. Fonts are also a common culprit
when it comes to breaking brand cohesion, so it's important to ensure that all headers, paragraphs, list items and links have consistent
font selection. To counteract any font size inconsistencies, a font scale should also be used.
Ensure that colours and buttons are cohesive
The bigger an application, the greater the risk is that the CSS (cascading stylesheets) becomes unwieldy. When this happens, it is easy for
the wrong colour variables to be used. This makes clean-up a headache. While you might not be able to fix this problem on your own,
identifying issues with consistency in terms of colours and buttons can be done by simply eyeballing the problem areas. The same applies to
items that have transparency
Is the HTML clean and semantic?
This last one is something that a designer or frontend developer will have to weigh in on, but it's a good thing to be aware of no matter
your skill level. HTML is used to structure out pages and components. Typically, these things are structured in a particular way to make
styling easier.
This means that if major design changes are needed, the HTML might need to be changed to accommodate the request. Sometimes we will also see
instances where the HTML could be improved to make it more semantic (readable for browsers, search engines and assistive devices) or easier
to style. In those cases, we may recommend that time be set aside to reformat the HTML and address the corresponding CSS. This level of
design change will get to the very heart of the UI.
A design review isn't just a 'nice-to-have'. They are an extremely important way for you to monitor the health of your application and keep
it looking fresh. Alongside regular security updates, design reviews will make it easier for your software product to evolve over time
without UI/UX hassles.
.png)
