Objects & Users
People constantly interact with things, and ensuring that these interactions are enjoyable, easy to understand, and physically possible is the task of Design.
Functional Design:
- Makes things technically possible
- Makes things interactive
- Makes things understandable
Human-centred Design: - Makes sure that the audience the product is for can properly use it
Principles of Interactions
Designers create experiences.
To define what experiences are think about an object you like or dislike. Which interaction with it makes you like it or not? This is an experience. People encounter many new objects every day and quickly learn how to use most of them. The reason why lies in the created experiences.
Examples (Controller):
- The feeling of moving the stick
- The location and push feedback of a button
- How well it fits into the hand
Affordances:
A chair allows one to sit on and carry it. Therefore it affords sitting and carrying. If a person is not tall enough to sit on it or not strong enough to carry it these affordances do not apply to this person.
Glass is transparent and therefore affords to look through it, but it is also solid and has, therefore, an anti-affordance for passing through it.
Affordances describe what actions are possible in relation to the user.
Some objects feature affordances that are not intended. Should they be removed?
Signifiers:
A drawer handle has the affordance to be grabbed and pulled. The signifier describes where the user should grab and what to do after grabbing.
Signifiers indicate how and where a user should interact with something.
Signifiers must be perceivable by the intended user or they seize to function.
Feedback:
Pressing the button for a traffic light will cause the light to switch after a period of time. To inform the user that the interaction was successful feedback needs to accrue directly after the interaction.
Feedback informs the user if an interaction has been completed and if it was successful or not.
Conceptual Models:
A computer does not really feature folders, but it becomes easier to understand how the concept of folders works by thinking of them as such.
Conceptual Models serve as a simplified version of how something works and are frequently used to quickly explain something or make it easier to remember.
These models don‘t need to describe something correctly in its function but in how it affects the user.
Mappings:
The buttons controlling a stove should line up with the panel location.
If mappings are set up correctly it should be clear which elements are affected Mappings describe the layout of controls and affected elements.
The mappings should correspond with the function of the device.
Natural mappings describe a state in which the mappings directly correlate with the physical space of the functions they relate to.
Principles of Gestalt
Describe how people visually group things together. This allows similar interactions or purposes to be grouped together.
Conventions
Some interactions become conventions if something has worked in a specific way for a long time and people are used to it. This type of behaviour becomes expected.
- These conventions can differ depending on the location or culture.
Example:
- X-Box and Nintendo controllers have their A/B and X/Y buttons reversed, but they still use the same indicators. PlayStation uses different indicators.
Thinking like a Designer
- Designers find the correct problem before searching for a solution
- Think about a given problem. What causes the issue? Can it be solved on a fundamental level?
- Designers consider multiple solutions before deciding on one
- Think about the effects a given solution has on the entire product. Does it cause new issues? Can it improve other elements of the product?
Finding the correct problem:
- Find potential symptoms
- Analyze why a symptom appears in a product
- How can the product be changed to resolve it
- Does the product still fulfil all the required/original affordances
Thinking like a User
Designers should always take some time to think about their product from the users’ perspective.
- Think about an object based on its first impression
- Start by guessing the intended function and how to interact with it
- See if the expected result happens when interacting with it
- See if you can find shortcuts to use the object faster/easier
User Testing
During the time a project is created more and more questions will come up. These questions can sometimes not be answered with existing principles either because they are very specific to the project, it’s hard to say which principle is correct for this situation or the team is not aware of the principle to rely on. This is where user testing comes into effect and will allow the team to get more hands-on feedback about which problems exist and what they look like in a practical environment.
As for the test itself, this will usually be a group of potential users getting access to a selected segment of your project. These users will simply interact with the product on their own terms and answer questions about what they are doing.
There are many different methods of testing all of them will give you different answers to different questions. As a Designer, you should be aware of at least 4 forms of testing.
A/B testing
A/B testing will either give two similar groups of users a different version of the product to figure out what exact effect this difference creates. Or tests the same product with two groups of users that are differentiated by a specific trade, to figure out how the product is perceived differently by different users.
Preparation:
A/B testing is designed to get an answer to a specific question so the first step is to figure out what the test should answer.
All users need to be asked for relevant trades to make sure the evaluation holds up.
Example trades could be: Experience with similar products, Time invested in similar/related products, age, gender, general hobbies, education, etc.
Since this is used to compare users the answer options should be offered by the test team which will usually result in yes/no statements or 1-X evaluations. Be aware that not all users have good self-evaluation skills, if something feels off it might be a good call to adjust the evaluation or remove this sample. Ideally, this is avoided by asking questions that have definitive answers like “how many hours do you play a week”.
An alternative and more consistent method will be for the test team to prepare a sheet with the trades and a group of questions to go with them so the test team can evaluate the users. These questions will be more grounded like “Have you played games similar to X” and then asking for specific actions done in these games. This will create a solid foundation to evaluate the user trades.
Now with a question in mind and a userbase with evaluated trades, it becomes possible to select the best section of the product to test and to create two versions to create a comparison.
Evaluation:
Similar to the preparation this test wants results that can be compared easily, because of this the evaluation wants to answer the same question for every user.
The best precision is delivered by having two evaluation forms for each user, one filled out by the user and one filled out by the test team while the user interacts with the product.
The sheet used by the test team will answer questions as yes/no statements or 1-X evaluations and has some space for general notes and notes for each question, these questions will answer precise questions to the initial test question. Keep in mind that it is possible that these evaluations might change during the test session, so there should be an easy way to change an answer quickly, from experience having a selection of 3-4 symbols that trump each other works really nicely so it’s possible to use the 1st symbol as default and if the decision wants to be overwritten the next symbol can be used to do so quickly without slowing down the test.
The sheet for the user should contain the same yes/no statements and 1-X evaluations that are on the test teams evaluation sheet but should also feature a few more general questions to muddle the purpose of the test. An option for general notes, desired features and expectations is also nice to also allow for some generic feedback to get more out of each test. Additional notes should never be considered as part of the test and are solely to inform the development team’s decisions.
To evaluate the sheets compare the average results of both groups but separate the test team and user evaluation. It is also recommended to weigh the value of each sheet based on the trades of the user, this can be done to get more precise results for the target audience, experienced/inexperienced users.
Each separate sheet can be used to further inform future actions for the product but the development team has to evaluate what this feedback means instead of just acting based on the result. It is not recommended to act based on a result if the reason for the result is not known, this requires further testing or evaluation by the development team.
Usability testing
During usability testing, a group of users will interact with a selected section of the product to figure out how well they understand and can execute the required actions of the product.
Preparation:
During the development of a project, all elements want to be in usability testing at some point, ideally multiple times until no larger issues persist in a given section.
The closer the tested section is to the final product the more valuable the results of the usability test will be, but at the same time this form of testing is most valuable to the development team early. Because of that, it is recommended to start usability testing as early as possible, but to always test with the most advanced section of the game until other sections become close to a version that could make it to the final product. Ideally, this form of testing happens frequently with smaller user numbers 4-7 users should be enough for one test.
Similar to A/B testing it is required to note relevant trades of each user to properly evaluate each user.
Evaluation:
Similar to A/B testing it is recommended to have a test sheet for the user and one for the test team. But the questions here will be more open.
For the test team, the sheet should mainly consist of notes for where users had issues with the tested section of the product.
For the user the test sheet should have a number of open-ended questions like: “Did you encounter difficulties with any sections of the game”; “How did you feel about X”, “How does X function”, “etc.”. An option for general notes, desired features and expectations is also nice to also allow for some generic feedback to get more out of each test. Additional notes should never be considered as part of the test and are solely to inform the development team’s decisions.
How these tests inform future development is for the development team to decide, they should not necessarily force action if it is deemed unnecessary. A generally useful approach is that each point of feedback should be explainable by the development team and this explanation should be the basis for future actions. If the development team can’t explain a point of feedback it is recommended, if at all possible, to wait for further usability tests before translating the feedback into an action.
Appeals testing
Appeals testing in which a larger group of users will get access to a section of the product to estimate how enjoyable the experience is.
Preparation:
This form of testing requires a large number of users, 50+ would be ideal.
The trades of each user should be tracked roughly mainly focusing on if they fall in the project’s target audience and experience level.
This test form will also require a longer section of the product as the test environment, ~15% of the product should be a good amount. For really large products a test environment that allows for ~4h worth of content should suffice. If this logic does not apply and the product focuses more on repeatable sessions the users should be able to have access to it for ~4h. If it is a really small project it might be necessary to make most of the project available to get usable results.
Evaluation:
All users should get an evaluation sheet on which they can simply score the project with numbers as in “8 out of 10”. Some additional questions like “What did you really enjoy”; “What did you dislike”; “What was surprising”. Will give a better framework for the score. If a more detailed result is required to evaluate what aspects of the product need to improve the scoring can be separated into high-level categories: “Gameplay”, “Combat”, “Character controls”, “Narrative”, and “Stability”, “etc.”. An option for general notes, desired features and expectations is also nice to also allow for some generic feedback to get more out of each test. Additional notes should never be considered as part of the test and are solely to inform the development team’s decisions.
Accessibility testing
Accessibility testing during which a group of users with a specific disability will interact with a selected section of the product to test how their limitations influence the experience. And to check if they can fully interact with the product.
Preparation:
This test method is very similar to usability testing the only real difference is that the user base should have a specific disability to test for. It is likely necessary to test for each type of disability separately to get a clear understanding of the issues they face when interacting with the project. It might also be necessary to test the entire project to make sure everything is accessible.
This allows for checking if it is still possible for them to interact with the product as needed.
Many projects will feature specific options to cater for people with disabilities so this method of testing will be used to check if these settings have the desired effect.
Evaluation:
These tests are evaluated in the same way usability tests are evaluated, with the small exception that in comparison to most tests recommendations for solutions are very welcome to create a broader understanding of the issues faced by each individual person.
Additional Reading
Introduction to Product Design:
Norman, Donald. 2013. The DESIGN of EVERYDAY THINGS
Gestalt Principles:
https://www.youtube.com/watch?v=RWJSC1HU32c
https://uxcam.com/blog/gestalt-principles/
