http://lilianh.tumblr.com/

Chapter 10: Orchestration and Flow

Fri, 12 Apr 2013 20:37:00 -0400

Overview

After creating personas, we need to create scenarios to imagine the ideal user interactions. Then, we use those to define requirements, which will then define the fundamental interaction framework for the product.

Narrative is an important part of human history, and is essential for communicating ideas. Scenarios are used in design to describe how the persona(s) would use the product to achieve specific goals. Designers should define what the product will do before deciding how the product will do it. To define what the product is and what it should do (Requirement Definition), the following steps should be taken:

Create problem and vision statements
Brainstorm
Identify persona expectations
Construct context scenarios
Identify requirements

How It Applies

Having used personas and scenarios in IAT 333, I have found that it helps also by allowing you to put yourself in the user’s shoes in depth. It forces you to think about every detail because you need to plan out the scenario as opposed to just thinking about it in your mind.

Questions

Do you think having someone on the design team acting and playing the persona is more helpful than hiring someone new to act as the persona? Someone new could bring a fresh perspective, but they would also bring their own nuances and personalities into the mix.

Jakob Nielsen: Heuristic Evaluations

Mon, 04 Feb 2013 20:51:00 -0500

Overview

Create problem and vision statements
Brainstorm
Identify persona expectations
Construct context scenarios
Identify requirements

How It Applies

Questions

Do you think having someone on the design team acting and playing the persona is more helpful than hiring someone new to act as the persona? Someone new could bring a fresh perspective, but they would also bring their own nuances and personalities into the mix.

Chapter 7: Frameworks

Mon, 04 Feb 2013 20:50:00 -0500

Overview

The design framework defines the overall structure of the users’ experience. It includes the arrangement of elements, interactive behaviours, underlying principles, visual and form language used to express data, concepts, functionality, and brand identity.

Not focusing on the little things - pixel pushing, widget design, etc - and focusing on the big picture will ensure that we stay focused on the fundamentals: serving the personas’ goals and requirements.

Interaction Framework

Step 1: define the form factor and list the constraints. Define the basic posture and determine the input method(s) for the system.
Step 2: Define functional and data elements, which are the representations of functionality and data that are revealed to the user in the interface. Described in language of UI representations. Data elements are the basic units to be referred to and should fit with personas’ mental models.
Step 3: Determine functional groups and hierarchy.
Step 4: Sketch the interaction framework/interface. Remember to stay high-level and not focus on small details.
Step 5: Construct key path scenarios, which describes how the persona interacts with the product by storyboarding, for example.
Step 6: Check designs with validation scenarios - shift focus to less frequent or less important interactions.

Visual Design Framework

Step 1: Develop visual language studies - color, type, widget treatments, materials, etc
Step 2: Apply chosen visual style to screen archetype - step is usually performed close to the end of the interaction framework

Industrial Design Framework

Step 1: Collaborate with interaction designers about form factor and input methods. Form and behaviour must be designed in concert with each other.
Step 2: Develop rough prototypes.

Refinement phase = design translated into final, concrete form. Follows the same steps we used to develop the design framework except at a deep levels of detail. Should maintain a visual style guide. Don’t “lead the witness” by explaining things in a persuasive manner. Usability testing = to evaluate, not to create. User research = before ideation, usability testing following it.

How It Applies

Questions

Chapter 6: The Foundations of Design - Scenarios and Requirements

Sun, 27 Jan 2013 09:51:00 -0500

Overview

Create problem and vision statements
Brainstorm
Identify persona expectations
Construct context scenarios
Identify requirements

How It Applies

Questions

Do you think having someone on the design team acting and playing the persona is more helpful than hiring someone new to act as the persona? Someone new could bring a fresh perspective, but they would also bring their own nuances and personalities into the mix.

Chapter 5: Modeling Users - Personas and Goals

Sun, 27 Jan 2013 09:48:00 -0500

Overview

Personas are user models that represent complex ideas with a useful abstraction. They provide designers with a precise way of thinking and how users behave, think, and why they do the things they do. They are based on behaviours and motivations of real people observed, and are composite archetypes based on behavioural data gathered from the actual users encountered in ethnographic interviews.

Rather than designing a product that has a broad functionality, designers should design for specific types of individuals with specific needs.

