1. 1. Start with High Level Vision
Define hypothesis to check with real users
Example: Allow instructors to present images to their students
Talk to and observe users
Understand how they get their work done
Images: digital images badly named if at all, used in many different contexts
Careful! Users leave out details!
The first tip is to Start with a high level vision of your new tool or enhancement!
key is to stay high level at this point & not make too many assumptions about system use.
A brainstorming exercise helpful in fleshing out ideas and creating range of questions to ask users
Image Gallery tool hypothesis: instructors…particularly in image heavy studies like art history…needed to share images with students on-line.
Talked to users and found out they did need to share images with users
Uncovered unexpected behaviors:
Instructors digital collections, which are typically in their infancy, are fairly disorganized with poorly named images if at all and they use their images in many different contexts from teaching to research to sharing with colleagues. Addtionally, they have lots of new and less traditional sources for images like google images
Helping manage personal collections became a priority
One note of caution in talking to users: they tend to leave out details!
they think they are unimportant or they are just so habitualized they don’t even realize they do it.
Post-ti note cheat sheets
So pay attention to what is not said!

2. 2. 80/20 rule Less is more Don't try to fit it all in
Leave out edge cases
Hide advanced or less often used functionality
the 80/20 is of particular interest to us since Sakai tries to be so much.
Many activities to support - teaching & learning, research, and collboration
Bottom line: don’t fit it all in
Leave out edge cases.
Go for the 80% and hide the less often used or more advanced functionality so those 20% who need it can find it but it doesn’t get in the way of common activities.
Screen shot

3. 2. 80/20 rule This is an example of the Section Info options.
infrequently used setting nicely hidden behind the options menu. I
doesn’t get in the way of common activities but is there the one time a term it is likely needed.

4. 3. Talk to & Watch Users We aren’t primary users What would Judy want?
Would Judy use this feature?
Potential avenues for connecting with users
Get out on campus and talk to
Instructors and students are interested in improving Sakai
Leverage other team member’s relationships
I’m sure you’ve all heard this one: Talk to and watch real users!
Easy to forget that we aren’t the primary users of Sakai
User’s don’t even talk about the details of their work
Need to ask lots of questions and watch users work to really understand how they get work done.
While working on the system continuously ask yourself questions like, would Judy really want this, or what does Judy do in this instance.
Judy here is a representative user not a particular user.
Conceptually great but logistically how do we talk to users?
Find a busy place on campus and ask people for couple minutes of their time. Candy bars can often entice students.
And don’t forget, Instructors and students interested in making it work for them
Leverage relationships other people on your team have with users.
At Berkeley, our training and support group is critical in helping us identify users to talk to.

5. 4. Find Out What’s Generally True About Your Users
Learn about enough users to separate out quirks from common behavior patterns
Loudest users likely have unusual requirements
Don’t include idiosyncratic requirements
This is really a follow up the previous slide.
Find out what’s generally true about users.
It can be dangerous to only talk to one or two users and assume they represent the majority. We need to learn about enough users until we start hearing patterns in behavior. The 80%. That’s what we want to build for.
An easy trap to fall into is reacting only to the users we do hear from which is likely 20% or less depending on our context.
Many users don’t come to us for a variety of reasons, they are busy, or feel too technically inept or they feel like their problems with the system are their fault.
So be sure to talk to a diverse & representative group of users.
The moral of the story is to be careful not to build in those idiosyncratic requirements, at least not in the main flow of the application.. As I mentioned before these kinds of requirements can be cleverly hidden in an advanced feature area if they are absolutely necessary.

6. 5. Scenarios Define Requirements & Workflows
Model activities not tasks or use cases
Context and details
Design for the typical the scenario
Workflows that match users work
80/20 rule
May include working across tools in Sakai
Example: Webcast study tool
Another important point is to think about the users entire activity.
A scenario defines an activity in it’s entirety, not just a task like uploading a file to resources but why is the user uploading the resource. Do they want students to do something with the file? If so can we include the creation of instructions and a notification in the workflow seemlessly.
Are there things that happen outside the system that are of importance? Like, do users get interrupted a lot in their activity. If so, perhaps we need to include cues about where they left off in the process so they can just pick it up when they come back. How many of you have walked into a room and forgotten why you’re there? Wouldn’t it be nice if there was a clue to remind you? This is the same kind of thing.
The 80/20 rule applies here again. Create workflows based on patterns in user’s activities, the typcial scenarios.
Take the file upload activity as exmaple. Currently in Sakai this requires users to use at least 2 tools, resources to upload the tool, perhaps assignments to give instructions and a due date and perhaps even an announcement just to make sure all students know it’s there. That said a lot of nice features have been built into resources to support just this kind of work..like notification…to cut down on this kind of cross tool activity.
I hope, as a community, we continue to build in this kind efficiency
Next I’ll show you a scenario we created at Berkeley for a webcast study tool we were designing.

