The Why and How of Design Reviews


A lot of ef­fort goes into de­sign­ing a beau­ti­ful web or mo­bile ap­pli­ca­tion. Not only do aes­thetic prin­ci­ples like lay­out, colour and har­mony need to be con­sid­ered, but ac­ces­si­bil­ity and brand co­he­sion are also on the table. Once an ap­pli­ca­tion is re­leased, it’s tempt­ing to think that the de­sign is ‘complete’ and any fur­ther changes to the app will be purely func­tional.

In our ex­pe­ri­ence, this is very rarely the case, and in this ar­ti­cle, we will run you through why de­sign re­views oc­cur and how you can carry them out in­de­pen­dently to en­sure your ap­pli­ca­tion stays fresh and on-brand.

Why does my app need a de­sign re­view?

Whenever new func­tion­al­ity is in­tro­duced into an ap­pli­ca­tion, it of­ten ne­ces­si­tates changes to the ex­ist­ing user in­ter­face and user flow. Applications may ben­e­fit from reg­u­lar small up­dates or re­ceive up­dates pe­ri­od­i­cally via more in­ten­sive scop­ing. Many ap­pli­ca­tions have an up­date pat­tern which is a hy­brid of both ap­proaches. Regardless of this, the end re­sult is that the ap­pli­ca­tion has shifted fur­ther and fur­ther away from what was ini­tially de­signed in the first scope.

Having de­sign­ers on hand to help with these changes can mit­i­gate how far the UI (User Interface) and UX (User Experience) de­parts from the orig­i­nal in­ten­tion, but some­times this is­n’t al­ways fea­si­ble or prac­ti­cal. Even with de­sign­ers on hand, changes from the orig­i­nal scoped de­sign can be un­avoid­able. The an­swer to this is reg­u­lar de­sign re­views, which al­low for ac­crued changes to the ap­pli­ca­tion to be per­formed in bulk.

How to con­duct a de­sign re­view?

Design re­views can in­ter­ro­gate an en­tire ap­pli­ca­tion or be re­stricted to a cer­tain num­ber of pages. The goal of a de­sign re­view is to es­sen­tially cat­a­logue as many points of im­prove­ment as pos­si­ble. This then al­lows the prod­uct owner to pri­ori­tise which items should be fixed first. At WorkingMouse de­sign­ers per­form these re­views on re­quest, but prod­uct own­ers and other mem­bers of the prod­uct team are quite ca­pa­ble of per­form­ing the re­views in­de­pen­dently to an ex­tent.

Set up a re­view doc­u­ment

The first thing to do is set up a re­view doc­u­ment where find­ings and sug­ges­tions can be found in one cen­tral lo­ca­tion. Make sure that it is ac­ces­si­ble for every­one in the team. A table or spread­sheet is the eas­i­est way to achieve this. You will need the fol­low­ing columns at a min­i­mum: name (to iden­tify the is­sue), de­scrip­tion (to pro­vide a sum­mary of what the prob­lem is), rec­om­men­da­tion (an overview of how the prob­lem could be tack­led) and pri­or­ity (to ad­dress the ur­gency of the prob­lem). It’s also help­ful to log when each rec­om­men­da­tion was made so that you can re­turn to the doc­u­ment at a later point and take note of which items have had ac­tion taken on them.

Examine each work­flow

Once you are ready to start re­view­ing, take the time to go through the ap­pli­ca­tion and ex­am­ine the dif­fer­ent work­flows that are pre­sent in the ap­pli­ca­tion. For ex­am­ple, you might have an in­tended path for the user to take from the lo­gin screen that goes to a dash­board and then into a par­tic­u­lar data set. You would then want to check that work­flow to make sure that the UX still holds up. The same would be true for any other work­flows that ex­ist in the app.

Inspect fonts for in­con­sis­ten­cies or ac­ces­si­bil­ity is­sues

Accessibility is a topic which we have cov­ered be­fore in de­tail on the WorkingMouse blog and it is very im­por­tant for most pub­lic-fac­ing ap­pli­ca­tions. One of the most com­mon things that can make or break ac­ces­si­bil­ity are fonts. Fonts are also a com­mon cul­prit when it comes to break­ing brand co­he­sion, so it’s im­por­tant to en­sure that all head­ers, para­graphs, list items and links have con­sis­tent font se­lec­tion. To coun­ter­act any font size in­con­sis­ten­cies, a font scale should also be used.

Ensure that colours and but­tons are co­he­sive

The big­ger an ap­pli­ca­tion, the greater the risk is that the CSS (cascading stylesheets) be­comes un­wieldy. When this hap­pens, it is easy for the wrong colour vari­ables to be used. This makes clean-up a headache. While you might not be able to fix this prob­lem on your own, iden­ti­fy­ing is­sues with con­sis­tency in terms of colours and but­tons can be done by sim­ply eye­balling the prob­lem ar­eas. The same ap­plies to items that have trans­parency

Is the HTML clean and se­man­tic?

This last one is some­thing that a de­signer or fron­tend de­vel­oper will have to weigh in on, but it’s a good thing to be aware of no mat­ter your skill level. HTML is used to struc­ture out pages and com­po­nents. Typically, these things are struc­tured in a par­tic­u­lar way to make styling eas­ier.

This means that if ma­jor de­sign changes are needed, the HTML might need to be changed to ac­com­mo­date the re­quest. Sometimes we will also see in­stances where the HTML could be im­proved to make it more se­man­tic (readable for browsers, search en­gines and as­sis­tive de­vices) or eas­ier to style. In those cases, we may rec­om­mend that time be set aside to re­for­mat the HTML and ad­dress the cor­re­spond­ing CSS. This level of de­sign change will get to the very heart of the UI.

A de­sign re­view is­n’t just a ‘nice-to-have’. They are an ex­tremely im­por­tant way for you to mon­i­tor the health of your ap­pli­ca­tion and keep it look­ing fresh. Alongside reg­u­lar se­cu­rity up­dates, de­sign re­views will make it eas­ier for your soft­ware prod­uct to evolve over time with­out UI/UX has­sles.

If you’re pre­pared to trans­form your busi­ness with the help of soft­ware, con­tact us here. Still need more in­for­ma­tion? Download our Guide to Creating a Successful Software Product.

Discover Software


Rhiannon Stevens

Creative sto­ry­teller and ex­pe­ri­ence ex­pert

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Migration vs Rebuild

12 November 2018

The top tech­nol­ogy frame­works you can use to build a mo­bile app

21 January 2020

How does end of life soft­ware im­pact you?

10 November 2020

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion