I am a frontend developer and a huge piece of my work is coding designs prepared by someone else. In the companies I worked in there was either a person or a team (or multiple teams) in charge of app design and user experience. Personally, I am not into designing. I find it really hard to build layout from scratch and think of possible user behaviours. I focus on translating a design into a code that will end up as an app or a website in front of users' eyes. Don't get me wrong - I think that designing user interfaces is a hard work, I'm just not "feeling" it (or I simply spent to little time on that). Anyway, I get a design and I code. However, before I get into coding I spent some time on reviewing the designs which often leads to some design changes. Why am I doing it? Didn't I just say that I am not into designing? Couldn't I simply sit and code? Not really. Let me tell you why.
That's great that nowadays we have so many technologies to use. We have a plethora of choices, especially in frontend development when there is something new coming literally every minute. You can have the best and the newest tech stack in your app but you will go nowhere without one thing. The most important one - the users. They have to feel comfortable while using you an app or navigating on the website you built. They need to perceive your app as intuitive and consistent. Have you ever looked for a closing icon in really annoying modal? Have you scrolled the list of countries to select the proper one because there was no searching by typing? We need to avoid that.
UX and UI designers know what they are doing. They try to build the best possible app. But.. they can miss something, this is completely normal. As a frontend developer, I look from a different angle. Imagine that a designer has worked on a feature for a month, he or she knows it really well now. When I get this design, first look really matters. There are few questions I always try to answer when opening the design for the first time. Here they are:
1. Do I understand what this feature does?
If I have to get an explanation how the particular feature works, this is a red light for me. I should be able to figure out how to navigate, where to click and what to do. If something in not clear, I want to have instruction on the screen (as tooltip or something). Of course, I am not saying that literally everything should be on the design. However, with context I have as developer (assuming that e.g. product owner shared what we want to achieve) I expect designs to be self-explaining.
2. If I saw this app for the first time, would it be clear for me what to do?
This is linked to the first question. If I keep asking myself questions like "So where I should click now?", "Why is submit button disabled on that screen?", "Where I can see that there is an error?", "How to close this thing?", I know that some changes may be needed. There is always a new user using your app. If you build for "every-day user", he or should shouldn't be forced to get few hours training on how to use particular feature. Image opening new website in the browser and spending 30 minutes figuring out how to navigate there. This is not how it works, you would probably leave the site after two minutes top.
3. Is it consistent with what we already have in the app?
Web apps are complex. As developers, we touch different parts of an app, we may have one particular feature assigned to a team or a project. Same goes for designers. There is always a chance that someone hasn't been in all places in the app. While reviewing designs, I check for inconsistencies. Why this thing is opening as context menu on this screen and as pop-up modal on the other? Why we show error in a red container here and as grey text there? Inconsistencies can be intended, there might be reasons behind doing something differently in the particular place. I always look for the confirmation that a feature should work this way here. If there is similar thing in the current app, I also want to know if it is expected for it to be changed to match the new approach.
4. What edge cases do we cover and how we do it?
An answer to this question comes when I start coding because it is hard to predict all possible edge cases. They usually come to my mind when I start to take care of handling error or stumble upon a problem with coding. When I encounter an edge case, I check if design is somehow ready for it. If not, I go back to product owner or a designer so we can decide what's the best way to handle it.
5. Does it looks fine? Are there some misalignments, unexpected font or size changes? How this should look on a different screen size?
This is pretty simple. I check for everything that seems to be off.
Do you follow any rules while starting work with a new design? What would you add to the list above? Share in comments :)
Top comments (2)
Thanks for your ideas Joanna, they made me detect some things I always review before coding a design.
I would add "Grid logic". Understanding how the designer created the grid helps to code the basic layout.
Wonder if there's some style guide somewhere about this process.
Thanks! Good point about the grid! I have usually worked in some kind of design system and basic layout (like grid) was already implemented so this didn't come to my mind. But you are right - this is really important.