A rule of thumb for assessing the design condition – for developers, PO’s and more.
It’s quite often that at the beginning of development, a team is presented a set of designs to implement that is prepared by an unknown designer. While it’s easy to say “I really love the idea and the way it’s designed!” (or the other way around – to criticise it), finding actual implementational shortcomings in such a design may be a harder task to do. And though the path presented in such a set of designs often does make sense, a team encounters problems at later stages of development. These problems make them spend ten times as much effort on fixing the problems coming from wrong design decisions, misconceptions based on a lack of feasibility input, or omissions.
Fortunately, these problems are, to some degree, repetitive across projects and teams — and as such, can be diagnosed at an early stage. Below, we present a never complete list of things to take into consideration to assess the design condition at early stages, to diagnose some of the potential design issues that would otherwise impact the development work.
Oh, by the way – this article has been illustrated with Midjourney. Why? Because we love how AI contributes to design. And while it’s still imperfect, and may be controversial for some, this is the future we all need to embrace!
First, Who Owns the Treasure?
Be it development already, or still some degree of design to be made, it needs to be fully in your hands. Mistakes often made at this stage include improperly set design files permissions, elements of external, inaccessible design files being included within the profile, or lacking licenses.
- Make sure the resources or reusable components are stored within accessible places such as a design library you have access to, or a dedicated page in the design.
- Make sure that either you or your Client have owner rights over the design file.
- If there are any licensable items in the designs — e.g. illustrations, animations, fonts or photos — ask if all the licenses have been passed to you or your Client or they still need to be purchased. In the latter case, make sure you know how to access them.
Is the Design Complete and Clear?
Before you start the journey, it’s good to have a map and a clear plan where you’re headed. While design completeness is a very broad topic, it can be easily checked by asking several questions.
First of all, you should check the flows completeness. Very often, designs only show the success path and navigate around screens showing errors such as no internet connection, service unavailability, form validations or access retrievals.
- Do the screens contain all the necessary steps?
- Is there more than just the “happy path” designed?
- Are error pages and error form states designed?
The next area to check are the building blocks reusability and versatility. This touches things like buttons, form elements and so on.
- Have multiple states of interactive elements been designed (e.g. active, selected, disabled buttons, field or dropdowns)?
- Are the designs built of reusable components that are defined in one place and only used in the design instances? Are these not overridden too frequently? To make sure what it is, refer to the approach Figma applies to components, their variants and text or color styles: What are components in Figma
Design clarity is another thing to check. Make sure any excess elements of the design (such as unfinished or abandoned concepts, work in progress, temporary copies…) have been removed or moved to a separate place within file or to another file (such as: unfinished concepts etc.). This will eliminate a lot of confusion around which designs are intended to be implemented, plus it will make it easier to identify any other design shortcomings. Moreover, any descriptions of the cases happening within these interfaces – such as “when user click on… this happens” will, with no doubt, be helpful to assess necessary development work.
Usability and the Utilitarian Value to Users
Often hidden behind the “UX” acronym, “user experience” is a pretty broad topic. For example, there’s a lot of business decisions that are related to it. But it can easily be narrowed down to usability and answer the question if such an interface will be ‘usable’ for people.
Just to give you a perspective – when you think about buying a car, you might like a Porsche with its premium materials, but it might be too expensive for your budget. You also like the fact that the steering wheel and the brake pedal are in the same place as in any other car — you probably won’t say it but it would bother you, if it was totally different. In fact, all these – the placement of the elements, premium materials and looks, and the pricing policy, build up user experience (sometimes named more broadly as “customer experience”). But only the placement of the steering wheel and the brake pedal (and numerous other elements within the car) are responsible for making it usable, and in this way, also bringing the utilitarian value.
Usability can be assessed in a quick n’dirty manner based on the 10 NNG Usability Heuristics:
- Visibility of system status
- Match between system and the real world
- User control and freedom
- Consistency and standards
- Error prevention
- Recognition rather than recall
- Flexibility and efficiency of use
- Aesthetic and minimalist design
- Help users recognize, diagnose and recover from errors
- Help and documentation
But here’s the catch: users’ needs differ depending on the actual user group and their usage scenarios. Where a steering wheel is a no-brainer, a need to have an additional compartment for delivering these 5 tons of load may actually double-cross, say, the Cayenne. So having the questions “What is it for?” and “Who is it for?” answered is important. And while placing the bets about these answers is definitely a part of the product strategy, the sole fact that these have not been answered may impact your development severely.
So more questions to answer would be:
- Does the Client have the target group identified?
- Does the Client have an understanding about this target group needs?
While here, it is good to understand the Client’s expectations regarding the approach to these – do they envision any usability testing that would impact the product scope? Do they want it to be prepared in a manner that would allow quick changes to e.g. some elements of the views? Does the currently used approach in design make it easy?
Accessibility (or: Making it Work for Everyone)
There may be a special group of users having specific needs to make something within their reach (hence, the term “accessible”). Note that making this happen may require HUGE engagement to implement, and HUGE^2 work to refactor. This engagement stretches from making fonts bigger to things like applying specific color palettes, or involving the use of screen reader devices that would make things accessible for people with hearing or sight impairments.
Therefore, while the decision if the needs of such groups should be covered (either from the very beginning or at some stage) is an element of the product strategy, it’s good to understand these plans from the very start. It will help to approach the development in a way that will limit the scope of refactoring in the future.
So the questions here are:
- Do we need to cover the needs of these groups?
- Do we know which level of accessibility is necessary? (E.g. for web AAA is way more complex to implement than AA!)
- Do we know if the designs are prepared in accordance to the required accessibility level?
Note that there are multiple guidelines for these. Here are the most important ones:
Web Content Accessibility Guidelines
Material Design Accessibility Guidelines
And yes, it’s hard to assess these – and there are experts who can conduct such an assessment for you. But it’s good to educate the Client on these.
Devices, Technology, Implementability
Now, let’s get to the big question: can it be implemented within a reasonable engagement? Often making small changes to the design makes tremendous changes to the development effort. So maybe if the designs were prepared in accordance to these… it would take way shorter?
And guess what — it’s true! Let’s prepare the design in such a way that makes the development more efficient. That makes it necessary for the designer to both understand the design guidelines for particular platforms and know these platforms. That said, the decision about the platform should not be made just based on the designs – these designs often can be adjusted accordingly if the right discussion is triggered in the very beginning.
So the important question here is: Do we know which technology (technologies) it should be developed in?
Only based on the answer can we verify if the design does fit its requirements based on the actual guidelines, e.g.:
Then, more implementability questions stretch to other practical topics with various importance:
- Has the implementability of the designed flows, features and UI elements been discussed with developers?
- Is the design capable of being scaled so that it fits multiple screen sizes?
- Are the designed screen sizes relevant for the currently statistically important screen sizes (you can use e.g.: Screen Resolution Stats)?
- Have the designs been prepared for devices such as desktop, tablet, mobile (in accordance to product priorities)?
- Is dark mode required or will be required in the future – and are the designs prepared for that?
- Is the system intended to be localized (translated) to other languages? Some languages (e.g. Finnish or German) may include extremely long words or different character sets.
- Are these left-to-right languages or also right-to left ones? Note that this may trigger way more work.
Last but not least: handoff! Are the assets within design (photos, icons & vectors, styles etc.) available for the developers and prepared for export? “Let’s do it later.” is a wrong approach here because ultimately you’ll need these assets.
Aesthetics, Style and Content
Finally: the beauty. Yeah, we love the looks. And we can easily say we like it or not but there’s more than that! And while visual consistency within the whole interface may be important, there is more down the line. At the same time, those big BIG!) changes. So let’s have these answered before we start:
- Is the interface visually consistent across the screens (colours usage, fonts etc.)?
- Does the color scheme follow the Client’s brand guidelines and industry? (E.g. pharmacies are usually green)?
- Is the wording consistent and appropriate regarding the envisioned target group?
Let’s not forget that the interface is but a container for the content it needs to hold. If, for example, you want to show photos of people dressed from head to toe, then most probably horizontal photos will not be the right form. Same about the texts they enter, like real names and usernames. Plus, let’s remember that sometimes the content is… just NOT there. People often don’t provide the profile pictures, or descriptions.
Questions in this area regard:
- Does the envisioned content adhere to the interfaces?
- Is any content preparation required (texts, images, photos, animation, videos…)?
- Do the texts used in designs reflect real use cases? (e.g. “John Doe” is way shorter than “Christopher Christiansen”)
- Do the photos in the design reflect real-case scenarios? (It will be used by REAL people, not those from STOCK photos.)
- Are empty states designed (e.g. in case someone has not added their profile photo, or has no messages in their inbox).
Last but not least… compliance!
The legal compliance is very important as not sticking to the regulation can be a huge, ekhm… an ultimate stopper for the whole idea. It happens that great, ambitious products turn out to address a need that requires a specific regulation and… the team developing them discovers it JUST the instance they hit the market. It is important to have these risks identified from the very beginning.
While each product addresses a little bit different challenge, some regulations need to be respected more often, namely those that regard collecting personal information or possible money laundering. And while meeting these depends on the market a product is going to operate in, here are some examples:
PSD2 Compliance Guide and Strong Customer Authentication Checklist
Good luck with your next project!
— Dom
