1. Using Personas to Create User-centered Designs
Allison Bloodworth, Senior User Interaction Designer, Educational Technology Services, University of California - Berkeley
July 2, 2008

2. Agenda What is user-centered design? What are personas?
Gathering data about users
Creating personas
Using personas in the design & development process

3. What is user-centered design?
User-centered design is a product development methodology based on actual user needs, behaviors, abilities and perceptions.
User-centered design is used by UC Berkeley because it offers the most effective path to useful and usable products.
Personas put a human face on the amorphous “user” because they are based on actual user needs. They save time by focusing development toward real use cases and away from unlikely “edge” cases.

4. User-centered design at Berkeley
Focuses on understanding:
Who are the users?
What are their goals?
Goals drive a person’s actions
Tasks are things a person does in order to accomplish his goals
What are their pain points?
What are their motivations?
To drive system definition & design
The main emphasis on our process is to understand who our users are, what there goals are and what their current pain points are.
So, who are we building the system for? It’s likely not the designers, developers, testers, support folks or anyone else on the development team. I’ll got into a little more depth in minute about how we learn about our users.
We want user goals to drive our system definition…hence goal-directed design.
Goals help us think out of the box and truly figure out how we can make users lives easier with technology.
For instance, I have a daily goal of getting to the office.
My task used to be to drive in traffic to meet that goal. Now most the time I ride my bike to meet my goal. In the future, maybe I’ll be able to simply press a button to get the office.
So the goal stays the same but the tasks change with context, with technological capabilities, with innovation…
We also want to focus on understanding where users feel the most pain with their current processes? Can technology take on some of the burden? Rather than replicate exactly what they do now in the new system, we need to figure out how we can make things better for them.
All this is meant to help us design systems that truly make our users lives easier

5. Why focus on user goals vs. (current) tasks?
“The way people do things today is often merely the product of the obsolete systems and and organizations they are forced to interact with, and typically bear little resemblance to the way they would like to do things, or they way they would be most effective.”
About Face 3.0
Just putting existing processes on-line often is not enough
Improving processes is often the best way help users achieve their goals
Business process analysis is part of a user-centered design process

6. User-centered design at Berkeley
User Research
Modeling
Requirements Definition
UI Framework Definition
UI Design
Development Support
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

7. User-centered design at Berkeley
This is a work in progress… but this is the process we are moving toward at Berkeley.
Talk through diagram…
Roles
Phases in the middle
Formal communication on the left
Examples of specific activities and deliverables that can be part of a phase on the right
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

8. User-centered design at Berkeley
Not a black and white process. The specifics of what we do for each phase is dependent on what kind of a project it is, new development or re-design of an existing system for instance…and what we already know in the specific domain.
I’ll go into a little more detail about each of these phases next.
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

9. User Research Ethnography and empathic research
Observation & interviews
Study users in their context
Centered on users’ goals and activities
Look for patterns
“I will briefly talk about these phases of Berkeley’s user-centered design process. Then throughout the rest of the presentation, you’ll be able to use the guide at the bottom of the slide to see what phase I’m talking about.”
We use ethnography and empathic research to flesh out who the users are and what they really do.
Users are not good at telling us what they do. They leave out things that seem unimportant but may be very important in getting their work done. And they’re not designers. In most cases they don’t understand the technical capabilities and constraints or how changing the system in some small way may affect the system as whole. A classic kind of example is a user may think they prefer pink text but not understand how that will affect their ability to see important information on the screen.
Context is important! To really understand what users do we need to watch them where the work normally happens.
It’s amazing how much information can be gained through the artifacts users have hanging around their work environment. If they post-it notes reminding them how to do a process we want to understand that. Maybe we can make the process more intuitive or let the system take care or tedious tasks. We can also learn about what’s important to users by the things they have sitting on their desk.
As I’ve mentioned, although we need to understand users’ current activities and work flows, we try to get down to the root of why they are doing it…their ultimate goal. We find that most times this requires asking “why” several times to get the “real” goals. PUT IN REAL EXAMPLE
And lastly we want to focus on patterns. We don’t want to build in idiosyncratic behaviors. We want to build a system that meets 80% of the needs. Once that’s accomplished, then we can build in those other 20% of cases in a way that doesn’t get in the way of the most common uses.
This is where modeling what we learned becomes useful.
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

