Hey guys, I am @aaafrancisc and this week I will be around, talking all sorts of game design topics with you, let's start!

Hey there @vibe_crc, nice to meet you

Hope you guys had a great end of the year. Nice to see this kind of initiative around, and glad to be part of it!

Over 7 years in complex game systems, usability, accessibility and UX. I do graphic design and I also do 2D art. Ask me a anything!

This is my twitter — @aaafrancisc, thank you for listening to my gibberish last week! :) Contact me and follow me if you like my face. Cya!

Let's start this day! What is the most annoying thing about what you do? Would love to hear some whiny game devs. C… twitter.com/i/web/status/8…

I will be talking about UX mainly, cause this is a subject not a lot of people cover in video games. My process? Ok - spam incoming😍

UX starts at the same time with design. When most of the elements in the design phase are laid out, UX is also starting there.

This is a presentation I worked on at some point and it blends UI and UX principles. Kinda outdated but still useful
dropbox.com/s/t38brrfgks60…

UX is wireframes and prototypes, information arhitecture, user research and interaction design. UI is visual design and typography.

One of the most important thing in UX is categorizing your information and consistency.

The first step into categorizing your information, is to lay down all of the elements that you will have in your game. Then make archetypes.

Archetypes of information such as - Account Info - Progression - Social - Resources

Second step is making an importance hierarchy between the elements of a single archetype

For example: Name of player is not as important as the avatar. Customizing the avatar is more important, so it needs to be more fleshed out

Another example: Ammo is more important than ClipSize. Ammo type will be bigger and positioned in a dominant composition with the Clip Size

Third Step: Position visual archetypes on the screen thinking of visual flow and visual ergonomy.

Visual Flow is how a player is following information, and how he is more likely to follow certain information with his eyes.

Visual Ergonomy is taking into account the Flow and try to position elements so that the player doesnt need to eye travel longer on screen

Note: You do not want the player to get tired following information, and traveling with his eyes from corner to corner of the screen

Step 4: You start prototyping and testing - This will give you valueable info if you missed something or you need to change something

While testing, do not ever put leading questions and influencing a play-tester opinion (will talk about play-testing on one of those days)

Step 5: Add conditions, refine them and count user steps, make user stories and see if they represent what you are aiming for in design

Mood of player is highly influenced by any kind of interaction and action before and while in the game. Pay attention to any kind of noise.

Get rid of noise and do not make compromises. Like in Architecture, there is always a solution, you just need to find a room for it.

Last but not least make changes in the UX respecting all other elements that you do not change. Every change is a change everywhere.

Also when a player comes and interacts with one of your core elements, that is indeed interaction...

...But you also have actions, sings and feedback, flow, behavior, emotion through logic, visual communication and other more.

Today we'll talk about playtesting and the importance of playtesting methods. Tricks and tips ahoy!

Rule 1: Choosing your right playtesters, whenever you test a mechanic or the whole game, their profile will affect the end result 100%

Error management in playtests are very important: biases, age, experience are all factors to take in account to tweak and interpret results

0 Friends! While their feedback is valuable, I find that when they know someone who worked on the game, they have a tendency to love it more

Rule 2: Playtest your survey before you playtest the playtesters survey, playtester. :)

What? You want to know your survey tests exactly what you want to know. You know well what is your interest, and you know what to ignore

I have done 1k playtests, and I hav always discovered things that could have been better. Think 1k times about how you phrase your questions

Rule 3: Do not lead questions, you are hijacking your our playtest. What does this mean?

Do not try to ask things like: "Hey do you like that mechanic?" or "Hey, that's really accessible?". Nope, do not influence them.

It's better not to distract - observe and listen, answer and note.
Another leading question example: "The controls are really sleek, right?"

Pointing at the UI small element that wasn't noticed and yelling "Cmon man! You just need to pay attention to the objective!" Don't do that.

Step 4: 1on1s - Same goes here, no leading questions, get more personal and listen to everything, ideas, and do not come up with excuses.

Excuses like: "The game is not finished" or "We are just trying things out" Don't be a weakling. Listen and note everything.

It's important to do 1on1s and not 1on2s, they influence each other in a playtest interview.

Step 5: Analyze the data - take time and read through the lines, make a list of feedback, pertinent and absurd and brainstorm on them

Use sheets, piecharts, clumsy math functions. Anything that you have at your disposal so you can get good info.

Here is also the step when you will see if your questions and answers in the surveys are good. If they were not, some results will be nule.

Step 6 and last: Interpret the data and do not try to manipulate things in your own favor. Have a fight with yourself over the results.

