Explore UX design practices: “More science than arts”
After graduating college, I joined the creative internship summer class at one the largest ad agencies worldwide. Everything was impressive to me, even the cereal machine at the 7th floor. Each Friday, my team of designers would print out a week’s worth UI mocks and stick them to whiteboards. They would then discuss visual styles and discard any that were not up to par. Each board had only a handful of “best options” at the end.
You might be thinking, “Sounds a standard critique.” Is there anything wrong with this? It’s the method.
Contrary to popular belief, design is more science-based than art. Design is not meant to be understood, but art can be interpreted. This fundamental difference means art should not be criticized, but design should be studied, tested and improved upon.
Don’t get me wrong, it is very important that a design goes through design reviews. Kickstarter walks a feature through three stages:
- The Studio: Exploration and Discovery
- The Critique: Focus on one path
- The QA: Pre-implementation Sanity Check
The critique is just one part of the process. We spend more time analysing test results than we do throwing mocks onto the floor.
You are not your user
It’s easy to judge the quality of a design. Visual-based deliverables are popular because people love to comment on the appearance of things. It’s easy to assume that things will behave in a certain way. For example, “The average user will notice this first” and “As an user, I’d prefer X over Y.” These assumptions should not be taken as absolute. These assumptions should be validated, since they are only opinions. While the UX community loves to talk about validating assumptions, they aren’t doing it enough. Their method is biased towards qualitative methods, such as the cognitive walkthrough or user interview. It is easier to talk to people than to query data.
Qualitative data gives you the what, while quantitative data gives you the why. That’s user research 101. While both are important for verifying hypotheses they should be done in parallel. You can start with the quantitative first and then analyse your users’ characteristics and assess the impact of a solution on them -objectively, with scalability in consideration. These high-level findings can be used for qualitative research. For example, you should ensure that your interview pool includes a broad range of users and not just those who shout the loudest. Design reviews can be more valuable if people are willing to suggest data or ways to design a test. This is in contrast to subjective criticism.
Dribbble is the new design platform
Quantitative data can even be used for the most basic UI decisions. How many times have product designers seen a beautiful design on Figma only to find that it was unable to handle large amounts of user inputs during implementation? Dribbble has many eye-catching dashboard graphics. They are graphics and not mockups.
It is important to understand the constraints and edge cases of real applications in order to design them. These are problems that occur at extremes of operating parameters. How can we ensure that 80% of exploratory designs are successful and 20% don’t fail?
We need to think about all possible UI scenarios. Before we even start designing the interface, we should query the use of the product. I recently helped Kickstarter ship Add-ons, a feature that allows creators to offer optional “add-on” rewards to backers. One of my first questions was: What is the maximum/average reward a creator can have, broken down by funding tiers and categories? What is the average or maximum number of items a reward has? How many projects fail? After doing some data modeling, I was able to get a good idea of the UI’s capabilities and what edge cases it should be covering.
It is frustrating to have to request new mocks from an engineer when you are working with them. This is why it is important to use quantitative methods early in the process to ensure that everything can be handled by your UI.
Observe, collect, draw!
I once attended a talk with famed Italian information designer Giorgia Lupi. I was surprised to discover that she visualized data by hand, regardless of how large it was, no matter how many data points. Lupi co-authored the workbook Observe, Collect, Draw!, in which she designed various exercises to inquire, collect, and categorize raw data. This is the best way to start if you’re a designer who wants to explore the world of data. Simply ask as many questions as you can about “how many”, “how much” and “what percentage.” Scroll through the data and take a look at it. You can get a sense of the raw data. Your brain can draw a lot from it.
If your company has not yet, you should start using a data discovery tool such as Looker or Metabase. Examine the data architecture of your application and learn how to run queries with only the graphical user interface (GUI). Looker greatly lowers the barriers to data analysis and querying with their GUIs. This means that it is more difficult to navigate your unique application’s data structure. I suggest reading through Mozilla web docs to have a basic understanding of arrays, objects, and data types. Understanding these building blocks will allow you to design a new product.