Three Projects, Two Designers

The common mistake is how practically everyone begins as a designer, myself included. To show how it plays out, I'll use three situations I've found myself in many times, both on my own projects and on other people's projects I joined:

• Creating something completely new.
• Creating an improved version of something old.
• Working on someone else's existing project to make it better.

(By "old" I mean anything no longer in development. That could even be a project that was finished or abandoned last week.)

For each one, I'll show how I would have approached it as an Unaware Beginner, and then as an Experienced Specialist. Some of the specialist's reasoning leans on the needs and feelings explained in Understanding Human Beings, so if a step sounds strange, feel free to come back here after reading that chapter.

My project: creating something completely new#

The inspiration#

I was inspired by an anime with giant robots fighting in space, shooting huge beams of energy that melted and exploded whatever they hit. The robots were piloted by humans like jet fighters, with an amazing sense of speed, power and agility. They fought in all kinds of places, against all kinds of enemies, with all kinds of mission objectives. The whole thing was epic, breathtaking, awesome. The way the robots, environments and weapons interacted gave a sense of infinite possible situations in every battle.

But watching it was passive. I could only enjoy the short, scripted experience I was shown. It was pleasing to look at, but I wasn't doing anything besides watching someone else do stuff. That wasn't enough. I wanted to be there. I wanted to pilot one of those robots, go to space and blow things up.

Alongside the anime, I listen to energetic music (drum and bass, jungle, liquid, trance, metal and random other tracks) that makes me feel free/powered/energetic/focused/serious/alive/aggressive. Much like the anime, listening to it felt passive, which made it somewhat frustrating. I felt energized, but had no outlet to spend that energy on. No existing game had the fast pace, unrestrained momentum, attractive theme, challenging difficulty and sense of empowerment that I was looking for.

Usually I'd satisfy this by riding my bike in the real world while listening to that music. I'd go fast, keep the momentum going, feel empowered, get healthier (which gave it meaning), and get challenged by staying safe and navigating unknown areas.

Thing is, I don't always want to ride a bike. I have limited stamina, so I can only go as fast as my body and bike allow, which sometimes leaves me wanting more speed. A bike doesn't let me fly over the sea or travel through space at Mach 20. It also doesn't come with a nuclear plasma cannon, and I don't want any actual destruction or violence happening in real life either.

On top of that, I had a lot of built-up anger, oppression and frustration from various circumstances in my life. A peaceful, nonviolent (real-life wise) way to release that tension through video game violence seemed like something that could help me calm down and find the patience and strength to deal with things.

Finally, there was the need for money to pay for shelter, food and bills. Selling a game seemed like a good way to solve that too. And my game idea was ethical: it wouldn't use dark design patterns or manipulation, so I'd be happy to create something that could be a shining example of game design done right.

All in all, a video game seemed like the best way to make this happen. And it's important to notice what that inspiration really was: a new, possibly better way of meeting my need for excitement, action, fun and power, which I had been meeting through other activities before. Only a possibility. In the middle of the hype I might be completely wrong about it being better than what I already have, and there might be better ideas I'll only see once I try the real thing. Until I analyze the inspiration further, or build it and see if it holds up, it just looks very attractive.

So now I had to design the game.

The Unaware Beginner's approach#

First I'd think about what I want to see in the game, based on what inspired me most and what I think would be cool. I'd remember the anime's robots, guns, opponents, environments and scenes and want them all recreated. I'd use the anime as the style guide for the look and feel. I'd make sure the music matched those genres and that the gameplay connected with it. I'd look at existing games and traditions, and copy whichever popular ideas I personally found attractive.

Most importantly, whatever my inspiration was, my goal as an unaware beginner would be to mimic it. To bring it to life as I had seen it and enjoyed it. I would not go into the real reasons why I enjoyed it, or the root causes that made the inspiration so powerful. I'd copy its essence as I saw it on the surface.

Then I'd try to combine all of this into a single product, using my previous knowledge and experience to judge whether each idea was good or bad. That knowledge came from a lot of trial and error with this very method: noticing flaws and strengths in games I'd played, designed or watched, remembering them, and comparing new projects against those old examples, hoping it would make a better game.

Here's the catch. I could only see those flaws and strengths after a project was finished and I had tried it. This approach can't spot a flaw before it's built, unless I already knew the answer from experience. It also can't tell me why something is a flaw or a strength, or where it really comes from. The interconnected system of human, hardware and game that makes up a playing experience can easily fool me, and I have no method to verify my guesses.

