loader

[ad_1]

Definitions for output and outcome, provided by Oxford Languages are:

  1. Output is the amount of something produced by a person, machine, or industry. Example: screen you designed.
  2. Outcomes are the way a thing turns out; a consequence. Example: the result of your design.

An output is a product or service that you create; an outcome is the problem that you solve with that product. For example, for a B2B website, an output could be whitepapers and demonstration videos. The outcome could be knowledge gained by customers. Unless you know what information people need and how they will use this information, it is premature to say whether or not a whitepaper or video is the correct solution

Hoa Loranger, “Minimize Design Risk by Focusing on Outcomes not Features

Rather than being encouraged to apply our critical thinking skills in approaching or solving a theoretical problem, we’re tasked with spontaneously selecting elements on an existing screen that may or may not have a defined use case, without the opportunity to deliberate on the broader context or purpose

We create a paradox.

The paradox

Hi welcome to your interview! Okay, today we’re doing an exercise focused on:

  • Redesigning an app experience
  • A whiteboard challenge with our pre-defined prompt
  • A whiteboard challenge (the nightmare edition!) featuring our pre-defined, yet-to-be-solved product problem within our organization

For our paradox example, let’s opt for the redesign of an existing app, as it is a commonly encountered scenario.

Prompt: What would you change about this [DoorDash] experience and why? Highlight your strategy and talk us through the framework you use.

Details: None. No, we’re not going to give you context on the business goals or user goals that would be applicable here, that’s why we picked such a big app! You probably already know! Oh, you don’t know DoorDash’s business goals and targets? You can assume it’s probably just to get more people to order!

Pause. ⏸️

When I’m designing or talking about a product, my brain naturally envisions multiple approaches to solve problems. I often discuss this in the context of neurodivergence in design, sharing my story with ADHD.

The skill of envisioning multiple pathways for how something can be done becomes a superpower only when you dive into the ‘why’ behind each of those options.

  • What does this path do for users?
  • What value would this path have?
  • What outcome would it create for the team/business/org?
  • Does this path tie back to the company’s goals or North Star?
  • Does this path make sense for what PDE is trying to accomplish?

Now imagine a designer looking at the screen and throwing po*p at the wall to see what sticks.

Going back to the DoorDash prompt, let’s say my improvement is to create a 1-push button that randomly generates a restaurant name. How would the interviewer gauge my product sense?

You might be saying “Well, it’s just to hear how you think about it. You can expand in your interview. Talk about how you’d do that, why you’d do that, and the value it would create”.

Ok.

A randomizer would be cool because I, and other overwhelmed users, don’t have to do any work. I can just hit a big button.

It would reduce the cognitive load users have when choosing their meals. No one would need to think much at all, it’s KISS! (keep it simple, stupid).

It would end the ping-pong loop of “I don’t know, what do you want?” that friends, families, and partners get stuck in. It would give visibility to restaurants that users might not normally see or find, which would consequently improve their revenue thanks to the added visibility.

Wherever possible, complexity should be avoided in a system — as simplicity guarantees the greatest levels of user acceptance and interaction

Interaction Design Foundation — IxDF. (2016, June 5). What is Keep It Simple, Stupid (KISS)?. Interaction Design Foundation — IxDF.

In the moments I had with the interviewer to think of an original solution, I half used myself, then half applied myself to other potential users. It’s niche — because I was thinking of people who might have ADHD and freeze when given too many options, and as mentioned, DoorDash has too many options!

So users think less, order more, find new restaurants, and restaurants benefit from the increase in revenue as a consequence of the added visibility. Great!

No! Designers shouldn’t tackle problems solely through their perspective. Our role is to stay unbiased; otherwise, we risk designing for issues that may not genuinely impact end-users.

But I had like, 5 of those 60 minutes to come up with ideas to focus our exercise on fixing. The interviewer was focused on the solutions I’d come up with (THE OUTPUT) not on how I’d inform those solutions and design around that (FOR OUTCOMES!).

The time spent in re-design or critique challenges has designers look at the UI, translate that into an experience, then guess a solution that is better with…

Yes! Little to no details on end-users or business goals. Now we’ve arrived back at “intent versus impact”.

My proposed solution could also create an equal amount of negative impact:

  • The button eats up the screen so users just close the app.
  • The generator doesn’t serve a core need, users told DoorDash they want to browse and weigh options. Users like thinking when using this app.
  • Users expect to browse by the categories of their choice when they open the app, so removing that as their first-touch experience creates friction. Users don’t feel overwhelmed, they feel informed.
  • People have dietary restrictions, so the generator might not always include them. Users don’t want to gamble with allergies.
  • There might not be enough restaurants in the area to make this feature valuable. DoorDash doesn’t want users to feel the pain of restaurant quantity.

Compelling design narratives that inspire confidence can only emerge through exploration and discovery, whether facilitated by the interviewer for efficiency or integrated into the exercise.

If designers are being evaluated on strategy, thoughtfulness, and communication, it raises the question: Why are we primarily asked about ideas and potential solutions, often with little room to apply real-world strategy?

Design is captivating due to its incredible versatility. In the realm of design, possibilities are boundless, each presenting two sides of the coin to consider and discuss.