7. 5. Scenario: Using Webcast to Study
Lisa has an exam coming up and wants to create a study sheet she can use for the next week while on the the gym.
She gets out notepaper, her textbook, and her binder with PPT “notes” pages and gets comfy on the couch.
She starts reviewing the powerpoints and notes from the lectures after the last exam. As she does this, she’s making notes (summarizing important topics) on her notepaper. (This will become her study sheet).
As she’s making her way through the slides she decides it would be useful to hear the instructor’s explanation of DNA replication again.
She goes to … a point in the webcast where that ppt slide is, and listens. One sentence he says seems to encapsulate the concept for her, so she tries to get it down word for word. Since her prof talks fast and does not always use lay terms, she relistens several times.
After she feels like she understands, she adds some notes in the study sheet.
She sees that there were a number of segments that she’d highlighted.
We created this scenario for a project at Berkeley that was envisioned to allow student’s to better study with webcasts of lectures. Lisa in the scenario is our primary persona, or representative user. She is a conglomeration of the students we met with and we think is a good representation of students using webcast as a study tool.
I know this is a lot of text. It’s just to give you an idea of what a scenario is like. This is an early version before we started specifying how Lisa would get these things done in the new system. We were focused on understanding what she needs to do in a perfect world first. Later versions read with specific system interactions imbedded.
I’ve highlighted interesting moments in red text
We learned that Lisa needed a way to study off-line while at the gym.
We also learned about their studying context along with typical sub tasks like synching up the webcast to the ppt slides and relistening to a section of the webcast several times.
-In this project we knew we needed to build in easy ways, preferably automated ways, to allow Lisa to do these things so she could focus on the task at hand, learning the content.

8. 6. Users Don't Think in Tool Silos
Minimize cross-tool workflows
Automate cross-tool workflow
Examples
Helper tool
Assignments and gradebook recent improvements to workflow
Data/information synchronization across tools
As I’m sure you are all aware Sakai is structured around tools. There are many good reasons for this and it also causes some user complexity since user activities often cross tool boundaries.
To help with this complexity we should minimize the need for cross-tool workflows or automate workflows so users seemlessly move between tools.
Some work has been done in Sakai to create helper tools that allow part of a tools functionality to be embedded in another tool.
In a minute I’ll show an example of where this kind of thing would be helpful.
Another good example of minimizing cross-tool interaction to complete a single activity is how assignments allows an instructor to automatically add a due date in the schedule. Again, I hope we can continue to improve users efficiency in this way.
Data synchronization is another good way to minimize users work…and luckily in many cases Sakai’s service architecture supports this activity.
The recent work to enhance information sharing between assignments and gradebook is a good example of this. My understanding is that Instructors will be able to grade assignments in either tool which will be represented in both.

9. 7. Software -- Means to an End
Minimize user’s decisions about mechanics
Hide advanced and administrative tasks
Use meaningful defaults
The implementation model is irrelevant to users - don’t reveal it
“crazy, line-breaking, non-human readable URLs which are designed to meet the system needs of uniqueness but not the human need of comprehensibility” Sean DeMonner, U of M
Software is a means to an end
Our users goals are related to teaching and learning, research and collaboration. Everytime they have to think about how to get something done in Sakai, like upload a resource, create a new section, it interrupts their natural creative flow.
When people talk about intuitive systems that’s really what they are talking about. We don’t want users to have to figure out the mechanics of the application.
If we can make reasonable decisions for them about the system we should.
This is where hiding advanced functionality, settings and administrative tasks can be helpful
We should use meaningful defaults. For instance we know that many users don’t take the time to rename their resources in Sakai so as they upload it, we default that field to the filename. If they aren’t interested in renaming the resource they won’t even think about it since the field is already filled in for them.
We can also help by hiding the implementation details. Although we all know this, it’s useful to remind ourselves that the implementation model is irrelevant to users. The UI and the back end models will likely be completely different.
Thanks to Sean DeMonner for offering this claryfing example of where we haven’t hidden implementation detail from users.
The right thing to do with our “crazy, line-breaking, non-human readable URLs” is for the system to translate them on display to users. I’m sure most of you are familiar with the idea of tiny URLs.