So I might think that more guns, more robots, more explosions, multiplayer, leaderboards, punishments and rewards, character customization, an open world, a leveling system, permadeath, more content, an epic story, more realism, voice acting and higher-resolution graphics will make a better game. Just because tradition and popularity say so, or because other games did it and seemed better for it.

Likewise, because of tradition and popularity, I might think badly of grinding, overpowered content, short games, simpler graphics, lack of story, simplified interfaces, single-player cheating, or whole platforms, styles, themes and genres. Again, just because they're commonly looked down on, or because someone said so.

This approach is the easiest, most convenient and most obvious thing to do. "Someone already did something seemingly right, so it's safe to copy them and expect it to work." The problem is that this method is horrible, even suicidal. I'm only looking at the surface of whatever I'm copying, not at the root causes underneath it. I'm completely blind and have no idea what I'm actually doing.

I might get lucky and stitch together enough good decisions to make something above average, but I'd be missing out on a gigantic amount of potential with no awareness of it, let alone any way to harvest it. And repeating a success would get harder with every project, because I wouldn't know what caused it.

To an unaware beginner, this looks like a great approach that obviously makes sense. In reality it's the opposite. It tricks you into bad decisions, makes you less likely to verify ideas yourself and produces blind results at worst.

The Experienced Specialist's approach#

The first thing I do is remind myself that playing or making games is a strategy to meet fundamental human needs. Nothing more, nothing less.

Then I look at the inspiration and at the vision that came from it, and ask how each makes me feel. Here the inspiration is the anime of giant robots blowing things up (plus the music), and the vision is my plan to make a game out of it to meet the need that the inspiration stirred up in me.

Feelings are an automatic, natural function of the human body that point toward fundamental human needs. So next I connect the feelings I noticed with the needs behind them. Some are obvious and I can name them instantly, others I find by process of elimination, using a list of needs and a list of feelings when I'm unsure.

So my vision is to pilot giant robots and blow things up, fly fast and dodge hazards, woven together with energetic music. I want to feel powerful, free and unrestricted. I want to discover and be surprised by unpredictable situations. I want the whole thing to have ongoing momentum, so I could enter a flow state and keep enjoying it without abrupt breaks. I want to be able to play it endlessly, but I want it to feel meaningful and fresh every time. I'd like it to be easy to pick up any time and get a complete campaign in about 30 to 60 minutes. And I want the game to respect me as a human being: not wasting my time, never removing my autonomy, keeping me aware of the real world (reminders to drink, eat and sleep, showing the real-world time) and generally empowering me instead of enslaving me.

Where did all those wants come from? From many sources of inspiration over the years. Some showed me new things I could do, others left me wanting something better. My mind collected them automatically, stored them and eventually connected them together by chance. This happened through a lot of "procrastination", exploring and experiencing everything around me, in the real world and online. Everything I've ever been exposed to went into my ever-growing library of references. That's where I get ideas from, and where I form judgements from.

Looking at the vision, I notice feelings on both sides. The feelings driving me to create it: frustration, disgruntlement and annoyance, because this solution doesn't exist yet or is flawed, and excitement, inspiration and hope, because this could be a real chance at making my life more wonderful. And the feelings I want the game to give me: stimulated, amazed, empowered, joyful, energetic, lively, awed, strong and free.

Translated into fundamental human needs, it's pretty clear. From this project, I need freedom/autonomy, power/capacity, challenge, variety/novelty/surprise and play/joy.

Once I've confirmed that these are the needs I want this project to meet, I have a focused purpose. If I'm not sure yet, I keep working through the feelings and needs until I've confirmed them all. I can't continue until the purpose is as clear as possible.

And suddenly I have the most powerful tool in the world for making this game's design the best it can be. I know what I truly want, so I can quickly settle any design decision toward the best option available.

I can now bypass traditions, popular memes, prejudices and dependence on other people's opinions. I can think with my own brain and come up with effective solutions for any situation, big or small. I can avoid mistakes I'd otherwise only learn about afterwards through trial and error. I can see whether something will work before even trying it. I also get a clear, endless source of motivation, total independence of thought, ownership of the project, and the ability to look at successful games and understand exactly what made them successful, down to the tiniest detail. It doesn't get better than this!

How the specialist answers design questions#

Starting from the most mundane basics: will it be 2D or 3D? Which camera view? Which platform? Which technology? What kind of graphics? How big is the scope? How will it work, what will it have, how will its content be made? Will it even be a video game, or a board game, a card game, an outdoor activity, an interactive movie or something else entirely?

