Models: Mental, Conceptual and Interaction

A mental model is the way a person understands the world around them. You have a mental model of wooden blocks and you have a mental model of your oven, it's just the way your mind understands the way that something works. Your understanding by no means has to be correct or aligned with the intended use; for example I have a charcoal BBQ that I burn firewood inside of in the autumn to use it as a space heater for my patio. My use of the BBQ isn't exactly aligned with the intended use, but my mental model of it has expanded beyond just grilling food.

A key part of solving a UX challenge is to define a mental model that is appropriate for what is being designed, mental models are created early, and evolve quickly they are by no means, written in stone and should grow as you get a fuller understanding of the problem domain.

Six consideration to keep in mind when planning/analyzing a mental model are:

• Appearance: the way the system appears it should be used.
• Familiarity: does the system use design axioms and established design patterns?
• Simplicity: the ease of use, can a new user figure it out through trial and error
• Recall: procedural knowledge, recognizable sequences vs declarative knowledge facts
• Flexibility: the ability to do things in any sequence.
• Feedback: does the system provided positive and negative feedback appropriately.

mental models can be represented by flows or user journeys, they need to communicate why the user is trying to use the system

Once a mental model is constructed or understood then that insight can be used to create a conceptual model. A conceptual model is the bridge between how the user thinks the system works and how it generally functions. for a conceptual model you can start thinking how you are going to facilitate the mental model. these can take the form of wire frames
Conceptual models should describe what the user is trying to do

When the conceptual model is established then it's time to start experimenting with interaction models; these are more defined representations of how our system should work, however these are experiments. They can prove to be successful or be failures, think of them as tests to see if your approach is valid, this is not an end product of a process but merely step in an iterative process.
these can take the form of prototypes.
and interaction models should demonstrate how the system is going to help the user accomplish what they want to do.

Design Rational

Design rational is the process of justifying a designers choice from their options; the euphemism "There's more than one way to skin a cat" holds very true for UX design. Oftentimes when solving a UX challenge the designer has numerous options, the trick is to pick the best one for this particular instance of this problem.

"Design rational is the articulation of various trade-offs between potential options to guide design towards the most optimal solution."

Design rational aims to understand the various options in terms of their various pros and cons and then justify the decision to pursue one particular design route over the alternatives. there are many pragmatic and theoretical approaches to selecting a design route, almost all of them are based on the articulation of design trade-offs and using those trade-offs to make a decision.

Questions, Options, and Criteria.
QOC is a methodology to facilitate systematic and principled decision making for design options. It's routed in the notion that

"A feature is represented by multiple options, which answer a particular question. Criteria help articulate the various tradeoffs between the options and guide the choice of which option to settle on."

Questions:

• Provide structure to the design space
• Help uncover and define design alternatives

Options:

• Are different potential solutions to the same question

Criteria

• The required and desired properties that a solution should satisfy 
• Differ in importance and generality 
• Help determine reasons for a decision

Criteria do not just come out of thin air, they are founded in requirements and often come from:

• UX research, the formative work that is done with target users
• Requirements gathering both functional and non functional
• Accessibility constraints: visually impaired, hands free for driving, etc 
• Usability: integration into daily routines, Privacy, social acceptability, etc
• Previous studies: historically identify what works, established paradigms  
• Behavioral theory: how do people act vs how they portray/believe they act
• Common sense.

where ever your criteria come from it's important to understand they are not arbitrary and are in fact rooted in a need, when a criteria is proposed ask why? if you can't come up with a good answer then you should rethink the criteria.

By listing all of the criteria required 

How Humans Perceive

There are five main senses that human beings use to take in information

Sight Sound Touch

Taste Smell

In graphical user interfaces we mostly leverage sight, in User experience we can also incorporate sound, and in some systems we can even leverage touch; as for taste and smell, well maybe in the future; however we are going to focus on sight since most UI information is conveyed visually. humans have a very narrow field of view, we most of what our brain perceives is peripheral vision, we can only really focus on about 5 degrees of information at a time.

This 5 degrees of vision is the reason we have to scan things before we identify what we are looking at, our brains do this automatically. When designing an interface we have to be aware that just because we put something on the interface doesn't' mean our users will ever look at it. studies have show that when users read a web page they follow an "F" pattern, that is the read the top line, maybe the second or third one, and they scan the left side of the page for information.

By being aware about the F pattern we now can identify where the best real estate on a page is to increase the odds of your user finding what you're trying to sow them.

Our human eyes are better at differentiating UI assets by their properties:

• Color: if something has a contrasting color our eye will almost certainly notice it
• Shape: not as stand out as a color change, but our eyes will catch objects that are of a different shape
• Clutter: is all the things distracting the user from finding what they're looking for, if there's too much clutter and we don't differentiate our search target from the clutter we have to manually search, scanning our UI the way you do a word search.
• Motion: if we add some sort of animation to our UI this will again draw our eye to our search target.

the Gestalt Principles are a set of principles that define patterns that humans see:

1. Proximity: objects or shapes that are close to one another appear to form groups. Even if the shapes, sizes, and objects are radically different, they will appear as a group if they are close together.
2. Similarity: we group things that look similar into categories, for example a group of triangles
3. Closure & Continuation: refers to the way that a dashed line is still perceived as a line even though it's not a continuation our mind sees it as one item. same with a dotted border.
4. Symmetry: we are far more likely to perceive symmetrical half's as part of a whole than two different objects overlapping each other.
5. Common area: things that are grouped inside of a border we them as being related.
6. Common fate: if visual elements are seen as moving in the same direction at the same rate (optical flow), our perception associates the movement as part of the same group

Take away

• we can use pop out, things like Color, shape, and motion to draw attention to things to make them pop-out from the other clutter.
• we can use the six Gestalt Principles to group things together
• and we can use the same gestalt principles to allow people to skip over sections to find what they're looking for

7 stages of action

In the book the design of everyday things, the author Donald A. Norman modals how people act when they are pursuing a goal. this modal has seven stages:

1. Forming a goal: decide on something you want to accomplish 
2. Forming the intention: decide if you want to pursue your goal
3. Selecting the action: pick the "best" thing to do to accomplish your goal
4. Executing the action: do the "best" thing you chose to do to accomplish your goal
5. Perceive the state of the world: take in the information of the result of the "best" thing you chose to do
6. Interpret the state of the world: use the information you gained to see how your "best" action changed the world
7. evaluate the world: decide if your action accomplished your goal, moved you closer to your goal, or further from your goal.

this is an iterative process that people follow to complete their minor goals to reach their major goal

if you look at the first three steps after forming the goal:

1. Form the intention
2. Select the action
3. Execute the action

they make up the Execution path, deciding to act, selecting the action and performing the action. Whereas the following three steps:

1. Perceive the result
2. Interpret the result
3. Evaluate the result

make up the Evaluation path, seeing what changed, interpreting it, deciding if the change moved the user closer to his or her goal.

the space between the user's goal and the execution path is referred to as "The gulf of Execution" the challenge for the user to map their goals on the possibilities in their environment, whereas on the other hand the user faces "The gulf of Evaluation" this occurs when the user tries to see what their action changed, interpret their change, and decide if their change moved them closer to their goal.

When designing systems we want to bridge these two gulfs, the gulf of execution and the gulf of evaluation. To bridge the Gulf of execution we want to make it clear and obvious for the user as to what they're suppose to do, and as for the gulf of evaluation we want to give them a clear indication via feedback that their action has been received and is moving them towards or away from their goal in order for the user to keep on their present course or pivot to move towards their goal.

Users need to be able to know what the system can do, how to do it.

The Gulf of execution: Users can figure out what they can do

The Gulf of evaluation: Users can see if they where successful 

Aids in discovery 

• Affordances: a feature of an object or environment that indicates the possibility of action, it'll communicate that something can be done intuitivly  
• Signifiers: an indication of what will occur and where it can occur. Signifiers are often required when you have many options but you need to differentiate them.
• Feedback: lets the user know that their input was recieved and what it did with that input
• Constraints: limit the number of options the user has, things the user can't do should be disabled or hidden. Limit the number of options making the selection easier.
• Conceptual Models: support future actions, they are paradigms that will clearly communicate to a user what their action will accomplish, they are supported by the previous aids.

a designers conceptual modal is how the system functions and can be used, however every system is clear and obvious to the designer, the user however can really only use their past experiences and the visual cues available to form their course of action to accomplish a goal

there are two more aids that can be leveraged for building a Cohesive Conceptual modal:

• Consistency: things should work the same way throughout the user experience
• Metaphor:  things should function the same way between different user experiences, that is if a paradigm has been defined for example 3 horizontal bars for a hamburger menu, that's exactuly what your experience should do

UX Design

"Most people make the mistake of thinking design is what it looks like. People think it’s this veneer – that the designers are handed this box and told, ‘Make it look good!’ That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works." – Steve Jobs

Design is not an afterthought, good design begins with the inception of the product or service and is in the forefront throughout the entire delivery process. The product or service is the direct result of the design, too often in the past products are built and then designed, a vernier thrown onto a product is not a design, it's a face-lift at best.

Design is not what it looks and feels like, design is how it works. A Design is a plan to arrange elements to fulfill a purpose, it describes on how a product or service works, design is solving a problem.

Design Process
To successfully design something we must

• Assess
• Identify & understand the problems we are solving
• what the user is doing what works what doesn't 
• Design
• Generate possible solutions to our problem
• Analyse the solutions and select the best one
• Build
• Low/Mid/High-fidelity prototypes

this is an iterative process we go through numerous times until we arrive at an iteration that solves our problems.

What makes UX Design special?
When designing User experiences we are focused on experiences and interactions with the system, these are time sensitive inputs with feedback that the user interacts with for the purpose of accomplishing whatever it is the user is trying to do, this person could be a novice, or seasoned user and our system must engage with both facilitating their tasks as effectively and pleasantly as possible.

