How the best designers tackle complex design challenges

Jenny Wen and other designers share tactics for tackling ambiguous problems: enumerate and prioritize your questions, present options on a spectrum instead of picking one direction, and use prototypes to get honest feedback rather than asking what people think.
Chapters
Imagine you've just been asked to lead a new project. You know, the kind that's full of complex interconnected problems where it's super unclear how to get started. How do you attack that ambiguity and get momentum quickly? That's what this episode is all about. And we're going to start by hearing how Jenny Nguyen got momentum when she first started designing FigJam.
The way that I usually approach like a big open-ended problem is I sort of want to just like write down all the questions that we have and all the questions that we need to solve. And I actually remember doing this with FigJam. We had this messy page in our Figma file that just listed like all of the different questions that we had and that we knew we would have to solve before launching this.
Spatial writing has pretty quickly become my favorite way to think, especially when dealing with really complex design challenges. The meatier the problem, the more likely I am to start my design process in FigJam.
It's big questions like, what is the relationship between Figma and FigJam? And small questions like, How do you manipulate text? Like really being exhaustive there.
Your goal is to figure out which questions do you have to answer that unlock answers to other questions as well.
I will go through and sort of look at the questions and say like, what are the questions here that really feel like once we crack them, all the answers to all the questions, other questions will sort of be easy to answer and very obvious.
These tipping point questions are often referred to as eigenquestions, and they're a key way to frame problems more effectively. Jenny even built an entire FigJam template help designers get better at identifying and sequencing the right questions. But at some point you have to start answering them with pixels, which is why I love this line from my interview with Michael Wandelmeier while talking about his time leading design at Meta Lab.
I think truly designing to find an answer, not finding an answer to be able to design, is a basic principle, isn't it? Like, you absolutely have to get into it and be evaluating a solution.
Jenny also talked about the importance of creating this momentum.
Even if If there's this sort of big hairy question and you're like not quite sure what to do, my instinct is always to like do something. It's like, okay, there could be a lot of options in this option space, but let me just like mock up one or two and sort of get those out there and get some feelers. Because having that information and that feedback about these 2 different options is going to help me just understand the option space better.
Now here's the mistake I see designers make too often. Let's say you're exploring one of these tipping point questions and you narrow in on like 6 different concepts that you think show a lot of potential. Now, the last thing that you want to do is present these as 6 separate concepts to the team. Here's Alex Cornell explaining why.
If you're just sharing a, like, a whole bunch of work, like, what do you guys think of this? And you don't really make it clear what you were really toiling over, you're going to get feedback all over the place. So I think it's very important to establish and make very clear the framework that was guiding you when you did the thing so that it can sort of create an architecture around The ideas that you show that is very clear to people so that it's not like just getting a whole bunch of mocks thrown at you. You actually help them understand what is distinct about this idea. Why is it even being included in this combination? And where does it sit on this little map that I'm going to draw for you?
That's why I'm such a big fan of presenting my work on a spectrum. If we do a good job of identifying those tipping point questions, then you can anchor all of your explorations along that spectrum. Now, all of a sudden, instead of looking at 6 isolated mockups, you're presenting 2 or 3 high-level directions that your team can take. And the key is to paint the edges first. And that's exactly what Jenny did while working on FigJam.
Like, there's just 2 extremes. So for example, how fun and expressive should FigJam be? And, you know, there could be one side that's like super not expressive, like very utilitarian, and one that's like over the top. And I usually think with most design questions, it's actually never the polar opposites. It's always like somewhere in between. The fine line is like figuring out where it is in that middle. But I think just pushing the extremes lets you see like, hey, if we just optimize for one certain thing, what does this actually design direction look like?
When I'm presenting my ideas at Crit or maybe just making a simple Loom video to drop it in Slack, I'll often start my presentation with a simple visual representation of my spectrum. This helps people understand my mental models before we dive into specific concepts. And a lot of times that spectrum is just appetite. How much are we willing to invest in this? But another spectrum that I frequently used at Maven was this balance between power and simplicity. Take email marketing, for instance. Should we allow instructors to customize their own automation systems, or should we design an 80/20 solution that works out of the box? Regardless of what spectrum you're operating on, the key is to make a recommendation.
Sometimes it can be useful to Kind of whittle something down to like, here's a decision that's scoped that I can fully describe to you all of the sort of background. And as a result of all that background that now you have, you could kind of either go this way or that way. And here's the reasons why you might go one way or the other. And here's what they look like. Here's a prototype of each of them. And here's why I think option 2 is the best one.
The importance of having an opinion when presenting your work has definitely been the theme over the last 80 or so episodes. Rich Arnold even said it was one of the main lessons that he learned after he left Vine and moved over to Instagram.
I think I had this habit of just sort of coming in with like a menu of solutions and being like, what do you think? Yeah, you want to pick one? And at Instagram in general, Facebook, like they're very good at not letting you take that decision off of your plate and put it onto them. So if you come in and you don't have an opinion on what's right, they'll just tell you to come back when you think you know what the right thing to do is. Then you have to come back and present Why this is the right thing to do.
And the reason is, when you have a clear point of view, it forces people to react, which is why it's such an important tactic when you're dealing with these super open-ended and ambiguous problems. It reminds me of when Michael explained why Metalab uses what he calls the ridiculously early hypothesis.
What this meant was to try to come back after a week of kickoff with a really strong, structured, narrative-driven point of view as to what we should be doing next and to present that to get a reaction to the client so that we don't give like some 4-week span of like product definition without having really put an idea forward.
Jenny talks about getting momentum in a similar way.
I'll always sort of have what I call like a straw man, just one option that I believe in the most, even if it's not going to be the final one. And I think just having an opinion and sort of asserting one option that I really care about is a good way to sort of like move things forward as opposed to having analysis paralysis.
Real quick message and then we can jump back into it. Meet Trevor Nielsen. He's been designing products for the last decade plus, but after 14 months, he canceled his Midjourney account because he found a tool that he likes even more after listening to this show, and it's called Visual Electric. It's a new image generation tool that's built specifically for designers. It's the most photorealistic one out there, even more than Midjourney. They also have a bunch of beautiful predefined styles, and it's so incredibly easy to iterate because the entire experience happens on an infinite canvas. So you'll feel right at home. Honestly, the whole product is the epitome of taste. So the next time that you need imagery for a project, I cannot recommend Visual Electric enough. Head to dive.club/electric to check it out today. And if you like it as much as I know that you will, you can use the code DIVECLUB to get your first month for free. My favorite animation tool, Jitter, just had a game changer of a release. They just dropped their first set of community templates created by some of the best designers and studios that I know. And get this, they're all free. You don't even have to download anything because Jitter is like Figma only for animation design. Just head to their new community page. It's full of incredible animations. And when you find one that you love, you can remix it in a single click and make it your own with their intuitive editor. If you want to give it a try, head to dive.club/jitter. That's J-I-T-T-E-R. Okay, now on to the episode. Getting momentum on a hairy problem is great, but when you keep pushing things forward, don't forget to make it very clear what the team is leaving behind.
It's not super defined the edges of where you could go. You at least understand that if we go this way, we're not going that way. And there's certain things down that way that we liked, but we're leaving them behind. And that's, I think, a good, a good place to be when people understand those trade-offs.
And that's why I like to think about building software products a bit like exploring a cave. Your role as the designer is to venture ahead, illuminate potential routes, share your findings with the group. Then you can propose a direction and help the team get there. You're not committing to a specific UI at this stage. You're merely aligning on the map and choosing a high-level route to take. I have an upcoming episode with Andrei Horasimchuk, who was the first designer at both Adobe and Figma, and I think he does a really good job of explaining this idea. Good designers understand how to tell enough story, but leave themselves wiggle room so that when it changes invariably down the road or during the process, at the end of it, they're not stuck with an unhappy executive, customer, you know, whoever. The best designers I've worked with or managed Have always been good at telling an inspiring story, showing what's possible, but not showing what will be, only showing what could be. That's why when I'm exploring early concepts, the phrase that I use the most is, it could look something like this. That tiny little disclaimer is a powerful communication tool and a great way to avoid visual nitpicking. Now, I know what you're thinking, wouldn't it be more obvious if the designs were low fidelity? And Possibly, but again, you get better feedback when something looks and feels real. When you're exploring a cave, high-fidelity prototypes serve as the brightest flashlights. Hey, it's Ryd. Don't forget, if you want to go even deeper, each week I send an email out to over 10,000 designers with bonus resources and key takeaways from these conversations. So head to dive.club/email to sign up. Okay, I'll see you next week.
More from jenny

The design process is dead. Here’s what’s replacing it. | Jenny Wen (head of design at Claude)