These questions arise naturally, out of necessity, especially when you're rushing to build something on the high of a fresh inspiration and suddenly run into the nitty-gritty details. With a clear purpose, they're all answerable.

For each question, I find all the options available. I search, ask, look around and research, both in real life and online, to gather every possible and probable choice. I also listen to my gut feeling about the options I've found and about whether I should keep looking for more.

Then I ask myself: "Which of these options serves the purpose best?" If my answer for an option is "I don't know", I test it in the fastest, easiest, cheapest way I possibly can. The point is only to gather information, so these tests are temporary, disposable experiments that take no more effort than necessary.

For example: "2D side view or 3D third-person view, which one suits my project best?" I'd imagine the game in both views, look up existing 2D and 3D games to see how they feel, and make cheap/crappy doodles with pen and paper to picture both options in every situation I can think of.

Since I want speed and high maneuverability, and I'm meeting a need for freedom, I'd eventually find that a 2D side view is more restrictive. I can't see far ahead, and a side-view screen is too claustrophobic to notice fast objects early enough to react. A 3D third-person view lets me look far toward the horizon, see objects way earlier and react to them easily. So the 3D view feels better, because it's more likely to meet my need for freedom, speed and control. I've just found the best option of the two.

The process is always the same:

1. Lay every possible option you can find on the table, any way you can.
2. Get familiar with each option.
3. Compare each option with the purpose of the project, one at a time.
4. Choose the option that serves the purpose better than the others.

Use the cheapest, lowest-effort methods to test and get familiar with the options you don't know. It's okay to be unaware of something and say "I don't know". What's not okay is to ignore it afterwards. Always say "I don't know, but I'll find out", never "I don't know, so I'll ignore it forever".

Also be aware that we're always limited to what's available to us. If something exists but nobody told you about it and there's no convenient way to find out, then that option, however amazing it is, doesn't exist for you until you discover it. That's why it's a good idea to explore, experiment and go places no one has gone before: the undiscovered options can be revolutionary. Keep your mind open to unknown possibilities.

With this process I can answer any question, of any complexity, size or significance, until I arrive at the complete design of my giant-robots-shooting-lasers-in-space game. As the project goes deeper, many more questions arise: Which style or theme is best? Will feature X make the game better or worse? What's the best structure for the menus and HUD? Does the game even need a HUD? Which controls? How do I best meet the need for meaning? What's the best metagame? How does the game start, progress and end, and how does the program itself start and end? How does the game's universe work, what laws of physics apply, what scale is everything? Which robots, which abilities, which enemies? Does it need lore or a story at all, and if so, how to present it? What's the minimum viable product, and how do I know when it's good enough to release? What marketing, monetization, pricing, funding and release strategy fits? What font? What sound design?

Using the same method, finding the best answer to each of these is no problem whatsoever. The answer may not be instant, but it's always inevitable and confident. Notice that the questions reach far beyond the game itself, into marketing, monetization and management. Contrary to popular belief, those are an essential part of game design too.

Some questions only become answerable once others are answered. In game design many things depend on each other. Before I can answer "what color should the main menu be?", I first have to have answered yes to "does the game need a main menu?".

At the core of it all is one question: "Does this serve the purpose of the project?", or "Does this bring me closer to fulfilling the purpose?"

That's the only question you need. Check the purpose. Check the needs behind it. Check how you feel about it. Do they match the option you're looking at? If yes, do it. If not, don't. If you don't know, test it and gather information until you do.

If a feature is essential to the purpose, the project can't succeed without it. If it's irrelevant, secondary or even opposed to the purpose, including it will be a disaster for the project and waste your time.

My project: an improved version of something old#

This one covers sequels, reboots, remakes, prequels, expansions, remixes and anything else inspired by an earlier project. It's happened to me many times, and I've watched it happen to others even more, so instead of one specific example I'll explain the general process, assuming I'm making a sequel to a game I liked.

The process is very similar to creating something new. The beginner follows traditions and popularity and enhances an imitation of the original, hoping it works out. The specialist finds the inspiration and the feelings and needs behind it, and uses them to guide the design. The only difference is that instead of starting from nothing, there's now something existing that I start from and have to take into account.

The Unaware Beginner's approach#

I'd analyze the old game at face value, listing the features I thought were good and the ones I thought were bad.