UX Design	UX Research
Understand the problem	Study Users: Tasks, context
Generate Possible solutions	Sketch, storyboard, wireframes
Analyse & Select	Apply UX criteria
Embody solutions	Build prototype
assess:find new problems	Apply UX research methods user tests
Repeat!!!

UX Design works hand in hand with UX research we move between the two to try and come up with the best experience and interface that we can for the particular system we're designing.

Storyboards

A story board is basically a visual depiction of a scenario.

"A storyboard is a series of sketched frames that visually depict how and under what circumstances; environmental and emotional does a user engage with the solution being developed."

if story boards are just scenarios drawn out, then why make them? Storyboards provide a few important advantages over scenarios:

• Better visualization of environment, a picture is worth a thousand words
• Visualize physical constraints, size of space, setting
• Depict users motivation and emotion
• Visualize interactions between multiple users.

Elements of a Storyboard

• Zoom: how wide/narrow is the focus of the frame, on the device on the user, the environment
• POV: from what perspective is the frame depicted, 1st person or 3rd person?
• Detail: what is the frame trying to communicate, the interaction, the users mood, the situation, what's the frame's focus?
• Emotion: What emotion is the user expressing: Lonely, Guilty, Happy, Energized, Board,etc
• Setting: where is the action taking place, in a car, on transit, at home, the toilet 

When creating storyboards, there are a number of things that need to be thought out:

• How many frames should the storyboard be?
• Should it depict one interaction by one user? or many interactions by many users?
• how will time be represented, sequential interactions or ones that span a day or longer?
• how will the actor(s) be represented in the frames, POV? 3rd person?
• Should there be text? if so how much?

when making these decisions your audience should be taken into account, if you're just creating a storyboard to flush out your own ideas, then as long as it makes sense to you great. However storyboards are often used to convey your idea to clients or the team, in those cases you need to keep the message your trying to convey in mind and just ask yourself, does this communicate my message?

Scenarios

Scenarios are descriptions of how specific users are leveraging technology to solve a particular problem within in a defined context.

"Scenarios are short stories about specific users who are using technology designed to accomplish specific goals in a specific context."

Scenarios bring together the research results of user needs and ideas and how to solve those needs; they are used to address user needs with design ideas. Scenarios are usually one ore two paragraphs long and they describe a particular use case, they expose various characteristics about our user and under what circumstance that user would need the solution; the elements of a scenario are:

• Setting: the situation or state of the system/context of use in which the activity occurs
• Actor(s): person or people performing the action in the given scenario
• Objectives: what is the person or people trying to accomplish
• Actions: activities that are being done to accomplish the actors objectives
• Events: things that happen to the users while performing the actions in the scenario.

Scenarios should aim to answer the following questions directly or indirectly  

• What: what problem does the user need solved?
• Why: why can't your user solve their problem without your solution
• How: how is your solution going to facilitate your users solution.
• Where: under what circumstances would your user want to engage with your application
• When: at what point in their day would your user want to engage with your application

Scenarios are a process, they are open ended, easily revised stories that are up for discussion, once a scenario is created it can be revised numerous times by the team, it is a design artifact that can be shared with the client for feedback or to gain further insight, it's used as an input not output. Scenarios like personas and all other design artifacts are used to understand a problem and communicate that understanding to further investigate and collaborate on the solution.

there are multiple types of scenarios

• Problem scenarios: define the problem that is faced before and type of solution is proposed
• Goal scenarios: describe the the goal and any roadblocks between the user and what they're trying to accomplish
• Activity scenarios: briefly describe how the proposed solution is going to help the user with their problem.
• Task scenarios: are elaborate activity scenarios that describe with great detail the interaction between the user and the proposed solution. 
• Information scenarios: describe how the users view and interpenetrate the information presented to them
• Interaction scenarios: describe the physical actions a user must take when interacting with a solution and how the solution responds to the actions.

Good design is a pragmatic process, not all types of scenarios are going to be valuable every single time, the key is to focus efforts on value added artifacts. If there is no value added, if the artifact doesn't help the team understand or communicate the problem or solution then the opportunity cost is taking away from effort that can be spent on something more valuable. the catch however is it take a lot of experience to know which artifacts will be value added and under what circumstances, thus a try it before you buy it approach is recommended; that is start each type of scenario and mature it to such a point that you can either definitely see value or definitely see no value.

Scenarios are short stories that help the design team understand:

• What the users problem is?
• Why the user has the problem?
• How is the solution going to solve the problem?
• Where is the user going to use the solution?
• When are they going to use it?

Scenarios should also be quick; these aren't suppose to be master works, they are after all just a tool to help understand and design the solution, 15 to 30 minutes per scenario assuming that you understand the problem domain and have completed your research. Rough and fast is the idea, get your thoughts on paper, iterate and refine. The reason you don't want to put too much effort into scenarios or any design artifacts is because you don't want to become a victim of "Escalation of commitment"

Scenarios are an excellent artifact to build before getting into wire-frames, and prototypes, they are a sounding board to help designers understand how to best go about designing solutions to help users accomplish their goals. Scenarios facilitate the reflection of intended and unintended consequences of their designs to maximize the value added aspects and minimize the unwanted side effects.