Elevating the perception of design, part 2: From theory to practice
This is Part 2 of a 3-part chronicle on how I’ve been working towards changing the perception of design at Uniplaces.
Disclaimer: this here is a story. My story. Told in a way that is as relatable and actionable as possible. By showing real-life, day-to-day examples, I’m hoping you’ll be able to extract valuable insights that you can carry out starting today.
Let’s jump right in…
The theory behind the process
“Easiest thing in the world” — Garth Pancake, The Ladykillers (2004)
First let’s look at what the typical process used to go about designing digital products today. The obvious first step would be to look at the theory, right? So let’s do just that. If you were to ask me to break down product design into a process, this is what it would look like:
Research
What people problem are we trying to solve?
Empathy: Putting yourself in the shoes of the user, attempting to see things the way they see, feeling things the way they feel, is key towards understanding where the problems are and where you need to focus your resources.
Define: Through the empathy stage you’ll identify a series of problems. Out of that you create a people problem definition. What is the problem, how common is it, who does it impact and how, in what part of the journey or funnel is this happening, what impact does it have on our metrics?
Conceptualise
This is where you get to be creative and design a solution for the people problem at hand.
Needs of Users: Take everything you learned in the Research phase and extract the need from the problem. What does our customer need? Is the solution we’re considering exploring solving the problem? Solving the needs of our customer?
Technology: As a product designer you have to know whether you’re designing to fit a race car engine or a singe-cylinder engine. That or you and your fellow full-stack or FE engineer need to be thick as thieves. Know what you can, and can’t do from an engineering perspective, and where to push the boundaries.
Business Goals & Strategy: Remember about the differences between an Agency Designer and a Product Designer? This is where the money is. As a product designer you have to constantly align your solution with the business goals and strategy of your product or the company.
Confirm
This is where it all comes together.
Build: Now you’re ready to support the engineering team, your backend, your full-stack, your front-end and build the solution you just came up with.
Test: Once it’s built, it’s ready to be tested. Either internally, through the process of dogfooding, or (as it happens most often) putting it out in the wild, shipping it, and seeing how people use it.
Once it’s out, once people are using your product, your new feature, your update, it’s back to step one, back to Research. Back to empathising with people, your audience, your customers, and confirming your findings, and that the solution you provided them is the best it could be at this point in time.
That’s it. At a high level that’s your product design process, your script to designing digital products. The table of contents of a “Product Design for Dummies” book. So how do you put it to practice? Can you even?
Can the theory sustain the day-to-day of a startup (or any other work) environment?
“Say what you will about the tenants of National Socialism, dude, at least it’s an ethos.” — Walter Sobchak, The Big Lebowski (1998)
Tldr; The short answer is “no.”
Every part of your organisation has a process. Your operations, or customer success management team as a script they hand out to the folks on the phone dealing with your customers. Your sales team has their own ways to which they go about poaching a lead, following up with another one, or entertaining that existing one. And so does your engineering team, in the way they go about, week over week, sprint over sprint, coding towards their story points to make the mark.
The product design process, as described above, is our theory. And it’s just that, a theory. “Why” you ask? Because in your 40+ hour work week, there’s no such thing as uninterrupted design mastering. Actually, I’d dare say there’s no such thing as uninterrupted mastering of anything. Every month, sprint, week or day is different. It’s either different requirements, different resources, different timelines, different products, different features, different customers, different expectations altogether. That pushes design to adapt. But pivoting, especially a late one, can harm quality, morale and productivity. So how do you adjust the process and turn it into action items you can apply day to day on your team and keep it creative and with the expected throughput?
First, let’s visualise the above:
What’s depicted above is that as a designer, or team, or leader you can tackle Project A in a way, and Project B in a different way, and both are different altogether from Project C. But one thing I’ve identified throughout my years of designing, building, shipping digital products and leading design teams is that there’s no such thing as a recipe for great design. Each designer as its own creative process. What I’ve found however is that there are a series of patterns that hold true in every process, patterns that are the foundation of every creative process and that if applied correctly will likely lead you to create great digital experiences.
So what are those patterns?
♦ Research
The only pillar to extract from the theory.
First let’s remove Research from a timeline, as it rarely (IRL) functions as a starting point, but rather as a complement to the creative process. This happens either in discovery mode, where through Research you identify areas where you should take your product next, or what the v2 of a given feature should be, or areas you’re not investing enough of your business and strategy on; or in validation mode, where Research works closely with design, day to day, to plan qualitative sessions with real customers with the goal of validating the work the team puts together. As an example, at Uniplaces, for validation we take the first 8h to 12h of the week to assess Product priorities and shift our research resources accordingly. This usually is at a 1:1 matching with where we’re at with the roadmap and corresponding sprints. The following 16h to 24h of the week we use to run the actual studies. We took care of recruiting prior to this and have anywhere from 6 to 12 students or 6 to 12 landlords (or both) to sit down with and validate the design work at hand. We then use the remaining 8h to 12h to gather findings, elaborate a proposal or an action plan, and debrief the stakeholders, which includes the product designer and the product manager.
Now Research becomes a function that works as a driver for empathy. It’s through Research that you get unbiased, unfiltered feedback from your customer on every point of the journey or funnel. With this feedback you’re then able to share the insights and drive a lot of the product decisions not on intuition, which is risky, but on facts and evidence, which is safe.
But remember, although Research allows you to base decisions on evidence, on facts, on concrete data — and data doesn’t lie — that doesn’t mean you should go off and run tests left and right. After all you don’t waste the most precious resource of all — time. Instead use research to answer questions, not just to see what happens or how things pan out. When testing doesn’t make sense, you can always concede to the voice of experience, or democratize the decision. Not doing so can hurt team morale, in the way that it minimizes the ideas and opinions in the room.
♦ Exploration
This is where things start to get interesting.
This pattern lives off of two premises. And by the way, you can easily promote this thought process to be applied to any team within your organisation, even though is resonates strongly with design:
1. Never does a great idea come at first try: if you want to stop being perceived as a service provider within the organisation, as a machine, as an execution layer, but rather as creative force, as product designers, you have to start talking the talk and walking the walk. By presenting a single solution your work is perceived as being rather binary, very black or white, and the notion that it’s not about creativity, but rather about execution subconsciously comes out, and you don’t want that. Always look to figure out a solution from different angles. And why is that?… well, I for one think it’s because:
2. The path to finding that one solution that works, is to draw out a lot of bad ones: I don’t mean “bad” in the sense that you should make a conscious effort to just spit out designs for the sake of saying you did it. But rather don’t just settle, time box yourself and just start sketching, word dumping, whatever you need to do to get those ideas out and flowing and note them down or jump straight into pixels — whatever works for you. Don’t overthink, there’s no right or wrong here. Just focus, and then create.
Let’s look at a practical example. Take a look at this listing card. This is a specimen of the type o cards we display on our Search experience:
Do you see anything wrong with it? Seriously, open it. Zoom in if you’re on a mobile device and move around; or if you’re on a desktop just look closely and take your time.
Maybe a few things stood out? Maybe more? Or none, it looks perfect?
Well, what about now:
Different right?
And now?…
Now that you have six (and keep in mind you don’t need to kill yourself with the number of explorations, the rule here is three depending on time, effort and estimated impact) you start to see some differences. You subconsciously start to prefer one over the others. You naturally start to compare and contrast each and every single exploration. And over time you’ll notice that one, or a couple, do a better job at solving your problem.
♦ Feedback
A strong and closed feedback loop.
So we just talked about how more ideas is the merrier. But how do we quickly disambiguate? You’re thinking Research aren’t you? Don’t haste to conclusions. The answer is peer feedback. At Uniplaces we dedicate 1–2h of every week (sometimes more, especially in the early stages of the creative process) to go over each other’s work and critique it. It’s like AA but for creatives addicted to solving people problems — CASPP. Feel free to call it that, or just plain good ol’ “Critique.”
During these critiques designers go around the room and share something they need help with. Prioritised by impact, as depending on team size you might not have time to run through everyone’s work, as a participant Designer you’ll want to first set context: what people problems are we looking to solve, where does this sit within our product, and what is the specific thing, or things, I need help with today. For the latter the designer should come ready with specific questions, but remember not to over generalize an ask and don’t allow the discussion to rathole. All the while remembering that the primary focus is on concept and execution of said concept. Pivots or future directions leave to a discussion outside the group.
At the end of the day the quorum is there to offer a fresh pair of eyes, a fresh perspective. That can help in breaking down the work in a way that’s not personal, but rather based on constructive criticism. We want to look for areas that weren’t quite thought through and that could benefit from improvement.
Let’s bring back the cards to look at this from a practical perspective:
First, some context: With these cards we’re trying to dump as much information on the user as possible, with the least amount of text. We don’t want the cognitive load behind consuming each and everyone of these to be high. And so, at a glance, the user should be able to tell if this listing is worth clicking on, or not. Which one does a better job at this?
I like how the price and location are big like that. But am not a fan of how they draw the photo to the background as a consequence. Besides, as an international student, I have no idea what “Alvalade” means and whether that’s a location or an ice cream shop. Under it I like how clean a structured the metadata is, but I question if that is the right information for the user. Is the title something the user will remember this listing by, is the title key in the decision making process? I dare say no.
There’s a number of things that don’t work for me here, starting with how the price sort of gets lost when dragged to the bottom right corner of the photo — to make sure we always have good contrast we’ll have to increase the dark overlay on the photo and that, just like the first card, is not ideal if I want to see that bedroom. Secondly there’s just too much metadata. Talk about cognitive load and learning curve. As a new user I probably don’t know what 70% of that means or stands for.
Now here things are picking up. I like how the photo is bigger than in all other cards. I like how we moved the title and reviews (which in this case happen to be somewhat of secondary information given its redundancy) over the image behind an hover state. Finally I like how the price is right there on top of the metadata with a clean and clear accent color, and the rest of the copy breaks down the type of unit and other basic information that I can understand at a glance, just by reading it.
There you have it. Setting up such advisor group is key not only to help boost team morale — think of it as a weekly team building exercise — as it makes everyone feel included. But it also makes it so your designers start to think more in “we”s and less in “I”s.
Have you been trying to work out a process, work out a system, to maximize the productivity and throughput of your design team, but failed as everything was overly theoretical? Look into applying these tactics, focus on the patterns, and odds are change is going to come.
