Please note that this blog is archived and outdated. For the most current information click here!
The Why and How of Design Reviews
A lot of effort goes into designing a beautiful web or mobile application. Not only do aesthetic principles like layout, colour and harmony need to be considered, but accessibility and brand cohesion are also on the table. Once an application is released, it's tempting to think that the design is 'complete' and any further changes to the app will be purely functional.
In our experience, this is very rarely the case, and in this article, we will run you through why design reviews occur and how you can carry them out independently to ensure your application stays fresh and on-brand.
Why does my app need a design review?
Whenever new functionality is introduced into an application, it often necessitates changes to the existing user interface and user flow. Applications may benefit from regular small updates or receive updates periodically via more intensive scoping. Many applications have an update pattern which is a hybrid of both approaches. Regardless of this, the end result is that the application has shifted further and further away from what was initially designed in the first scope.
Having designers on hand to help with these changes can mitigate how far the UI (User Interface) and UX (User Experience) departs from the original intention, but sometimes this isn't always feasible or practical. Even with designers on hand, changes from the original scoped design can be unavoidable. The answer to this is regular design reviews, which allow for accrued changes to the application to be performed in bulk.
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.
If you’re prepared to transform your business with the help of software, contact us here. Still need more information? Download our Guide to Creating a Successful Software Product.