By "good" I mean the feature made the game better. For example: an art style whose shapes, colors and tone made the world feel real and wondrous. Enemies bursting into meaty chunks with squishy, impactful sounds, which made combat feel tactile. An overworld map that gave a sense of place and progress. A leveling system that made my character stronger and richer the more I played. Multiplayer that added surprising, intelligent human companions or opponents. Big, impressive explosions that simply felt epic.

By "bad" I mean the feature damaged the experience. For example: an interface and controls too complicated for a casual player with limited time. A cash shop that broke the game's balance and the trust of long-time players. An unskippable tutorial that wastes the time of everyone who already knows the basics, especially returning players. Grinding, meaning repetitive actions done not for their own sake but for some extrinsic gain, which is the very opposite of having fun. Gimmicks, features that are special only for the sake of being special, which break the consistency of the game's universe and make it hard to take seriously.

Then I'd keep the good features, remove the bad ones, and make the good ones bigger, more advanced and more complex. I'd also look at what's popular, traditional or requested elsewhere and try to integrate those, to make the new game bigger and better.

This is a dire mistake. My process has no foresight about whether any of it fulfills the purpose of the project. It only sounds effective because I don't know the root causes that would reveal how poor an approach it is. Things that are popular or traditional aren't guaranteed to be compatible with or useful in another project. They can damage or even destroy it. And be aware that a frighteningly large number of game developers, including many very prominent ones, are designing blind like this. Following them without question is the blind leading the blind.

The huge thing to notice is that the old game was made with a certain mindset, which shaped how its features were chosen and built. (At least usually. Sometimes a game is designed well by accident, through intuition.) The beginner making the new game has no understanding of that mindset or that purpose. I'd think I knew the purpose by looking at how the game works, instead of at what inspired it. So I'd be confident that the features I remove really are the cause of the bad parts, and that the features I add will fit, when neither is guaranteed.

It gets more complicated. If the original developer was also an unaware beginner who happened to make something that seems to work, I might think the original design was flawless, not realizing that many of its parts weren't made with a purpose and probably aren't the best solution for that game. A lot of potential gets missed this way, and the new game ends up a shadow of what it could be.

Players notice that wasted potential, especially the longer they play or the more similar games they've played. It leaves them sad and frustrated, because they needed more wholeness from the game. Their enjoyment drops, sometimes to the point of ruining the whole experience, and they leave.

Even if I accidentally made an engaging game this way, I'd only be scratching the surface of what's possible, and I wouldn't know why it worked. I'd credit my "improvements" while the real root causes stayed hidden. Otherwise, this approach is blind and can end with a result worse than the original, without me ever knowing why it failed.

The Experienced Specialist's approach#

Instead of looking at the old game's features at face value, I try to find out what its purpose was.

The most direct way is to ask the original creator what they were needing and feeling when they made it. I'd collect as much information as possible: what inspired them, why they chose certain designs over others, and what they expected from the project back then. I try to hear the human being behind it.

Be aware that even the original creator might not know the purpose. They may have had an intuition they can't put into words, or brute-forced it through trial and error until something resembling their wish appeared as a happy accident.

It's also quite possible the project was made for an extrinsic purpose: the game was less important to its creator than what it gave them. Maybe it was a stepping stone for learning, growth, money, influence, social acceptance or community, or the fun of the development process itself, with the game as a side effect. In that case their purpose won't be useful to me, because there's a disconnect between what inspired me and what the creator was after.

(A side note: if you intend to follow that extrinsic purpose yourself, you'll find it very hard to get any useful guidance for making an engaging game. You'd be developing a game you're not interested in playing, while expecting others to be interested in it. That path leads to ruin, don't take it. Making Games for the Wrong Reason explains why.)

For that reason, or if the creator isn't available (reluctant, busy, unreachable or dead), I can find the purpose myself by investigating the game. If the creator's purpose was extrinsic, the purpose I find will be different, because it's based on the game's own merit. It's a more personal purpose: what I want from the game.

One more thing to consider is my own intention. Do I want to preserve the old design at all, or am I open to overhauling it to meet its purpose in a different way? If the old game was designed with a clear purpose, that's a matter of preference. If it wasn't, overhaul is mostly the only option, except for pieces of accidentally fitting design that clearly serve the purpose. Those can be salvaged.

So how do I find the purpose myself? Instead of analyzing mechanics, features and systems like the beginner, I play the game and explore my experience of it by asking:

• What am I feeling when I play the game?
• What do certain parts of it make me feel?
• What does each detail make me feel?
• What do I want to feel from this game, from its parts, and from each detail?
• If I'm developing it for someone else: what do they want to feel from it, its parts and its details?