10. Modeling Make sense of research findings Personas Mental models
Use cases - current or future processes
Use case frequency matrix
Activity diagrams - more complex processes
Artifact models
Helps gain consensus early on…before any design happens
Provides shared language & vision
Mental models: represent the way users think about a domain, as well as how well your system supports their needs.
Now that we all this information about users, what to do we with it?
Modeling what we learned about users helps us make sense of what we heard. We pull out patterns to create archetypical users, personas, we’ll design for. Personas help us make sure we aren’t building systems for ourselves or for a user’s idiosyncratic needs or behaviors.
We may also create other models like activity diagrams or communication models that help us understand how work really gets done.
Activity diagrams are like work flows except they include things that may happen outside the system but affect system use.
Besides being great design tools, the models can then be used to share research findings with the rest of the team. They help us gain consensus on who we are designing for and what activities we want to help them with before we ever start drawing screens.
So we want to have an all team check-in here to get everyone on the same page early.
They help ensure that the entire team has a shared vision and language throughout the design and development process.
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

11. Persona: Michael the Moderately Seasoned Professional
Source: Todd Warfel "Data Driven Personas”:
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

12. Requirements Definition
Refined based on:
User needs
Business goals
Customer needs
Context Scenarios
New processes, context of use
How users complete an activity
We typically start a project out with high level requirements in mind. For instance, we may go into a project knowing we want to allow users to utilize categories and weighting in their grading. A requirement near and dear to many in the community.
The requirements definition phase is when we further refine what users need. We get into specific goals, activities contexts and needs.
We also need to keep any mind in particular business and customer needs that should built into the system.
Do people understand the difference between users and customers? A user is the person using the system to get work done. Unless we are building consumer products, the customer, or person making “buying” decisions is usually not the user.
We write scenarios that describe imagined future use based on what we learned in our research. At this stage, this is a story about how users complete an activity. We don’t get into the specifics of how they will use our system in the activity until the next phase. This helps understand how factors outside the system will affect their work and keeps us from designing behaviors around design elements rather than designing the elements for needed use.
Scenarios can be another consensus building tool for the entire development team.
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

13. Scenarios A design technique used to envision future use of a system
Focusing on how users can achieve their goals
Helps designers & developers understand how system will really be used
A story about a particular persona interacting with the system
May be based on a use case, or a set of use cases
Can be used for usability testing
Scenarios become progressively more detailed
“Now I’m going to make a brief aside about a model, which I will mention again later, that is often used in conjunction with personas: scenarios.”
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

14. Types of Scenarios Context Scenarios Key path scenarios
High-level, no interaction details
Focus is on how the user can achieve her goals
Part of Requirements Definition phase
Key path scenarios
Incorporate functional and data needs into the scenarios
Part of the next phase: UI Framework Definition phase
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

15. Example Scenarios Context Scenario Key Path Scenario
Lisa is in lecture and realizes she’s confused when the instructor starts talking about mitosis. She takes note of the time.
Later that day she opens up her bSpace course site and goes directly to the webcast for that day and reviews the portions of lecture via the webcast she needed clarification on.
Key Path Scenario
Later that day she opens up her bSpace course site clicks on the “Most Recent Webcast” link. bSpace switches to the “Use Webcast” View and the webcast for the day plays.
Lisa looks at her notes to see the time she noted earlier, and enters it into the “Lecture Time” field and presses “Enter.” The lecture jumps forward to the point where the instructor was talking about mitosis.

16. UI Framework Definition
High level design
What pages do we have?
What panes need to exist within the pages and how do they work together?
What design elements are included in each page, pane, etc.?
Should be a holistic view of the design, not too detailed
Key path scenarios
Allows for iterating on the details
Start talking about technical feasibility
The UI Framework Definition is when we start creating the conceptual design. So using our persona’s goals, mental models and the scenarios we created we start defining how users can complete activities in our new system.
This is still at a high level. We are focusing on creating a holistic design that has pages, panes and elements that are consistent make sense together in our application.
In an agile world, this is where we can start breaking the system into chunks for iterative development. So we may choose a page or pane to start designing in detail.
This is also a good place to begin working with the developers on technical feasibility of the our ideas.
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