Personas help solve a number of common problems. For example, the Elastic User. Since everyone on a design team has a conception of who the user is and what the user wants, this “user” becomes elastic, bending to fit the thoughts of everyone. Design choices are then rationalized since there isn’t a concrete definition. Other problems include self-referential design and edge cases. Personas should be driven by goals - tasks are only a means to an end. There are three types of goals (experience, end, and life) and these goals motivate usage patterns.

The design for each interface should be focused on a primary persona.

How It Applies

Having completed a couple of IAT classes using personas, I think that personas are very important to the design process. I have experienced how team members (including myself) can get off track, and having a “real” person as our primary user helps bring the focus back.

Questions

Do you thinking choosing one of the people who were observed and had the most average answers and using that person as the persona is the same as creating one?
Are there other ways to solve problems such as the elastic user?

Chapter 4: Understanding Users - Qualitative Research

Mon, 21 Jan 2013 03:39:00 -0500

Overview

Deep knowledge about humans can only be gathered through qualitative research, not quantitive research. Not only does it provide the potential users’ behaviours and attitudes, it can also provide credibility and authority to the design team and uniting them with a common understanding of the underlying issues.

Some of the types of qualitative research are

stakeholder interviews: important to find out the preliminary product vision and administrative decisions such as budgets
subject matter expert interviews: experts who have lots of experience in the field who can share knowledge
user and customer interviews: find out the goal in purchasing/using the product, frustrations with current solutions, etc
user observation/ethnographic field studies: observing a user firsthand while taking notes
literature review: research on what’s already out there, to learn the vocab, check new data against existing data
product/prototype and competitive audits: again, research whats already out there

Ethnographic interviews: combination of immersive observation and directed interview techniques

persona hypothesis: should be based on likely behaviour patterns and factors that differentiate these patterns, not just on demographics. Who uses these products? What are their needs and behaviours?
interviewing in multiple stages: begin with broad, open-ended questions and drill down to detailed questions. Afterwards, observe their patterns of use and ask close-ended questions to tie up loose ends in the data.

Basic methods of interviewing:

interview where the interaction happens
avoid fixed set of questions
goals first, tasks second
don’t make the user a designer
no technology discussion
let the user talk

Something Interesting

Usability testing vs user testing is actually quite different when you think about it. I have always called it user testing, and I realize now how completely opposite the two are. Simply calling it usability testing rather than user testing reminds the designer to always remember that it is their product that is being tested and not the user. I also think it makes sense to put it later in the design process so that several iterations will be available for the user to choose the most effective option.

How It Applies

This applies to my IAT 381 class. Currently we are looking at different Content Management Systems and seeing how well they work and what we like about them. This chapter helped me see myself on the other side - as a user testing the product, I should be focusing on my goals and how the tasks get me to the goal.

Questions

If the designers find that the preliminary product visions of the stakeholders are different than their own, should they try to convince the stakeholder to change his/her mind or should they try to change their own views?
After conducting all the interviews and reviewing the data, what do you do about the answers/behaviour that only a small amount of people came up with/exhibited? Should they be disregarded as an anomaly or should we assume that it is the answer/behaviour of a beginner or an expert?

Chapter 3: Beginners, Experts, and Intermediates

Mon, 21 Jan 2013 03:39:00 -0500

Overview

For every product, the skill levels of its users can be classified as beginners, intermediates, or experts. Generally, the majority of the users will fall in the intermediate range. There will always be some beginners and some experts, but the users in these ranges tend to come and go rapidly. Both beginners and experts tend to move towards the intermediate range over time, because beginners do not like to stay beginners and it takes commitment to remain an expert. Therefore, products should be optimized for the intermediate users.

Unfortunately, the intermediate users are often overlooked. Programmers, who must know every possible use case in order to write the code for it, tend to design overly complicated products with emphasis on every option possible. However, the sales, marketing, and management departments are often responsible to demonstrating and teaching the product to customers, reporters, investors, etc who are all beginners. This gives them a biased view of the types of people who will be using the product.

The goal is then to quickly get beginners into the intermediate stage, to avoid giving the intermediate users obstacles in their path to become experts, and to keep the perpetual intermediates happy.

Something Interesting

Cooper et al states that:

