loading...

Technical review of designs

anfibiacreativa profile image Natalia Venditto ・3 min read

Today I had a 2 hours long review session with our client stakeholders, and their UX/UI engineers. And I thought...this is something that may be interesting to many beginners.

Part of my accountabilities as a Frontend Technical Lead is reviewing designs and wireframes in order to find potential issues before the implementation phase begins.

But, what kind of issues?

Performance issues

When we implement a digital solution, a website, an application, we want it to be performant. We want it to load fast. We want it to score well when tested with the Page Insights tool or Lighthouse (or any other similar tool).

Screening designs for potential render-blocking features, so you can implement them in an optimal way, is crucial. Some of those issues could be around media. If you have many media assets on a page, you know you have to suggest compression/optimization tools for authors, lazyloading and intersection observers for async loading and immediate loading above the fold. You need to have the right configuration for video players, to load the actual videos on demand.

Additional performance issues could be caused by dynamic components operating heavy javascript computations above the fold.

Another source of performance issues is fonts. If there are too many custom fonts in the design, make sure to handle potential FOUT, FOIT or FOFT correctly.

Accessibility issues

If you're implementing the frontend, you have a certain part of the responsibility of ensuring the UI passes a certain level (usually determined by the business stakeholders), of compliance.

You can catch some accessibility issues by reviewing designs for non-passing contrast ratios (foreground/background), for example with the tool provided by WebAIM

While reviewing designs, you may also want to ask about animations. Heavily animated navigation items, auto-playing elements, and resetting of browser indicators, like focus, could end up in a non-compliant UI.

Layout issues

The most significant layout issues usually come at localization times. When localizing the UI, you may realize that fixed widths and heights may suppose a problem: while in English (the most used language for design representation) a string may fit well, in other languages like German, it is unlikely to fit.

Always ask the designer/UX/UI engineer, how they would solve the problem if the word is too long, or if the lines wrap, or if there are more lines than the ones represented in the design. Should you truncate? Should you hide the overflow? Will the authors take care of it?

What does the design look like if elements like teasers, for example, have different amounts of content?

Also question designs that feature fixed-width columns with text inside, or that split into a second column after a certain amount of items, for example in the case of lists. That's very difficult to achieve.

Another usual problem with layout comes from different aspect-ratios for images. Always ask who is responsible for ensuring equal heights or widths. If it's the author, your implementation is safe, but if it's the system, then you have to make sure you have tools to post-process assets on upload time or calculate post-render with javascript.

More

There are of course more issues that you can come across, but these are some of the problems I've seen the most over time.

Stay safe, and have fun!

Posted on by:

anfibiacreativa profile

Natalia Venditto

@anfibiacreativa

I started frontend developing when marquees were a thing. Now I work as a Frontend Architect and Tech Lead at www.netcentric.biz. Google Developer Expert for #Angular and #WebTechnologies

Discussion

markdown guide
 

I'm really a fan of the "Handoff checklist" concept, simple one, but quite effective. Includes states, fonts definitions, edge cases and so on. It helps ensure quality and avoid hours of aligment with ux teams.

 

Well said!

It is not easy with certain clients when they outsource designs to third party agencies. You try to get involved as early as possible. Sadly some times you just get the finished designs for implementation.

 

So true. And this is something Frontend Developers should insist on: having the ability to review designs for those potential issues, as soon as possible or even collaborate in the definition of behavior.