17. UI design
“Design is the conscious and intuitive effort to impose meaningful order”
Interaction design AND visual design
How does it behave?
What does it look like?
How does it make users feel?
Wireframes, mock-ups, and/or prototypes
And 5 stages later, we get to design. This is what many people think of when they think about design. In this phase we create wire frames detailing the specifics of the system. We define specific behaviors, and design elements that enable users to meet their goals.
As I mentioned earlier, at Berkeley, we are trying to be more agile and develop in iterations so our goal is create these wireframes in chunks rather than design the entire system before handing it off to developers.
The development team should be familiar with the conceptual designs we created so they can see how it all fits together and of course check for technical feasibility as I mentioned earlier.
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

18. Development Support Constant communication
No throwing it over the wall
Continuous iterations as we learn more from development
And finally, design doesn’t stop when the wireframes are complete. This is where communication between the designers and developers gets intensive. We find that there is never time for specifications to be written before development starts rather it gets defined through conversation. Specs can still be useful to document what we’ve agreed and capture behaviors for future work.
Additionally, as you’ve probably all experienced, we are continuously learning about what is possible and where previous decision no longer make sense. If we run into technical constraints than as a team we start looking for different ways to accomplish the same intent.
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

19. What are personas? Basic definition User models
“A persona is a user archetype you can use to help guide decisions about product features, navigation, interactions, and even visual design.” - Kim Goodwin, Cooper
User models
Models can consolidate complex information into an (easy to remember) abstraction
Remembering & making sense of all the raw data would be impossible without them
single data points don’t mean much, but patterns do
Models are “powerful tools for representing complex structures and relationships for the purpose of better understanding, discussing, or visualizing them.” - About Face 3.0
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

20. Persona: Sarah Windsor, Overwhelmed Faculty
From:
Sara & the other Sakai personas come from the course management research.
Search for Sarah Windsor on either the Fluid wiki or Sakai confluence to find the other personas.
Source: Sakai
From:
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

21. Persona do’s and don’ts
Should:
be based on user research
be based primarily on qualitative research
be focused on users’ goals
be based on common behavior patterns
be specific to your design context or problem
come to life, and seem like real people
Should not:
be focused on stereotypes or generalizations
be an ‘average’ of observed behavior patterns
be based only on user roles
be based only on information gathered from subject matter experts, as they cannot completely represent end users
*Users* are people who use the tool to accomplish something, and are not necessarily the buyer
*Goals* drive a person’s actions, tasks are the things a person does to achieve their goals
Goals remain stable, but tasks change as technology changes
our goal as designers is to help our users achieve their goals, feel competent, and usually to also minimize work
By focusing on *common behavior patterns*, just a few personas are able to represent the needs of many
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

22. Why use personas? Focus Empathy Gaining consensus
Avoiding the elastic user
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

23. Why use personas?
Focus
Designing for too many different types of users makes a product too complex to truly satisfy any of them
Pleasing some users often conflicts with pleasing others--must have a way to make choices
Helps prevent focusing the design on:
edge cases
averages
- car example: SUV vs. sedan vs. sportscar
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

24. Why use personas? Empathy
People are wired to be attuned to other people
Helps put yourself in the users’ shoes
Helps avoid self-referential design
Facilitates the use of role playing to:
make design decisions
evaluate designs
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

25. Why use personas? Gaining consensus
Give the team a shared understanding (early on!) of who they users are and what they need
Without personas, the team may be disagreeing about who the users are, rather than actual design decisions, without even knowing it
Gives the team a tool to reason through design decisions
- story: without personas, it was hard to decide whether to optimize reading (students re-loading pages constantly, looking for grades) or writing (lots of TAs entering grades at once) to the database for the Gradebook, as people remembered anecdotes from user research (e.g. a student hitting the db over and over trying to get their grades), but it was hard to tell whether they were edge cases or not. This is where the 80% rule (optimize the design for 80% of the users) comes in.
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

26. Why use personas? Avoiding the elastic user
If the users haven’t been clearly defined, they may stretch to fit the needs of the product team
“Our students are very tech-savvy, and will certainly be able to figure that out.”
“Students just won’t be able to understand how to do this. We need to create a wizard.”
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

