Thread by @MorelloNMST

Today’s post is a break from the individual steps, and defining the process I see in design.

1. Set goals
2. Form solutions
3. Execute
4. Evaluate outcome
5. Iterate

We’ve covered steps 1 and 2 in our earlier posts. Let’s talk about the overall process a bit more.

The process is there is similar to a lot of creative efforts, like writing, performance or art.

My goal with these posts is to demystify design. All creative efforts seem like dark magic externally, but design is a learnable, teachable craft all its own.

With so much potential fuzziness and subjectivity involved, even the most hardened professionals need some structure and order to their efforts to keep on track.

I’d say not using a structured process as a designer is irresponsible in a professional setting.

Even when “Finding the fun” as a famous design legend at my new studio says, it’s still using a process to make sure iterations = progress.

Our goal is to improve the game, not laterally change it, when we do design work. This is why 1 and 2 set that target.

It also assumes we’ll miss something in the process. No author or artist ships their first draft, no engineer bypasses code review. This is simply a drafting and refining process for those unfamiliar with it in other fields.

Now, on to how this works!

* These steps are sequential. Order matters.

Each step’s job is to set you up for success in the next phase. Problem solving without goals is flailing, executing without a solution in mind is work for work’s sake. Iterating without evaluation is RNG.

There’s strict dependency!

With this, when we see a problem in the design, we should look at the root cause of it.

Faults in an earlier phase will have a rippling effect. If our goals are off, everything else will be too. If our solutions don’t meet our goals, evaluating that is really challenging.

* Make sure you’re debating the same step

Designers will argue about execution or the solution when in fact they disagree on the goals. Or will avoid good goals for fear of a specific execution.

This is a huge trip up - even for a lot of senior folks. It’s just not well-taught.

A good tip for any aspiring designer, or player looking to give good feedback is to zero in on the issue. Is this a goals or solution problem? Are the iterations trending s way that doesn’t match something earlier?

State this aloud. Get people on the same page.

* When problems seem really difficult, review previous steps.

Similarly, going backwards in the process when stumped can reveal new information your work has uncovered. Maybe the solution doesn’t match the goals as you work, but maybe the goals are off!

It’s ordered, not rigid

* Never let the tail wag the dog

That is, never let a solution define the goals without discussing what that particular solution is teaching us about the goals. Always walk backwards and reapproch earlier steps if needed.

This is a critical teamwork skill.

Designers disagree. A LOT. It’s normal, and when in a well-functioning team, an awesome thing.

But when you disagree, don’t try to ram your version in to show your vision. That’s both counterproductive and shitty - you might get a temporary win at best, at a huge trust cost.

This seems like a whole ass post too - how to disagree but be aligned.

VALORANT’S design team was really good at this by the end. But we’ll save that one...

Using a process like the one listed here is a great way to structure design, and be more likely to ask the right questions, have the right discussions and make sure work = progress towards a better game.

Tomorrow has no post - long drive day- but we’ll be back Tuesday for more!