beginners need to be able to grasp the concepts and scope of the product quickly and the product must adequately reflect the user’s mental model of his tasks. Dialogue boxes which only appear the first time a user uses a product is recommended as long as it stays focused on scope and goals and avoids intermediate and expert issues.
experts have a “disproportionate influence” on intermediates and beginners. They want shortcuts on everything and will quickly memorize the nuances of the interface. Expert users always want to learn more and want to see new, powerful features.
intermediates have a set of tools they use often and are comfortable with it. They know that there are more advanced tools available and those who are motivated to learn more require reference materials such as online help.

I find it interesting that these generalizations apply not only to software. This could apply to other technology as well, such as a television or even a stove.

How It Applies

I think this is a very interesting theory that I will be applying to all my future designs. I’ve been taught to create personas, conduct interviews, come up with scenarios - but have never focused on how users of different levels will interact with the design. It might have been there subconsciously, but I think paying more attention to this problem is important.

Questions

Can you think of instances where this set of “rules” do not apply?
When you are developing a product, it is brand new and everyone who you conduct user tests with and interviews with will always be a new user. How can you ensure that you are catering to the intermediates when they don’t exist at this stage?

Chapter 2: Implementation and Mental Models

Mon, 14 Jan 2013 06:22:00 -0500

Overview

The implementation model is the way a system actually works, while a user’s mental model is how they think something works. It is based off of their interactions with the mechanism, but usually does not cover the actual inner mechanics. This is completely fine, as not understanding fully does not prevent the user from using the product. The represented model is the way that a designer chooses to represent the implementation model to the user. The designer’s goal is to make the represented model match the mental model of the user as closely as possible.

Something Interesting

I have always found the debate regarding representing the mechanical age in the digital world interesting. Personally, I prefer the minimalistic look. If I’m going to pay a lot of money for a new technology that promises me the world, I don’t want to see remnants of past anywhere near it. To me, it implies that whoever designed this product is still holding on to old ideas and have not been innovative enough. However, I can also understand why some may prefer the interface to look familiar. Habits are hard to break and completely relearning how to use a product can be something people are not willing to do.

How It Applies

I found the part about mathematical thinking applicable to my life at the moment. I have a little bit of experience with coding, mostly through required courses, but have been learning a new language (PHP) for a freelance project. I have found it difficult to switch between thinking like a coder and thinking like a designer, and have had to block out separate times to do each. It was difficult to multitask but I didn’t understand why until I read the part about the Boolean statements and how they were directly opposite of how human brains work. Since I’ve had to use Boolean statements for querying databases for this project, it immediately clicked as to why I couldn’t figure out a design problem in the middle of coding.

Questions

Are you a fan of skeuomorphism? Why or why not?

Chapter 1: Goal-Directed Design

Sat, 12 Jan 2013 05:56:00 -0500

Overview

It sounds simple - make products that will help people achieve their goals, and the product will be successful. In reality, products often fail because it is missing the human element. Digital products are no exception, often forcing users to change their way of working and thinking in order to complete a task. This is a result of ignorance about users, conflicting interests, and lack of a process. Proper design includes identifying user requirements and provides a detailed plan for the behaviour and appearance of products based on the goals of the users, needs of businesses, and the constraints of technology.

Something Interesting

One part I found really interesting was where it stated that digital products routinely made users feel stupid, forgot things, and just generally exhibited poor behaviour. It is something I completely agree with, yet it is not something that usually goes through my mind when I run into problems on my computer. I have grown so accustomed to the error messages that only have one option (“OK”) that I click it without a second thought, and find myself sometimes appreciating that it is telling me what the problem is (no matter how vague) instead of just shutting down the program without a warning. I have also changed my way of working for the programs I use, and have done so so often that it feels normal to adapt to my computer instead of making it adapt to me.

How It Applies

This chapter was definitely applicable to my life as a designer. It has made me question my relationships with the technology I use, and provides some strong ideas for anything I design in the future. Some of these ideas I have already had experience with, such as using personas.

Questions

Cooper lists one of the reasons that products are so bad is because of a lack of process. He compares designing to engineering and points out that engineers must follow “rigorous engineering methods that ensure the feasibility and quality of the technology.” Is this a fair comparison?
Humans adapt to our environments. What is the line between adapting too much to the technology we use and adapting too little? Should we expect technology to completely fit into our lives seamlessly?