27. Types of personas Design Personas Other types of Personas
User Personas (most common)
Customer/Buyer Personas
Served Personas
Negative Personas
Provisional Personas
Other types of Personas
Marketing Personas
Strategy Personas
Organization Personas
*Provisional personas:* important document the data used and any assumptions you’ve made, make it clear they are provisional, use sketches of the persona instead of photos
*Marketing personas*: help with product definition, and can help with the persona hypothesis
*Organization personas*: represent places where users work
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

28. Personas usually contain…
Goals
Attitudes (related to your context)
Behaviors & Tasks (in your context)
Photo
Name
Tagline
Demographic info
Skill level
Environment
goals provide context and structure for tasks
Other things to potentially include: education, job description and personal details such as education, marital status, and favorite sport
Photo resources: Morguefile.com, istockphoto.com, flickr creative commons licensed photos
Scenarios
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

29. Types of personas Primary persona Secondary, tertiary, etc. personas
A persona whose needs must be satisfied
Multiple primary personas require separate interfaces
Secondary, tertiary, etc. personas
Personas whose needs should be considered after those of the primary persona(s)
A persona is made secondary because their needs can be mostly met if the design is focused on the primary persona
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

30. Primary Persona: Ernest the Engaged Employee
“Work is important, but not my whole life.”
Personal Information
Profession: Data Architect
Age: 43
Background: Originally from upstate New York
Education: BS in Library Science from Columbia. Is continuing his education informally, by sitting in on classes at UC Berkeley’s School of Information whenever he can. Attends industry conferences about once a year.
UCB Background: “Fell” into a technical position at UC Berkeley 8 years ago after working in libraries.
Home Life: Has been married for 15 years and has two children, ages 6 and 13. Their family has a pet Cockatoo. He is interesting in volunteering some time at his 6-year-old’s Montessori School in Berkeley.
Hobbies: Photography (learning Photoshop)
Personality: Efficient, detail-oriented, dedicated. Enjoys meeting new people and learning about them.
User Goals
To be as efficient as possible at work so he can spend as much quality time with his family as possible
To make more money
To continue to learn
To improve his photography & perhaps make it more of a business
Pain Points
After the IST re-org, some processes have been unclear, and he’s often had to hunt around for the right person to get things done.
Too many passwords to remember
Too many collaborative tools being used in organization
Information he needs is all over the place, not organized efficiently
Site Objectives
Help Ernest find the information he needs quickly & easily
Clarify the IST/OCIO information available instead of adding just another site to the confusion
Help Ernest learn about and connect with the IST/OCIO community
Example: IST Staff website
Ernest the Engaged Employee - primary
Susie the Super Supervisor - secondary
Newton the New Employee - secondary
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

31. Sakai Persona Map
Use a bullseye model to visualize the different personas & their relationship to each other
From:
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

32. Methods used for gathering information for personas
User observation
Contextual inquiries
Interviews
Focus groups
Diary studies
Existing data
Existing knowledge
*Focus groups*: beware groupthink, self-report and inability to really understand user behavior
*Existing data*: website or application statistics (e.g. pages visited, search terms), market research data, market segmentation models, data gathered from literature reviews
*Existing knowledge*: interviews with stakeholders, subject matter experts
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

33. How are personas created?
Persona hypothesis
User research
Identify behavioral variables/attributes
Persona scales
Choose personas
Write personas
Communicate personas
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

34. Persona hypothesis
A starting point to help determine what types of users to research
Created before talking to end users
Based on information gathered from stakeholders, SME’s, your personal knowledge, and review of existing literature
Hypothesized behavior patterns
Should not be based purely on demographics
Differentiate users based on needs and behaviors
More user types can be added later if research points to other types
Often map to roles in a non-consumer domain (e.g. education)
Can be just a rough outline/list of user goals & behavior patterns you expect to see
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

35. Fluid CM research: User behavior/characteristic matrices
User types (Roles)
Application (CMS) use
Class structure
Group size
Technical level
Country/region
Type of institution
From:
This was our version of the persona hypothesis
User characteristics, attributes and behaviors to keep in mind when choosing users to talk to
e.g. behavior patterns such as how much is the LMS used in class, how much group work is done in class, pedagogical style (e.g. constructivist)
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

36. User research Interview & observe users in the context of their work
Use focus structure document to guide each user visit
Take detailed notes & photos
Capture interesting quotes
Use symbols in notes to organize info
Process ‘raw’ notes into a more categorized & synthesized format
Create summaries of notes
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

