How can we build trust as game designers? This is a question I’ve been asking myself, and in doing so came across an awesome video by James Everett, Lead Game Designer at Magic Leap (talking at Game Connect Asia Pacific).

In the above video James discusses the following.

Saruman vs Hobbit

Don’t be a Saruman, someone who ‘dispenses wisdom’ from an ivory tower. Instead be a hobbit. Be a comrade, a facilitator, filter, and collaborator for the people around you.

Trust

Everett breaks down trust into two components.

Logical

The logical component is based on the societal structure that we expect from normal, rational human beings, comprised of:

1. Contractual obligations
2. Past behavior
3. Following social norms
4. Following the law

Emotional

Emotional trust is:

• The default in healthy teams
• Reciprocal
• Pleasant and efficient

Everett then discusses three ways in which designers can build or break trust.

Build or Break Through

Clarity

A designer should be clear but not prescriptive (be the hobbit not Saruman!). Clarity is a foundation for trust, because it means members of our team don’t have to interpret what we mean.

Everett goes on to break down clarity into two types.

Self Clarity

One must understand their own ideas. If they don’t nobody else will. He suggests using a tool that works for you.

External Clarity

When a designers self clarity is sorted, they must then build external clarity using an appropriate method such as sketches during a meeting.

Designers should make the level of assuredness they have in what they are talking about clear. If they are not sure about an aspect of design they should clearly communicate that to avoid giving their colleagues a nasty surprise. As designers we should drop our ego, and not afraid to admit that there is something we don’t know.

Another important aspect is conveying to ones team why a design decision was made. Why is the deeper question that our coworkers ask. Knowing why allows others to appreciate our decisions, really take them on board, and question us in a more constructive manner.

Ultimately the best way to check external clarity is to have ones coworkers explain it back to you. If what they are saying matches your own ideas then great! If not it might be time to use some empathy.

Empathy

“The ability to understand and share the feelings of another” – Oxford Dictionary

Since internal iteration (in ones own mind) is super fast. When trying to communicate ones ideas to another, the complexity is increased by a magnitude of at least two. So as designers we must employ empathy when dealing with our coworkers, particularly when their thinking is different from our own.

Never say an idea is dumb, it is at best counterproductive. A designer should be happy to listen to other ideas, and find out the why behind them. If an idea doesn’t make sense explain why it doesn’t fit into the game. You have to listen to your team, these are the guys whose trust you need! Just consider the balance of the relationship in two days we can create months, even years worth of work for our coworkers (of course design never is as clean as that).

Part of empathy is self empathy. As designers we need to accept that we are going to be wrong at some point.

“I’m wrong so I’m one step closer to being right” – James Everett

Being wrong is okay! It’s usually has a rational basis. Maybe the decision was based on had incorrect information, or maybe the idea wasn’t what you thought it would be when it became a tangible prototype. If we discuss mistakes honestly and openly, it builds trust because those are values a team can appreciate.

Reliability

“Just because its the cool thing doesn’t make it the right thing” – James Everett

Designers should be reliable, exhibiting consistent behavior. They shouldn’t jump around the place with their design (from a platformer to a FPS overnight), and shouldn’t abandon their games design for something else that is cool at the time particularly when the rest of their team has bought in to the idea.

The design of a game is an internal process. So that means not brainstorming with non team members, and not making commitments outside of the team (don’t invent features at a press conference). Support the design your team has signed up for!

Now if you have to make a change or introduce a feature, make sure to telegraph that out as early as possible. Explain your why! Talk about the change as early as possible so that you avoid upsetting coworkers.

Conclusion

Trust is hard. Just look at the problem of computational trust. It is mind blowing. As a newbie designer who has stumbled enough for self awareness, I found this to be one of the hardest problems to tackle. That along with learning how to let go of ones ideas.

I’m realizing that as designers its important that we understanding that building trust important because I have found that if there is no trust in a team, then how can you trust that you’ll make a good game?