How product designers choose the right people, tools, techniques, and process before designing the product.
At four thirty on a Saturday afternoon, Shafira received a message in the family WhatsApp group.
“We are coming over after Maghrib. Maybe ten people. Do not prepare anything complicated.”
In Indonesia, “do not prepare anything complicated” can mean almost anything. Ten people may become fifteen. Someone may bring a cousin. Two children will probably ask for fried rice without chili, while an uncle insists that sambal is the entire point of eating.
Shafira looked at his kitchen. The chicken was still frozen. The rice cooker was empty. One knife was sharp, the other was useful only for spreading margarine. There were three recipes open on his phone, each promising a different version of the perfect dinner.
His first instinct was to start chopping.
Then he remembered the last time he had done that. Halfway through cooking, the gas ran out. The shallots burned while he searched for a new cylinder. The soup became cold because the fried chicken took longer than expected. By the time everyone sat down, Shafira was exhausted, and the kitchen looked as if it had survived a small flood.
So this time, before touching the knife, he asked a different question.
What kind of dinner was he actually trying to make, for whom, with what time, ingredients, and help?
That question sounds ordinary in a kitchen. In design work, it is one of the most important abilities we often skip.
It is called Design Your Design Work.
🧭 The Product Brief That Looked Clear Until Someone Read It Carefully
A few weeks earlier, Shafira had joined a product team working on a feature for a digital banking app. The brief was short: “Improve the experience of first-time users who abandon account registration.”
The request sounded clear enough. The team opened Figma, reviewed the registration screens, and began discussing a cleaner progress indicator. Someone suggested reducing the number of fields. Another person proposed a friendlier illustration.
Shafira almost followed them into solution mode. Then he noticed that the team did not agree on what they needed to learn.
The product manager believed people were leaving because the form felt long. The compliance lead believed users were confused by identity verification. Customer service had heard complaints about blurry ID photos. Analytics showed where people left, but not why. Engineering knew that some errors came from a third-party service, yet that detail had not reached the design discussion.
They were all preparing different dishes in the same kitchen.
The problem was not a lack of design methods. The team already knew how to interview users, map journeys, run usability tests, and create prototypes. The problem was deciding which people, tools, techniques, and sequence made sense for this particular situation.
Design Your Design Work is the ability to shape the design effort itself. Before deciding what the product should become, a designer makes choices about how the team will learn, create, test, and decide.
It is design applied to the work of designing.
🥕 First, Decide What the Team Needs to Learn
Back in his kitchen, Shafira stopped collecting recipes and checked what the evening required.
The guests would arrive around seven. His mother could help with the sambal. His younger brother could buy ice and refill the gas cylinder. One guest did not eat seafood. The children would need something mild. This was not the night for a complicated new recipe that demanded two hours of uninterrupted attention.
The constraints did not reduce his creativity. They gave it a useful shape.
Shafira brought the same logic to the registration project. Instead of beginning with screens, he wrote four learning questions on the whiteboard:
- At which moments do first-time users hesitate or stop?
- Which problems come from comprehension, trust, technology, or the surrounding environment?
- What does the team already know with confidence?
- Which assumption would be most expensive if it were wrong?
Those questions changed the plan.
The team did not need a large survey first. They needed to observe a small number of people attempting registration on their own phones, in realistic conditions, while also reviewing support tickets and technical error logs. They invited customer service and engineering into the research planning session because those colleagues held parts of the context that design did not.
The point was not to choose the most fashionable method. It was to choose a combination that could answer the questions at hand.
A workshop is not automatically better than an interview. A prototype is not automatically more useful than a conversation. A design sprint is not automatically the right response to every urgent brief. Methods are ingredients. Their value depends on what we are cooking.
🧺 Gather the Ingredients Before Choosing the Recipe
Teams often treat process as a fixed sequence: empathize, define, ideate, prototype, test. The sequence is easy to remember, which makes it tempting to treat it as a prescription.
But real projects rarely arrive as neat textbook exercises.
Sometimes the team understands the problem but lacks viable possibilities. Sometimes a concept exists, yet the team does not understand the social context around it. Sometimes the biggest uncertainty is technical. Sometimes the product has already launched, and the work begins with strange behavior in the data. Sometimes the right next move is to build something. Sometimes it is to slow down and listen.
The Stanford d.school frames design abilities as capacities that can be combined according to the situation. This matters because a capable designer does more than execute a familiar process. A capable designer composes the work.
For Shafira’s team, the first week became a deliberate mix:
- Review the funnel and error logs with engineering.
- Listen to customer service calls and group recurring complaints.
- Observe six first-time users registering in different settings.
- Create rough prototypes only after the team could name the most important uncertainties.
The plan was not sacred. It was a starting hypothesis about how the team might learn.
That distinction is important. Designing your design work does not mean producing a beautiful project plan and defending it at all costs. It means creating enough structure to move responsibly, then adjusting when the situation teaches you something new.
🔪 The Right Tool Depends on the Cut You Need
While preparing dinner, Shafira used a heavy stone mortar for the sambal, a small knife for peeling shallots, and the rice cooker for what it did better than he could. He did not use every utensil he owned simply because it was available.
Design tools work the same way.
If the team needs to understand behavior in context, observation may reveal more than a polished survey. If people struggle to explain an experience, asking them to show the last time it happened may be more useful than asking for a general opinion. If the biggest risk is whether users understand a label, a simple clickable prototype may be enough. If the risk concerns trust in a high-stakes service, five disconnected screens may not recreate the experience required to learn.
In the banking project, observation revealed something the team had not expected. Several users did not abandon registration because the form was long. They paused when the app asked for a photo of their ID and a selfie. Some were registering in a commuter station or a crowded warung. They did not feel comfortable taking out an identity card or photographing themselves there. Others worried about what would happen to the images after upload.
A shorter form would not solve that.
The team’s original solution was based on the assumption that speed was the primary problem. The research showed that context and trust mattered just as much.
Because Shafira had designed the learning process before designing the interface, the team discovered the wrong assumption while it was still cheap to change.
🍳 A Process Is a Recipe You Keep Tasting
Halfway through dinner preparation, Shafira tasted the soup. It was too sweet. He added salt, squeezed in lime, and reduced the heat. The plan changed because reality had spoken.
Good design work has the same rhythm.
After the first three observations, Shafira’s team updated its questions. They added a trust-focused interview prompt, asked participants where they would feel comfortable completing identity verification, and built two low-fidelity concepts. One concept explained why each document was needed. The other allowed users to save progress and continue later in a more private place.
Notice what happened. Research did not sit in one phase and end. Prototyping did not wait politely for a formal handoff. The team moved among learning, synthesizing, making, and testing as the problem became clearer.
Design Your Design Work gives that movement intention. It helps a team ask:
- Who needs to be involved now?
- What do we need to understand next?
- What level of evidence is enough for this decision?
- Which activity will reduce the most important uncertainty?
- What should we change in our approach based on what we just learned?
These questions turn process from ceremony into judgment.
🕰️ Design the Conditions, Not Just the Calendar
There is another part of this ability that is easy to miss. Designing the work also means creating the conditions in which people can contribute well.
Shafira noticed that the compliance lead rarely spoke during open brainstorming sessions. When invited to review a nearly finished concept, however, she would raise constraints that forced major redesigns. Instead of blaming her for arriving late, Shafira changed the collaboration format.
Before the next concept session, he sent a one-page note describing the questions, known constraints, and areas still open. During the session, participants first wrote concerns individually, then discussed them together. Compliance expertise entered the work early enough to guide possibilities rather than merely reject them.
The team did not need more meetings. It needed better-designed participation.
Just as a kitchen works differently when ingredients are within reach, responsibilities are clear, and the stove is ready, a design team works differently when people understand the question, know what kind of contribution is needed, and have a format that allows them to contribute.
🍽️ When Everyone Arrived After Maghrib
At seven fifteen, the bell rang. Ten guests had indeed become fourteen.
Shafira was not calm because everything had followed the plan. It had not. The chicken needed longer. Someone brought extra children. His brother returned with ice but forgot the crackers.
He was calm because he had designed a setup that could absorb change. The rice was ready. The sambal could be served separately. There was a mild dish for the children. The main ingredients were prepared, and other people knew how to help.
The dinner worked because the work had been designed before and during the cooking.
Product design is similar. We cannot remove every surprise from a project. We can choose how we prepare, whom we involve, what we need to learn, which tools fit the uncertainty, and when the plan should change.
The strongest designers are not the ones with the longest list of methods. They are the ones who can look at a situation and compose a thoughtful way forward.
Before you open Figma, schedule a workshop, or repeat the process that worked last time, pause for one question:
What kind of design work does this situation actually need?
🧺 Takeaways to Bring Into Your Next Project
- Design Your Design Work means deliberately choosing the people, tools, techniques, sequence, and working conditions for the situation.
- Start with what the team needs to learn, not with a favorite method or expected deliverable.
- Treat the process as a hypothesis that can change when new evidence appears.
- Design participation so relevant expertise can shape the work early.
- Constraints can focus creativity when they are understood, shared, and used intentionally.
P.S. Next up:
“Learn from Others: Like Watching a Barista Who Knows Your Order and Your Mood” 👀
🔗 About This Series
This is article 1 of Designerly Thinking: Eight Core Design Abilities, followed by a reflection epilogue. The abilities come from the Stanford d.school and are not intended as a rigid sequence.
- Design Your Design Work: Like Setting Up Your Kitchen Before You Cook
- Learn from Others: Like Watching a Barista Who Knows Your Order and Your Mood
- Synthesize Information: Like Sifting Gold from Sand to Find Meaning in Messy Research
- Rapidly Experiment: Like a Chef Testing Small Portions Before Serving the Full Menu
- Move Between Concrete and Abstract: Like a Doctor Connecting Symptoms to the Larger System
- Build and Craft Intentionally: Like a Watchmaker Engineering Every Gear
- Communicate Deliberately: Like a Diplomat Aligning Allies in a High-Stakes Room
- Navigate Ambiguity: Like a Captain Forging the Route Through the Fog
- Reflection: Like a Warung After Closing, Turning a Busy Day into Better Judgment
Design Your Design Work: Like Setting Up Your Kitchen Before You Cook 👩🍳 was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.
