Recently, I was participating in a few designer interviews. After the first round, candidates would be given a design exercise which they would need to complete and present to us remotely in the second round. We would then look at the design, ask them questions and provide feedback during their presentations.
From interviewers’ perspective, understanding a candidate’s design could be challenging. Candidates usually need to go through many screens in a short period of time. Maybe the candidate is not so good at explaining the rationale behind his or her design. Sometimes there could be problems with the connection which lead to poor audio or video. In these circumstances, how can we critique a design effectively and provide the candidate with valuable feedback?
Here is the question that I often ask myself when looking at a candidate’s design:
Is it actually working?
And I find it useful to initiate my thought process.
First of all, asking this question prevents us from getting mired in how things look. Though visuals are important, design is first and foremost about how things work. After looking at several pages of wireframes/mockups, we could easily get lost in the visuals presented by the candidate and only care about whether the text passes the accessibility test, or whether the color palette is appealing. This question reminds us that visuals are secondary at this stage and can be nitpicked later, and there could be bigger problems that lie in the core of the design to be discovered.
Once our focus is shifted to how things work, we will then be able to look at the big picture, step into the users’ shoes and start empathizing with them. Who are the users? What are their goals? Where will they use this design? Will the candidate’s design actually help them achieve their goals? Does everything fit together in a logical way? Is there anything in the design that actually is causing friction and prevents the users from getting to these goals? By asking questions like these, we think from the users’ perspective and dig deeper to uncover the underlying problems of the candidate’s design.
Last but not least, for a design to work properly, it needs to meet the business requirements, whether these requirements are stated explicitly or not. Let’s say the candidate is tasked to design an electronic program guide (EPG). Typically, an EPG inside the app of a video content provider could easily contain more than 100 channels. If we taking this into account, we will know that certain design decisions should be made accordingly. Will the candidate’s design be able to display 100+ channels effectively? What is the best way to display all this information, card, list, grid or something else? Should the design support infinite scrolling? Will the candidate’s design enable users to quickly sift through all the channels and find the ones they want? Do we need a filter in this case? If we think about the business requirements, we may find that sometimes the candidate’s design in their mockups may work at first glance, but there could be problems when it is applied to real-world situations.
Of course, critiquing a design during an interview isn’t just about finding problems. It’s also about identifying the areas where the candidate has done well and perhaps learning from the candidate. Since most candidates spend a lot of time completing the design exercises and preparing their presentations, they deserve hearing valuable and constructive feedback. I hope that the simple question above can help interviewers provide well-done design critiques more easily.
P.S. Jared Spool has an excellent article on what defines a well-done critique.