37. Raw notes
Works both at home and in her (very organized) office; carries her PC back and forth
Seminar: posts multiple discussion questions each week, has students respond to 1 each week. Part of participation grade which is 25% of their total grade.
- Would like students to have a one stop shop where they can get all info for her class: website, bSpace, Library Resources
- Throughout the semester she puts all her grades in Excel; she has mostly quizzes and exams, and only has a few assignments
Wants to be able to save copies of files having to do with students on her local drive
Helpful info if students ask for recommendations later
- She’s usually only a week ahead of the class in her preparation, which may change in the future when she’s taught the class more
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

38. Categorized Notes - Content Management
Typical/Good/Bad day
Course Details
Schedule/Organization
General CMS/LMS use & activities
Types of course materials
Communication
Content Reuse
Photos
Interview/Observation Setup
Persona Info (personal details)
Context of work
Teaching style/format
Computer/Technology use
Use cases/Activities
Pain points/Opportunities/Time wasters
User goals
These categories often map to your focus structure document
Works both at home and in her (very organized) office; carries her PC back and forth - Context of work
Would like students to have a one stop shop where they can get all info for her class: website, bSpace, Library Resources - pain point
Throughout the semester she puts all her grades in Excel; she has mostly quizzes and exams, and only has a few assignments - teaching style format
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

39. Identify variables
Personas should be based on observed behavior patterns
Identify the behavioral variables which differentiate your interviewees
Two by two comparison - UIE.com method
Read two randomly chosen summaries
List attributes that make interviewees similar & different
Replace one of the summaries with another randomly chosen one
Repeat until all summaries are read
Choose endpoints of scales
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

40. Persona scales Distinctions Roles Support running class
Timing of posting materials
Primary type of communication
Number of computers
Overall goal
change the field
teach students
get published
Previous LMS use
Years teaching
Years at current institution
Large, small or both classes
Discipline
Create scales for each of your behavioral variables and plot your interviewees on the scales.
Determine which users are similar by looking for behavioral patterns
You may discover that not all your variables give you valuable information, and some may be thrown out
From:
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

41. Choose personas
Determine list of potential personas based on common behavioral patterns
Sanity check
Do they make sense? Do they reflect what we’ve seen? Are there too many to be useful? Will they help us make design decisions?
Finalize initial persona list
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

42. Write personas Draft persona characteristics & goals for each persona
If possible, all info should come from actual user research (your notes)
All persona information should be relevant to your design context
Check persona set
Anything missing?
Any redundant personas?
Write the persona descriptions
Some bulleted lists, some narrative
You may have multiple formats depending on your team’s needs
A few personal details OK
Try to relate them to your design
Add them last
Choose primary, secondary, etc. persona(s)
Too many personal details can be distracting
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

43. Fluid Content Management Personas
Instructor Personas
Ahmad Yousef
(Faculty - Tenure-track History)
George McFadden
(Online Instructor - Journalism)
Ahmad Yousef
(Faculty - Tenure-track History)
George McFadden
(Online Instructor - Journalism)
Henry Sibley
(Longtime Faculty - Chemistry)
Catalina De Silva
(Faculty - GSI Manager in Spanish)
Sergio Rossi (Graduate Teaching Assistant - Urban Affairs & Planning)
Stacey Pearson (Graduate Teaching Assistant - Biochemistry)
Robin McCoy
(Faculty - Business School)
From:
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

44. Fluid Content Management Personas
Student Personas
Christy Gonzola (Undergraduate Student - Molecular & Cell Biology)
Ashley Myles (Undergraduate Student - Acheology)
Shaina Wiseman (Graduate Student - Land Development)
Andy Wright (Graduate Student - Information Studies)
From:
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

45. Fluid Content Management Personas
Instructional Support Staff Personas
Michael Demsky
(Departmental Support - Biology)
Anita Stalmach (Departmental Pedagogy Support - Instructional Designer)
From:
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