Last but not least: Do not lead yourself in making rash decision just because an individual said something

If all or most said that a certain level or part of the game sucks, then you might have a problem. Or you have chosen the wrong audience.

Tip 1: If you are ashamed to show what you did, you are play-testing a bit too late. Play-test early and often.

Tip 2: The most ideal playtester is the one that likes your genre, your fantasy, he is a bit outgoing and he does not know you.

Tip 3: Ask the right questions. Think of what questions and what you want to find out 1000 times before doing it.

Tip 4: Listen to issues, not solutions. You care about them, you note them but, issues are the ones that matter.

Tip 5: What people often answer, is not exactly what they think. Persuade them into saying the truth, ask the same question multiple times

Tip 6: Always think that BIASES can ruin a playtest. Identify BIAS monsters and filter their responses

I am really glad! Thank you for your interest!

No reason not to. If you're secretive, you sign an NDA. If you think they are not efficient, there are a lot of examples to prove wrong.

Playtests are a small part of the bigger User Research subject. This assures validation before shipping, and even before development

If they refuse, after arguments were on the table - then something is wrong in their judgement, and you do not have a proper product manager

Validation of certain aspects is the bigger part of the iterative process. Validation is key to know if you are on the right track

What are your greatest fears and frustration about the GDD? Let me know your thoughts so I can focus on some aspects tomorrow 😇

For example, Confluence or Wikis, or for the more fancy like me InDesign with hyperlinks in between pages and PDF structuring

Also tiddlywiki.com - I use mostly Google Docs cause I can add navigation usability in docs and connect them with xls or slides

Tracking changes is important, from a point the GDD needs to be updated accordingly to the Backlog, when time is advantageous

Let's talk about what a Game Design Document is and what is not. Tricks, tips and secrets!

What is GDD? A game design document is the bible, the novel and the core of your project in each phase. The starting point for everything.

Do not confuse a GDD from a small mockup for a very specific UI element. GDD is the starting point and foundation.

A GDD will help everyone understand the project, its scope, its vision and most importantly the specifications of Gameplay and Mechanics

A GDD will help you not just in pre-prod or prod, it will greatly help in the post-mortem.

Why a GDD? It's the bible of confronting doubt and mistakes. The tool of fleshing out each bit of the game. And it's a team effort!

People should be able to comment and edit a GDD, and track these changes in between them.

Through a GDD you eliminate any kind of unclear goals and specifications and helps you elaborate each aspect of the game.

You eliminate any kind of unnecessary hype in the team, by having a realistic laid down scope of the game.

The interesting question now and the most difficult. HOW?I will explain my technique, each one has a different one. But, this one is mine.

After almost 8 years in the industry, I have put all the lessons together and I started splitting my GDDs in three main big chapters.

CHAPTER I: Concept and vision - Description, key features, theme and metaphor, market info, genre, cost, audience, scope, feasibility.

Chapter 1 needs to be as concise and short as it can be, but gives a clear vision about the gameplay, scope and plan of the game and project

CHAPTER II: Core Design and Gameplay Loops - Gameplay, mechanics, technicalities, variables, constants, functions...

...details on each step of the gameplay loops, menu structure, flow of the game, tutorials/learning sequences, monetization. ALL of the game

Chapter 2 is the most consistent and detailed part of the design document, gives an in-depth look to every mechanic

This section needs to be build to have general descriptions that can be understood by anyone, but also in-depth specifications for coders

CHAPTE III: Production Section - mock-ups, backlog, tasks, budget, technical specifications, QA and compliance, Editorial and Marketing...

...rendering specifications, art scope and direction, team ownership, responsabilties, schedule and planning on expanding the team, risks.

Chapter 3 represents every element that support a good production flow. This helps everyone understand the project from all aspects

This helps me a lot to make the project manager, the artists, anyone that is involved have a clear vision over the project

This makes people know everything from start, be synced and not ask inefficient questions between them like "How does that mechanic work?"

...weird questions when we are half-way in the production makes things really awkward in the team. Avoid that. Everyone needs to be involved

I am unable to share a template. I am sorry. It's unique for each gameplay, you'll need to figure out what you need for each Chapter 😉

Tips and Tricks Time - I will go ahead and try to give you some tips on how to pay attention to some mistakes and good practices for a GDD

Please use paragraphs, headings, tingle your spacing, in between paragraphs, letters, do not overkill a sentence, use visual hierarchies!

Use a proper readable Font - I recommend Candara for heading1, heading2 and Roboto for body. Color - always use a dark grey, not a black!

Not just in GDDs but also in presentations.