Yet designers are still boxed into what someone, or a group of someones, has decided is “right”.

The outcome of that paradox

The interviewer:

  • I’m sorry, you didn’t discuss any of the things we typically expect to hear.”
  • “You didn’t mention the thing that I would do or that I was thinking, so I’m not confident in your abilities.”
  • “You gave us a great list of potential solutions but you didn’t expand on just one of them. We don’t feel confident you’d be able to make decisions as quickly as we need.”
  • “We felt you asked a lot of questions! I know we told you to talk out loud, but we wanted you to know the exact right amount of when to ask things versus when not to.”
  • “We felt you didn’t ask enough questions! I know we didn’t tell you our preference or how we prefer to work with designers, but we feel you’re not a strong collaborator.”
  • “We decided to pursue another candidate after taking anywhere from 8 hours to 3 months of your time without giving a reason” (lol)

Food for thought: Would a company create a product for users centered around heightened emotions and stress levels, with as little guidance as possible, then be disappointed when those users didn’t do exactly what you wanted? No?

So why are design challenges purposefully vague? Are designers meant to solve your intentional mystery? Do you hire employees and then make them guess what makes them successful? Do you hire product managers and then make them guess what the best product metric is?

You don’t?

“No, but we’re trying to see if they can figure it out with their skill and strategy”

Oh. Do you mean the one that shifts on a project-by-project basis depending on the goals and outcomes?

On top of everything, it makes you wonder about inclusivity and accessibility. Are these formats designed to be fair to neurodivergent candidates who are more than capable?

I remember this one big-name interview — by the third hour of a six-hour on-site, I was getting nervous. Keeping constant eye contact was a bit tricky for me, and guess what? That ended up being included in feedback on why I didn’t get the job.

Do you ever think about how some candidates might just freeze when they’re put on the spot? Imagine being given 60 minutes to whip up a full solution for a prompt you just heard for the first time.

Now, picture this: what if that interviewee has been out of a job for months and is just $20 away from a $0 account? In the back of their mind, they’re thinking if they don’t nail it, they might not eat next week.

Does not cranking out extravagant value in 60 minutes automatically make someone a bad designer? An unqualified designer? I mean, are we running sprints in just 60 minutes here?

Aren’t these the questions we approach our product problems with?

How/what might a user feel/think when going through this experience/process/flow?

It might be an inside job

At many organizations, design is a second-class citizen to product and engineering. This makes it increasingly more difficult for designers to tie any of our work to business outcomes.

Ryan Scott, a design leader, teacher, and advisor, provided this design business value framework as part of his “Describing the ROI of Design” course:

  1. Project: work that led to the design outcome(s). →
  2. Customer outcomes: how they were affected. →
  3. Business outcomes: how the customers’ resulting behavior changed key metrics. →
  4. Financial outcome: how everything ultimately affected the company’s health.

I’ve had conversations with countless designers who echo the same narrative. It’s so prevalent that it might even feel like a rite of passage when you’re stepping into the world of design

Designer 1: “I’m struggling at work. I feel like no one wants to consider my input or solutions.”

Designer 2: “Why?”

Designer 1: “Well, most things get de-prioritized because our product manager is focused on their product metrics, and engineers usually side with whatever product says since they make the final call on our decisions.”

Designer 2: “Have you told a strong narrative behind your design decisions and hypothesis? Did you utilize any customer or data insights?”

Designer 1: “Yes. Even with that context, the consensus is that committing to the designs/work required to give end-users (and product) the best chance of success is extra scope to our engineers, which is too risky since the PM needs to show movement ASAP.”

Designer 2: “Did you explain that to your team?”

Designer 1: “Yes, but they told me that they are hyper-focused on the outcome that leadership is pushing for. ”

Designer 2: “Oh. who defined what you’re building or what success looks like?”

Designer 1: “The leadership team”

Designer 2: “Have you considered quitting?”

A couple of things were happening here:

  • Leadership often requests features or instructs the product team on what to build without allowing them the space for independent discovery. This hinders the ability to discern the right solution for customers.
  • Product managers hold the final say and wield the gavel, mainly because they’re the ones in the spotlight, interacting with leadership.
  • Engineering has tight deadlines to hit goals as quickly as possible, even if there’s uncertainty about how what they’re building adds value or aligns with the company’s overarching objectives.
  • Communicating tradeoffs, impact, and even at times insights, doesn’t empower or enable the designer.

If an organization functions similarly to that, how can we anticipate the design teams within that organization to establish an effective interview process? If organizations lack a precise understanding of what design entails or how it generates impact, how can they effectively assess those skills in a design interview?

Internal misalignments often occur without acknowledgment or communication within the organization. Given this, there’s little reason to expect these misalignments to be communicated externally.

It’s as if employers are conducting interviews without really knowing what makes a designer good, great, or even capable at their job.

At times they might not even know how to accurately identify the candidates who are qualified for the role employers want to fill. In this case, it’s not the junior designer striking gold, getting hired at $250k to do a staff product design role.

It’s usually well-informed, competent, designers being told they aren’t a fit because the fix they wanted to make to the DoorDash UI didn’t mention the thing the interviewer was looking for.

[ad_2]

Source link