Graduate student in North Carolina
The professor started the class by discussing the assignments and recapping last class.
There are many different kinds of models that were discussed in this class, including activity models, cultural models, physical models, etc. The professor then asked, “Now what?” At this point, we have to have a meta discussion about how these models work together. We have to synthesize the models and come up with a way that they all fit together.
All models are wrong. Some models are useful.
To evaluate whether the stated maxim is true, the professor noted you have to perfom a “sanity check,” which questions whehter the design makes sense and is useful for all parties involved.
The professor made a distinction between UX, which is user design and UED, User Environment Design. The UED is intentded to model and analyze the flow of user interfaces and it includes UX, but it also looks at how the flow of the users’ work interacts with this system. User Environment Models use a formal modeling method that is intended to replicate this analysis.
There are several components of a UED that are important:
Focus area - The portion of the screen (or system) where the users’ attention is. This area has a specific purpose that the focus area must support. For example, a spreadsheet’s purpose is to enter and view data. The grid exists for us to enter information in a readable format. The functions of the focus area are designed to support the purpose. A spreadsheet’s functions can be sorting, giltering, calculating, etc.
Links - Work objects sometimes correspond to links, which move the user to other focus areas. They should support the natural flow of the task. Spreadsheet applications (most) require users to shift their focus in a print preview layout to define their printing areas.
Objects - Also important, but the professor went too fast and I couldn’t get it.
The professor summed up the UED concept:
Box linked to other boxes. All have descriptions.
In short, the UED provides a framework for examining your design.
The professor started the class by discussing entity-relationship (ER) models. These are used to design or reverse engineer relational databases. It was noted that ER morels are also useful analyzing the structure of information in other systems like flat files, spreadsheets, content management systems and other unknown settings.
The ER model represents the structure of information that is associated with (e.g., created by, obtained from some real-world event.) The event is the trigger.
Data elements, or attributes are individual pieces of information (city name, ID number).
An entity is a set or group of data elements that represent what the database “knows” about a real world thing.
Each attribute is defined with a corresponding data type, such as text, numbers, dates, currency, etc.
The professor started the class by discussing flowcharts and work flow modeling. Flow charts are the most common form of process modeling.
Similar to flow charts, but it includes emphasis on which actors (users or system components) do which actions, and the hand-offs between actors.
It was noted that UML is a thousand page specification and there are a plethora of different symbols that can be used. There are several different activity components that are concepts required for starting a model.
Swim lanes - Organizes actors by actor (person or system). Can be displayed vertically (read from top to bottom) or horizontally (read from left to right).
Initial state - Where the process starts. Indicated by a solid point or circle.
Final states - The activity final or the end of the activity is a point surrounded by a circle. A flow final is the end of a single path and is represented with a hollow point with an X in it. The professor noted that this indicates the end of the model, but not necessarily the end of the activity.
Action - A step in the process. This is represented by a box with rounded edges.
Transitions - Paths between two actions
Control flow - Indicates flow of control or responsibility or sequence of actions. Represented by an arrow pointing to different action boxes.
Object flow - Indicates passing an object or information artifact. This is represented by a larger box with straight edges.
Transition connectors - Diagram with lots of transitions can become complex. The connectors are essentially “goto” indicators.
Unlike many other process models, the activity model can include temporal aspects of the process. These are usually made to represent delay and are represented by an hourglass symbol on top of the control flow arrows.
Additionally, a flow can start with an hourglass symbol as a trigger to indicate the start of an activity.
Decision diamonds indicate decisions in the model. It is represented by one path in, at a diamond, with multiple paths out. The output paths are then labeled with guard conditions, meaning they are complete and mutually exclusive.
Merge diamonds indicate where two or more paths have the same result. It was important to note that convergence diamonds cannot be then used to output decisions.
A fork indicates multiple paths from an activity that must be followed simultaneously. A join or sync indicates when multiple paths must all be completed before the next activity can start.
The professor started the class by discussing the upcoming homework assignments due next week. The Information Gathering Plan for the team project is due on Tuesday (Oct. 4). The class today will be discussing artifacts and systems related to organize artifacts.
Artifacts are tangible things people create or use to help them get their work done … An artifact reveals the assumptions, concepts, strategy, and structure that guide the people who work with it … Artifacts can be bought … or created on the fly
This can include calendars, post it notes, paper, and even stone, electronic, fabric, etc. as long as the tool helps people get things done. The class also noted that radio or TV show recordings, text messages, tweets, etc. can all be considered artifacts.
The important characteristics include:
Artifacts are tangible
An artifact acts as a container of content - The professor noted that this definition implies a life-span longer than unrecorded speech.
An artifact is a form of external memory - It is a means of communicating and/or preserving information.
An artifact is associated with a work process - Work is defined broadly. It can include recreation, leisure, and other things we might not consider “work”.
A successful artifact supports the work process. An unsuccessful artifact interferes in some way. These can need additions, annotations, deletions or other modification. Causes include that it is confusing or in a format that is awkward.
When trying to define artifacts, we need to include…
Structure - Form, grouping, order, spacing, formality and other characteristics.
Intent - What is the purpose of the artifact is, who uses it, and how it fits into the work flow, and what its role in the information is.
Content - Information in/on the artifact
Life cycle - artifact source, destination(s), changes along the way
Relationships among these components
Artifacts are good sources of information about the current system, breakdown, task requirements, peoples’ job roles and responsibilities, etc. If possible before an interview, you can study the artifacts to prepare and get you ready to observe how they are used during the interview or as a prompt for other questions.
It is important to obtain the artifact at different points in its life cycle. From the initial creation, as it is in use (multiple users? steps in the work flow), when it is “finished” and how it travels from one step to another. It’s also important to observe the artifacts in formal and informal uses. For instance, a meeting agenda may also be used for a todo list. It’s important to note why this happens and what event triggers the change.
Artifacts help answer questions such as:
How well does the artifact fit with the workflow in which it is used? Is the usage obvious?
How well does the artifact fit with the information it contains? Is the information well organized and understandable?
How well does the artifact support its intents? Is the purpose clear? Is it trying to support several inconsistent intents?
The class began by discussing the upcoming homework. The professor noted that students should have begun dividing up current work among groups.
The professor then moved to discuss how work models can assist us understand work flows. They represent tasks, processes, workflows, actions, decisions, and more.
Some graphical models give functional decomposition and allow us to think critically about tasks and subtasks.
The endpoint will be individual steps that can be implemented in the system. In a way, it takes big concepts and allows you to break it down into actionable steps.
Functional decomposition illustrates the concept of leveled models. These are a representation of levels of specificity or detail and allows “zooming in and out” from seeing the big picture to see the specific details.
When designing work models, you must first represent the happy paths, a sequence of steps (user and system) that results in the desired outcome. Then, represent the unhappy paths, or sequences of steps that don’t work (breakdowns).
You can’t think of all the possible unhappy paths - focus on the ones you’ve observed or that are most frequent. These are the ones the system should handle and/or seek to prevent.
UML is a set of processes and models for system analysis and design. “Unified” because UML is the result of merging 3 earlier (and similar) approaches for object-oriented modeling. There are different “degrees” of UML use, including sketching alternatives, developing blueprints, and designs for program architecture and modeling. The professor noted that for this class, we will only discuss the sketch and blueprint uses.
The term “use case” is overused.
The professor noted that in some cases, it refers to a broad overview like a scenario and is similar to a business case to describe and justify the system development. In UML, there is a more specific definition that often takes into account lower-level issues. You can also graph use cases in diagrams or explain them in texts.
A use case models how users and the system interact, the boundary of the system, and the system sub-components and their interaction. At the model level, there can be a high-level overview and represent what has to occur without getting too granular.
There are many similarities between use cases and scenarios, but the key differences are that scenarios use star actors and has an invisible system, while use cases talk about system boundaries and sub-components, and can span many user roles.
The professor then broke the class up into groups to create a high-level model of an example situation about a weather information website.
The professor started the class by discussing models and modeling techniques. Importantly, models can include a representation for breakdowns, defined as “errors or failures, something that doesn’t work well as it should/could, or an annoyance that creates extra work. In systems analysis, our goal is to identify and eliminate/minimize these breakdown events.
Alluding back to our models overview from previous classes, the professor noted that there are three high-level categories or types of models:
Big picture models - Brainstorming, visioning, imagining
Work models - Processes, procedures, workflows, decisions
Content models - Representations, organizations, arrangements, presentations
Scenario-based design tries to manage the complexity of design problem solving by concretization. A scenario is a concrete story about use. (Carroll, 2000 p. 22)
The professor noted that scenarios give you the opportunity to take a large, complicated question (like staff processes in a hospital) and narrow it down to a specific thing. In itself, it’s not a complete way to understand a situation, but it can give you a good overview about what’s happening at a specific point.
A scenario was compared to a play script. It’s an intersecting, messy story that models real life. There are transitions, different perspectives, and different issues that arise in the overall narrative.
Scenarios also allow us to explore the consequences of design decisions. We can see job responsibilities, procedures, resources, timing, and understand the individual parts of the system and the system as a whole.
The professor noted that within the scenario discussion, we need to make sure we don’t forget to consider transitions, where most design failures happen (between actors, between tasks).
Important components to consider in scenarios:
Settings or environments
Agents or actors
May include major systems as actors, if desired
Actors often instances of a persona
Generally a star actor that is the primary focus
Goals and objectives
Sequence of actions or events
In a physics lab, there are several parts that can be modeled easily.
Physics lab equipment room
Item checkout for maintenance
Audit/check usage information
Sequences of actions
Personas can help bring users alive (Holtzblatt, p. 181)
A persona is a one-page textual description of a typical user … an amalgam of elements drawn from several users who share common job roles, demographics, and user need characteristics. (Holtzblatt, p. 182)
It was noted that in this definition, there is a prototypical construct of “students” or “professors” that we can list common principles that serve as classes of users. Again, this is a level of abstraction that, like scenarios, can help us understand large problems better. Personas can serve as agents or actors in one or more scenarios, linking the two. In the physics lab example, the lab manager and the instructor serve as the personas that we can use as stand-ins for real people later on.
When creating personas, it’s a good idea to use a small number of major players or actors that represent the most common or important users of or participants in your system. It’s also good to consider diversity to cover all major users that may be related to the problem or solution.
The process of building/constructing personas is relatively straightforward.
Draw on data from interviews and observations
Identify each persona’s goals, roles, and tasks
Write a persona definition
Use the persona in analysis and design
The professor then broke the class up into groups to discuss an example situation of a walk-in computer help desk at a university Student Union.
The professor started the class by again discussing the Project Description project due next class on Tuesday. Additionally, there will be a calendar of recommended progress. See the slides for this day for more information.
Previous to this class, we talked about different aspects of project. In today’s class, we’ll talk about the challenges with predicting and planning projects.
The professor noted that when it comes to projects, there are several maxims:
Planning = prediction
Time = Money
Time = Tasks + People + Resources
Project goals, process, resources, benchmarks, milestones
Situational awareness for project team, stakeholders
Progress, delays, barriers, risks
What is working, what isn’t working
Changing plans, resources, etc. to accommodate change
Proactive and reactive
The scope and goals of the project need to be set by setting reasonable expectations, avoiding project creep, and matching resources to scope.
The tasks also need to be defined. You need to figure out what needs to be done, decomposing larger tasks into smaller pieces and specific assignments, and by identifying task dependencies. These can be sequences (Task 1 must be completed before Task 2 can start) and parallels (Task 1 and 2 are independent and can be done simultaneously.
The schedule needs to be clear. The task duration and completion date need to be included with the milestones and deadlines. This also takes into account slack time and crunch time (critical path).
The people need to also be managed where you take into account needed skills, task assignments, working within other commitments, and preventing over or under utilization.
Other resources need to be managed, including rooms, equipment, training facilities, etc.
Risks also need to be managed and monitored. It’s crucial to identify these risks and communicate them with your stakeholders. Additionally, you need to identify champions.
Results need to be managed, namely establishing and clarifying deliverables. It’s important to establish and effectively meet the criteria set down in the initial planning phases. It’s also important to demonstrating a commitment to success.
Budgets need to be managed, including the direct and indirect costs, fixed costs (one-time costs, e.g. equipment purchasing or software licensing), and variable costs (vary in proportion to time or activity, e.g. cloud computing usage fees).
These categories are applicable to both project and operation budgets, including equipment, supplies, personnel, travel, system back up, etc. After we get these estimates, there needs to be a project justification for the question is it worth the expense? This is usually a monetary question, but also has qualities or intangibles that may be relevant (good will, reputation, staff retention) and takes into account actionable metrics (ROI, cost-benefit analysis and ratio of benefits to costs, and “bang for the buck”). Additionally, the question is it worth the effort? is an important question. If it does positively affect the organization, there may be underlying issues that aren’t taken into account (opportunity cost, offset work, etc.)
The professor then broke the class up into groups to discuss specific tasks, resources, people and create a schedule with milestones and deliverables for the project.
The professor started the class by reminding that there is an assignment due in one week on September 20th. Primarily, this seems like a labor intensive group work project.
The professor then moved to discuss contextual interviews, which were compared to the interviews that were taken last class where we asked our partners about the details of their commute. It was noted that in contextual interviews as framed by this class session, the question process is a bit more difficult.
For a basic framework, there are three parties: the interview, the interviewer, and the task at hand.
Contextual Inquiry seeks to provide rich detail about customers by taking team members into the field. Once there, apprenticeship suggests an attitude of inquiry and learning. (B&H, p. 46)
The professor noted that to have a successful contextual interview session, we have to see the user as the expert and the analyst or designers are the apprentices. “We’re here to just observe and learn how you do things.”
In some cases, however, it isn’t possible to observe directly. Sometimes safety, confidentiality, or physical space are limiters that make it difficult to get a first-hand experience. Examples include surgery, ambulance or rescue situations, battle, lawyer/client privilege interviews, etc. In situations like these, the best substitute includes interviewing immediately after the event when its fresh in someone’s mind, video tape the event with the user (perhaps with faces/words obscured), or increase the number of interviews. In these cases, you’re seeking saturation or the point where you’re not learning anything new. The professor also noted that in situations like this, an intimate relationship with a user can help you in the future to have greater access for other projects.
You have to be there to see it and understand it.
An immersing first-hand experience with real examples give you a better understanding of the situation and can contextualize what the user is talking about later on.
Artifacts, layout, and physical objects give you a better idea of how the work takes place and what is critical to the user’s work.
Pace of work, interruptions, and time pressures can be more directly observed and re-weighted depending on the situation.
Helps you grasp intangible or unspoken factors like work culture, personal difficulties, and more “sticky” things that need to be experienced to understand.
You and the user have to each have your own expertise and learn from each other.
You learn about the job, tasks, problems and breakdowns, and the culture and values.
The user learns about what you need to learn and how to contribute to the project in addition to what the possibilities for a new system can help improve their job.
You each view the job differently - Your goal is to understand the current system and design a better system. The user’s goal is to get the work done.
Collaboration helps you both to learn and to improve workflows.
You need to interpret what you have seen
Take individual facts, observations, and try to find patterns and relationships.
Ask questions. Suppose in the middle of a task, the user has to consult a colleague. Why? Clarifying or leading questions can be helpful in this situation and include “to check on how to do it? to ask permission? feedback? needed information? make plans for lunch?” and “why did this happen at this time in the task? where does this information come from? are there other needs?
Keep you and the user focused on the task at hand, but if you focus too much, you may not be open to really seeing and learning.
Don’t eliminate the possibility of learning something that is not directly related, but is important to understanding the problem or designing the news system.
Be comfortable with admitting ignorance and asking questions
Be aware of and beware of your assumptions
Surprise is a good thing! It can lead to more research directions or opportunities that can lead to better situations.
The professor noted that there are many questions and prep work that needs to go into the situation before interviewing people.
What do you need to learn? Setting goals helps, but surprises are inevitable.
Why is it important? Will it help you understand the problem, context, user needs? Will it help you design the new system?
Who can give you the information you need? It’s advised to start with a client contact, consider work roles and tasks, consult the organization’s hierarchy chart, and then schedule interviews with accessibility or ability to meet in mind.
Snowball effect. Use one interview to chain to another person to get information from another colleague that would normally just ignore your email.
Additionally, the question comes up, “How many people do you need to talk to? It really depends on your situation. If you observe similarities, you’ve reached saturation, a good place to be. Also you have to be mindful of additional perspectives or stakeholders that might need to be considered including the time that you or others have to spend on the interviews. The goal isn’t to get interviews, but to get information. If they run out of time or information for various reasons, it’s okay to stop.
Preparing in advance can help you better understand the problem definition, set clear interview goals, examine possible artifacts or documents to help add context to the current situation, and find our history or success of past projects, if possible.
Planning will help you capture what you learn in the interviews. Consider having two interviewers, one to ask questions, one to take notes, and both to observe. Also consider what types of notes or diagrams you will have in the interview session. Some can be distracting, while others are critical to the interview. Consider what types of sound or video recording can take place. This also comes with acquiring and explaining consent between the interviewees or clients. Along those same lines, photos that can be used later on can be of great benefit to your study, but need to have permission.
The conventional interview
Explain your purpose for your being there
Allow interviewee to express ideas or opinions at the start
The contextual interview itself
Summarize what you have learned, let the interviewee comment or correct your impressions
Describe what happens in the next steps of the project (follow up, additional interviews and interviewees, snowball)
There are several different types of questions that you can ask in the contextual interview session.
Describe the steps in the task
Show documents or artifacts used in the task
Location of original information and destination
What is a … - Specific clarifying questions.
What do you call this … ?
Are there other things like this?
What do you do with it? What do others do with it?
What do you dislike/like about this?
Asking about relationships between people, artifacts or processes, processes, definitions, information, and other interpretations can be very revealing and can help the interviewer get more information. In addition to open-ended questions, restating what the interviewee has previously said can lead to more information. Additionally, try to fit what you’ve heard into what you know (or think you know). For example, “So this thing is related to that thing because they both something…” This helps you clarify things in your own mind and allows an opportunity for the user or interviewee to correct assumptions that might not be accurate. The professor also noted that it’s okay to interrupt the user if they’re trailing on or if you don’t understand something they’re saying. It’s a huge waste of time to let them continue if you don’t understand what’s going on.
It’s important to look upstream, finding where the work comes from, what triggers or cues specific reactions. Also, downstream information is important to see where the work goes upon completion. Why and how things are done helps you understand side effects or reasons behind what they do.
Thank the interviewee, use at least an hour immediately after the interview to review, record, and write down additional questions. It’s important to record your gut feelings or impressions because they can be easily lost. Share what you know what your team members, ask additional questions to the interviewee, and plan next steps for follow-up interviews or other avenues of research.
Can talk to more people than an interview
Can hear how people react to what other people say
But, there’s a risk of group-think or self-censorship
Examining artifacts: documents, tools, objects
Examples of working systems in similar organizations
Broad way of measuring high level concepts
The professor noted these are generally rare because they don’t give you actionable or specific information that helps your research. Usually it requires follow-up.
The professor started the class by reminding the students that there is an upcoming assignment that will be due within the last two weeks.
The professor then gave a definition of contextual design and cited the textbook definition found on page 3.
There are several different types of expertise that are required to successfully analyze and manage an information system.
The professor then noted several things that may occur in an organization that can make it difficult to successfully implement projects.
The history of the organization and previous systems projects can sometimes make management or workers jaded about previous failures. They may also be deluded that past success means that the same plan will work in the future.
The organizational culture may prioritize innovation or tradition and the management could be hierarchical or flat structures or a combination, making it difficult to draw comparisons between organizations.
Stakeholder interests and concerns can collude your success by competing issues.
Available resources may limit, including time, money, staff, etc.
Nature and severity of the program can make it difficult to work on the issue. If a critical system must remain online consistently
The novelty of a problem or system could mean that the organization could have a bespoke system that makes it more difficult to troubleshoot because each situation is different and has the possibility of never having been faced before by anyone.
The professor noted that there are competing ideas about how users needs and opinions should be incorporated in to the design of the system. Swan’s article Making place for clutter… provides a basic overview of how to observe people working in their “clutter” and interviewed them afterwards. These interviews included questions such as, “Why did you do that?” and “What is your rationale for doing this?”
Interviews are some of the most important tools that researchers have when coming up with a user-centered design plan. These can be thought of as “richly detailed qualitative accounts” or “thick description” as they help researchers understand what they have observed and can help readers understand what the informant is trying to convey. It is noted that there should be an identification and narrowing down of what is important and relevant to the study. To do this, it requires non-judgmental observation from systems analysts.
After the interviews are taken, there are several steps that need to occur to analyze and generalize the information that you’ve received.
The professor then asked the class to define the term “clutter” found in the reading for this week. It was noted that it can be considered residue, or things that don’t seem to go anywhere or have any immediate or obvious purpose. There are some characteristics of physical clutter that can be thought of as similar to e-clutter that can be thought of as your Downloads folder. Items are downloaded, sometimes used only once, and then are never looked at again. Other “miscellaneous” folders that, in some cases, can be an embarrassment for users.
The class noted that e-clutter and physical clutter have some similarities, but they are markedly different in outcomes. For instance, physical clutter gives you a level of locational abstraction that e-clutter doesn’t allow. Additionally, e-clutter doesn’t have a built-in value on its surface without thumbnail or other signifying marker. You have to open it to know what it is. The class also noted that the nature of digital files allow you to stash a lot of stuff without thinking about it. When physical files pile up, it becomes a much bigger reminder because it can be a barrier.
The professor then broke the class up into groups to discuss symptoms and problems related to clutter that are in the workplace. The class noted that physical clutter in the workplace is often mixed with work-related material and personal documents. This mixture makes it sometimes more difficult to segregate and prioritize information that is needed in a pinch. Additionally, e-clutter is a huge issue in offices, particularly with Outlook, in that it can be very difficult to organize and keep track of messages coming in, particularly when working in teams or with a shared inbox. Other groups noted that text documents or excel spreadsheets get out of sync and often require a “librarian” or editor to piece together and merge the different files into a final master document. Other groups proposed that a move to centralized documents in the cloud with Google Drive could address these issues, but there are often institutional barriers (support, security, etc.) that make it impossible to move to something new.
The professor then split the students up into one-on-one partners to practice interviewing each other for a task in which they are experts. Example activities include work activities or commuting to campus. There should be two interviews, we should learn as much as possible about the task, and then switch to learn something about the other person.
After the exercise, the professor noted that the most effective interview questions ask the responder to clarify or expand on what they’ve said. There’s a narrative part, but then there’s a clarifying stage where the interviewer gets more specific information about the general overview. These follow up questions are critical to the success of the interview, particularly if the interviewer is unfamiliar with the topic.
The professor started the class by defining a few key terms.
Components are symbols or structures that represent objects or concepts in the real world (e.g. shapes, words, icons)
Features are characteristics of the components (e.g. represented by size, color)
Relationships occur among components (e.g. time space authority, sending/receiving and by using layout, lines etc.)
Assumptions are about the world being modeled. It’s important to note that these assumptions can be both accurate or inaccurate.
The professor noted 5 communication functions:
Conscripting is an act that involves enlisting participation and eliciting reactions and comments (e.g. prototype website: Tell us how you like the new look!)
Coordinating is expressing progress and the provisionality of solution states (e.g. Based on initial analysis, we have determined the breakdown is found in transition from proofreading to publication. Here is a flow-chart of the new process we propose)
Framing is establishing or reaffirming a common ground, typology, or constraint field (e.g. We have determined that the problem lies in the information used in decision making. This decision table details the breakdowns.)
Persuading is convincing a stakeholder, often a prospective client that the solution fulfills project requirements (e.g. Running this simulation model demonstrates how we avoid bottlenecks at high-traffic times)
Recording involves keeping a record of the solution state so that it can be used by others in the future (e.g. Models can document design decisions, templates for future development, or act as user documentation or training materials.)
The professor noted that to avoid errors in models, you can proofread models just like you can proofread writing.