I write this down in whatever way is most comfortable, pen and paper or a document, so I can always come back to it. This is very important information. These feelings work as a compass that always points toward the best solution when I review ideas, because feelings reveal met and unmet fundamental human needs.

Once I know the purpose, it becomes very clear what's beneficial or harmful to the game. I can add and remove features with confidence, knowing my decisions come from a real reference that's always available inside me, instead of brute-forcing a design or forcing in features just because they're popular or traditional. I can see the true form of every detail and how it serves or damages what the game is trying to achieve. Fixing old mistakes and finding new opportunities becomes clear and doable.

Someone else's project: making an existing project better#

In this situation I'm joining a lead developer or a team who are already working on a project, as a partner or an outsider. My job is to help with the game design, whether I arrive at the start or in the middle. I'll analyze the existing plan and then either give feedback on how to improve it or take over the whole design as my responsibility and make sure it succeeds. By "succeeds" I mean it meets the requirements and desires of the people I'm working with.

Said more plainly: my task is to give them what they really want. They have a dream of some sort (a need), and probably an existing concept (a strategy) that they believe will achieve it. This isn't my project or my initiative. Whether I'm there as an enthusiast or as a contractor, the priorities of the people who own the project come first. I'm there to help their dream come true. The way I do that is by making sure every design decision ends up serving it, so the game comes out as one coherent design instead of a pile of separate wishes.

I might arrive at the start of the project, during development with a prototype and plans, during beta with a mostly complete game, at launch with updates still coming, or at the post-mortem to explain why something worked or didn't. Each situation is different, and none is simply better than another. The start looks like the most flexible place to come in, but if the team is open to overhauling or killing the project when the evidence shows its design is headed for failure, a later entry is just as open. An existing design can be helpful or annoying: if the team reveres certain traditions, convincing them takes work, but an existing design might also provide a working framework or useful pieces, or at least a clear warning sign. There's no good or bad entry point, only different ones.

Providing game design is a position of great responsibility and power. What I design affects everyone on the team, because design dictates every aspect of the product: code, art, audio, marketing and the design itself. Everyone will be putting a lot of trust in me, so I want to honor that and make sure my partners' needs are met with the same importance as my own. That includes listening to them, giving them a recap of what I heard them say, and asking them to do the same for me, so our communication is verified, fair and compassionate.

Lastly, I stay alert to the possibility that what my partners intend isn't what they're actually doing. They say they want A, but they're doing B, which may lead nowhere or even to the opposite of what they want. I need to be able to detect this and translate between what they ask for and what they actually want. That takes honest, open, firm observation without judgement.

The Unaware Beginner's approach#

I'd start with two things. First, I'd look at all the existing material (work, doodles, notes, documents, images) and play any prototypes, demos or experiments, and take an educated guess at what's being created and why. Second, I'd ask my partners as much as I can about what they want to create and what they want from me. These are the six core questions:

1. What are you trying to create?
2. Why do you want to make it?
3. What inspired/prompted you to create it?
4. How would you like the final result to be?
5. What would you consider success for this project?
6. What would you consider failure for this project?

I'd also keep asking "why?" to follow up, because I expect the answers to be vague, dismissive or incomplete. I can't expect others to be skilled at game design or at communication, so my partners may not know what's important to mention, or how to put it into words. It takes patience to keep going until I fully understand what they want.

Clear, complete communication with my partners is critical. Even if I have better ideas than they do, those ideas will be resented, and I'll struggle to make any progress, if I don't connect with and listen to my partners first. I must never try to meet my own needs while ignoring theirs, or keeping a relationship of trust and willingness to help each other becomes extremely difficult.

To drill deeper into their plans, I'd use two more questions:

• "Why do you think this will work?" (Can you explain it in your own words? I need to understand the logic behind this idea. How did you come to that conclusion?)
• "How would you achieve that?" (I'm unsure how this thing will solve that thing. Can you clarify the connection? How certain are you that this will work? I need clarity on this.)

With these, I can check whether an idea's logic fits what the project is supposed to achieve. If it does, the idea has a good chance of success. If an idea is too complex to judge and I've never seen it in action, it may hide subtle flaws, but I can catch most of them by testing it: either with a quick, crude experiment, or with pen and paper in a mind dump. That means writing down the idea, everything about it that feels unknown or uncertain, its pros and cons, the alternatives and their pros and cons, and anything else remarkable about it. It's completely free-form. The point is to get everything out of my head onto paper, where I can see the problems and benefits before testing anything live.

After all that, I think about how I can contribute, depending on what stage the project is at. Up to this point, everything I've described is exactly what the specialist does too. From here on, the paths split.

As the beginner, I'd look for existing examples, traditions and popular trends to decide what to do. And as usual, this is where things go wrong. Without understanding fundamental human needs, no clear purpose can be found, because that understanding is required to find one. I have no method to verify whether design decisions really work. The project's chances of success are random. I might get lucky, but I'd only find out after release, when it's too late to fix the core design, and the sequel, if there is one, is doomed to repeat the same blind cycle.

The Experienced Specialist's approach#

Everything up to the point of actually designing is the same. The key difference is a much closer focus on fundamental human needs and on the feelings the finished product is supposed to deliver.

When looking at the existing material, I don't stop at guessing what's being made and why. I also ask myself:

• What needs is this project trying to fulfill?
• What is it trying to make me feel?
• Why do my partners want to meet these needs in this particular way?
• Why do they think this strategy will be effective?

These are my own educated guesses, and they'll be useful to compare against my partners' answers to the six core questions. And when I ask those six questions, I don't stop at the answers either. My goal is to understand the feelings and needs driving the answers, what's going on beyond the logic. So I expand each one with a follow-up:

These follow-ups give far more accurate information about what my partners are really striving for, because the conversation now focuses on feelings and needs. Without them, the focus would stay on the strategy for getting those feelings and needs met, not on the feelings and needs themselves, which are the root cause that inspired the strategy in the first place.

The beginner was concerned only with the end result and the plan to reach it, trusting that the partner knows what they truly want without verifying it. The specialist doesn't take what the partner wants at face value, but reads between the lines to find where the plan came from and why. I trust my partners' intention, but I always double-check. Failing to verify what they actually, truly, really want can be enormously expensive: tons of effort, time and resources poured into something that wasn't even what was wanted.

It's very easy to fall into the false security of believing a person is 100% sure of what they want. Unless they're very aware of their own feelings and needs (through NVC or something similar), there's a real risk that their plan is flawed or even works against what they desire.

Once I have clear feelings and needs from my partners, I review all the existing plans and material with the same two questions, "Why do you think this will work?" and "How would you achieve that?". And I ask them many, many times, not once. I ask them about every single detail: menu structures, character designs, narrative, mechanics, color palettes, fonts, audiovisual style, metagame, monetization, marketing, publishing, everything. No matter how small, even the color of a character's shoes. I want to know what drove every existing decision.

To a beginner this looks like overkill. But every single detail matters and can have a huge effect on the project. If some decisions were made because "this is popular elsewhere" or "everyone does this", instead of following the purpose and the needs behind it, those decisions can cripple the final product. They're rot that contaminates the rest of the project if nobody questions them. I'd be failing catastrophically at my responsibility as a designer if I let any of it go unquestioned.

Then I compare the two things I now have: the purpose (what my partners truly want the project to fulfill) and their current plans, content and ideas for fulfilling it. Where I don't know the consequences of a plan, I find out however I can: knowledge from the internet, people, finished products and research, experiments and tests, or logic and pen and paper, which is very effective and saves the expensive option of building a working prototype.

While comparing, I find that the existing material either supports the purpose or it doesn't. If it does, it's good, though I still double-check, and I stay alert to good plans that could become even better. If it doesn't, it's unsuitable and needs to be removed, changed or reorganized.

When that's done, I have a very clear understanding of what the project needs. I know what my partners really want, not just what they claim to want. From here I can finally act, and I always know what's missing, what the next step is and how to take it. Even if a step's outcome is uncertain, I know I'm on the right path, because a crystal-clear purpose is a bulletproof reference I can check every action, decision and idea against. Anything that doesn't line up with the purpose is poison for the project, so it's easy to avoid.

If something's consequences are unknown, I find out before putting it into the design: experiment, use logic, use pen and paper, test it. Putting something into a design without understanding it is far too risky. In the worst case, a single wrong idea can cripple a project's potential.

And with every contribution I make, I keep the team informed of what I'm doing and why, and I listen to their feedback, in case a better idea surfaces, I misread the purpose or something bothers them. We're making this together. Even when the team says they trust me to just go ahead, I'd still rather present proposals before implementing them, to keep the communication thorough and the connection tight.

That's how I'd approach a team project as the experienced specialist, and that finishes all three situations. The pattern is the same in each: the unaware beginner experiments blindly with solutions that seem appealing, while the experienced specialist focuses on the purpose through feelings and needs, and creates tailored solutions with clarity and confidence.