46. Stacy Pearson - TA Trainer/ Graduate Teaching Assistant
Characteristics
Lives in the suburbs, about 40 minutes outside the city by car, with her parents
Is a 3rd year PhD student with a specialty in Biochemistry, and has been TAing since 2004
Comes in everyday at 6:30am and spends all day on campus until around 5pm. She does most of the work on campus, in the lab and in her office, and none at home.
She coordinates the TA training program where she trains TAs through the office of Teaching Advancement. With other coordinators, she organizes workshops for TAs on how to teach students.
She uses Blackboard as a TA but is not a huge fan. She only login when she gets an notification with important announcements.
She uses a highly paper-based file organization system. She prints out course materials and organizes them into binders in chronological order.
If she needs to take files home, she s her files to her Yahoo account.
Goals
Get her PhD
Become a better teacher
"I'm all manual. Papers, folders, and binders.”
Main Points:
Uses physical folders, binders, and drawers to organize her reading materials
Teaches TAs how to teach students
Concerned about Mac-PC compatibility when transferring files
Frustrated that she doesn't have access to the LMS her students are using
ADDITIONAL INFO IN THIS PERSONA
Did her undergrad at the University of Waterloo, and 3 years at the University of Toronto
* Her home computer is a PC, which she only uses for checking s. She mostly uses her iMac in her lab and occasionally uses the iBook in her office that her department gave her a few years ago. Even though it is a laptop, she finds it heavy to carry around and just leaves it in the office. She is on her Mac machines, and the other TAs she works with are not, so she is always concerned about compatibility when they share documents such as PowerPoint slides, Excel sheets with grades, and Word documents.
Supports two departments, Biochemistry and Dentistry. For the lab course for the Dentistry department, she writes Quizzes and marks them. Quizzes are specific to each experiment, so every TA has to prepare his/her own questions. She also prepares forms for students to fill in lab results and the lab itself. Her students print out the lab instructions from their LMS, but she doesn't have access to it. This causes problem sometimes of her walking into the lab with different lab instructions than the students. She thinks it would help if she could log into the students' LMS.
She also marks the presentations students give as part of their lab course
She coordinates the TA training program where she trains TAs through the office of Teaching Advancement. With other coordinators, she organizes workshops for TAs on how to teach students. The latest workshop was on Problem Based Learning and Self-Directed Learning. For this program, she sometimes gives written sessions on Blackboard.
The coordinators of the TA training program go to all departments every September to find out what they want their TAs to be trained in. They customize the training slides for each department. The training workshops varies in sizes, from 6 to 100, but typically they get about 40 TAs in a class. The program covers materials from the TA Handbook, how to grade
* She uses a highly paper-based file organization system. She prints out course materials and organizes them into binders in chronological order. What normally happens is she'll print out the lecture notes for the upcoming lecture, carry it around in her "Today" folder, because it's lighter that way, take notes in them, then put them in the binder after the lecture. If she hasn't had time to read the notes, she'll put the notes in the binder without punching holes, so they stick out. This is her flagging system, reminding herself to read it later.
* She also digitally organizes her files into folders on the desktop. She has a folder for the "old crap," where she dumps all the old folders and files. When she needs to find an old file, she uses the OSX finder "Search" capability.
* She tends to use to communicate with students. She uses her Yahoo account for this, because it's easier to organize contacts and do mass mailings there. She groups students by section and year, and sends s out to the group and cc's her boss. Yahoo lets you create groups of contact, so when you send, you can select the group rather than typing up each student's . In her LMS, she can send an to multiple people, but she needs to copy and paste all of those addresses.
* Each of the departments she works with has their own LMS. As a TA supporting multiple departments, she finds this very cumbersome and would like one integrated LMS.
From:
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

47. Communicate personas Introductory workshop
Posting one or two page summaries in work areas
Laminated sheet containing short summaries of all personas
Persona deck of cards
Have everyone put a persona on their door to represent who they identify with
Set up a work area for a persona
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support

48. Persona Resources Books About Face 3.0 The Persona Lifecycle
Practical Personas: The User Is Always Right
Presentations
UIE's Building Robust Personas in 30 Days or Less:
"data driven design research personas:"
"The user is always right: Making Personas Work for Your Site:"
Articles
Building a data-backed persona:
Personas vs. User Descriptions:

49. Questions? Let’s talk during the conference!
Check out the Fluid UX Toolkit:
Contact info:
Allison Bloodworth, University of California, Berkeley:

50. Persona Example: Matthew Johnson, USDA Senior Manager
A small portion of a much larger persona
Source: U.S. Department of Agriculture's (USDA) Economic Research Service (ERS),
 User Research  Modeling  Requirements Definition  UI Framework Definition  UI Design  Development Support