10. 8. Less is More
Are there some settings which aren't usually needed? If so, can you hide them?
”Extras on demand” design pattern
Less is more.
I mentioned this in reference to requirements earlier but it’s worth repeating here in regards to workflow and page design..
Every piece of information or interaction on a page competes with every other piece of information and interaction on the page.
Help users minimize their decision making in the system by only giving them the necessary information to complete a basic interaction. Less used activities can be hidden until they are needed.
So as you work through the design, you can continuously ask yourself, are there settings which aren’t usually needed? If so, move them out of the main flow or offer them to users only if they need them,
Next I’ll show an example of “extras on demand” a recognized design pattern which will be part of the Sakai DP library and can help in these situations.

11. 9. Consistency Apply known web app conventions
Yahoo Patterns,
“Designing Interfaces”, Jennifer Tidwell’s book
Apply known Sakai conventions
Copy interactions from other Sakai Tools
Style guide
Sakai design patterns -- released soon!
Conflicting interactions or questionable usability? -- Questions to UI DG,
Consistency is always a primary design goal. If we can teach users how to do something or what it means once and leverage that across the system we can save them all kinds of time.
Achieving consistency is also unusually difficult in our Sakai work since our work happens so distributed so we need to be extra cognizant of it.
When possible we should use generally known standards in web application usage and in other Sakai tools.
Yahoo design patterns and the Tidwell book listed here are a couple of my favorite references on interaction conventions or patterns.
There are also known conventions in Sakai.
You can look at other tools to see how they’ve done something and copy it.
Or reference the style guide which, although outdated, includes descriptions of basic interactions.
The Sakai design patterns are coming along and will hopefully be released soon. You can check out Marc Brierleys talk on the pattern library Tuesday at 2:00.
Even with these tools available, there is a lot of conflicting information out there.
If you run into conflicting situations, you can always pose questions to the Sakai UI DG.

12. 10. Use the end user's language
Try it out on users!
Users aren’t familiar with technical terms
Look at other Sakai tools and copy their language
Higher Education has own language
“Faculty” v.s. “Instructor” -- flexibility for local customizations
This one has been implicitly talked about already but it’s worth being explicit since it is such an important one.
Use the end user's language
Try it out on users if possible. 

Is it unnecessarily technical? Remember most users won't understand technical semantics. Replace them with more common non-technical terminology.
Also, is it consistent with usage in other Sakai tools? Look at other Sakai tools and copy their language.
Even specific areas of expertise or practice have their own language as Higher Ed does.
And as we’ve learned even that language differs by area of the world or even region of any particular country.
It’s important to allow for this kind of flexibility in language. I was reminded of this when I originally used faculty in my presentation which is uncommon outside the US. Ensuring words like this are in properties will make local customization much easier.
Again, try it out on users to get their reaction.

13. 11. Test Early & Often on Users
“Something is usable if it behaves exactly as expected.”
Joel Spolsky,
Those of us designing and developing Sakai tools know too much
Finding users
Grab students in common areas
Leverage training sessions
Offer food
Which brings me to, test your designs and even design ideas on users early and often.
Some of you may have heard of Joel Spolsky. He has a popular development blog-type site I’ve referenced here.
In his article, “Usability in one easy step”, He defines something as usable if it behaves exactly as expected.
The way to learn about users expectations is to talk to them and put them in front of the system to see their reactions.
Those of us designing and developing Sakai tools are so close to the system that we make assumptions about what users do and don’t know that aren’t necessarily real. Remember the video?
So Test paper or early prototypes on at least a few real users.
If this isn’t possible, test on someone non-technical and unfamiliar with system who will indulge you.
As I mentioned earlier, grab some students in a common area on campus or leverage training sessions other members of your team hold. Our designer at UCB, Seamus, took 10 minutes at the end of a training session to get feedback on our new Sakai skin. He got some really good feedback in that short time.
And of course, especially with students, offer them some food.

14. 12. Ask a Designer If you have access to designer(s):
Get them involved early
Once architecture is in place only minimal changes can be made
If you don’t have access to a designer:
Ask the UI DG,
Recruit a designer from another institution for your working group
So most of these principles assumed you are developer on your own without a designer teammate.
If you do have access to a designer on your team, my advice is to get them involved early so they can help shape the system based on understanding users, their needs and known design practices.
Once the basic architecture is in place there is NOT a lot less flexibility in the kinds of changes that can be made.
What if Apple had built an mp3 player just like everyone else and then passed it off to their designers for feedback. Would they have been able to from a button model to the flywheel?
Not only is it technically infeasible but by suggesting a solution, all of the sudden the world of alternatives we can see gets smaller.
Even if you don’t have a designer on your team, you can always ask questions on the UI DG list or better yet, recruit someone from the community to work with you nn your project.
And now Aaron will discuss what’s hard and what’s easy to develop in Sakai to help designers think through implementation consequences of their designs.

15. Thank You!
Questions?
Well that’s all I have to say. Thanks for listening and we’ll take any questions now.