Sakai Tools Designing a User-Centered Sakai Tool Sakai Tools Team Rob Lowden, Daphne Ogle

  • Published on
    03-Jan-2016

  • View
    213

  • Download
    1

Embed Size (px)

Transcript

  • Sakai ToolsDesigning a User-Centered Sakai Tool Sakai Tools TeamRob Lowden, Daphne Ogle

  • AgendaTools Team UpdateUser-centered design (UCD)Deep Dive IDEO VideoUCD and Sakai ToolsCSS and skinning Sakai

  • Tools Team UpdateTTeamPast 18 monthsNext 6 monthsTo infinity and beyond

    TTeam UpdateUCDIDEOProblem StatementResearchModelingRequirements DefinitionFramework DefinitionDesignDevelopment SupportCSS

  • Why User-Centered Design (UCD)Successful adoption Users choose to use SakaiNO need for "excessive" training and support staffUsableEasy to use / IntuitiveMeet basic user needsDoesnt cause more work

    TTeam UpdateUCDIDEOProblem StatementResearchModelingRequirements DefinitionFramework DefinitionDesignDevelopment Support

  • Suggested UCD ProcessCooper Consulting, www.cooper.comTTeam UpdateUCDIDEOProblem StatementResearchModelingRequirements DefinitionFramework DefinitionDesignDevelopment Support

  • IDEO VideoTweak processMulti-disciplinary teamFail often in order to be successfulFeedback early and oftenWatch users at work in their worldDont be constrained by current systems

    TTeam UpdateUCDIDEOProblem StatementResearchModelingRequirements DefinitionFramework DefinitionDesignDevelopment Support

  • Problem StatementProblemThe problem ofAffectsAffectsImpactThe impact of which isSuccessful SolutionA successful solution would provide (benefit of successful solution)Menlo Innovations, www.menloinstitute.comTTeam UpdateUCDIDEOProblem StatementResearchModelingRequirements DefinitionFramework DefinitionDesignDevelopment Support

  • Legacy Tool Refactor Problem StatementProblemMany Sakai legacy tools are unintuitive and not aligned with style guideLimited amount of time & resources available between end of January and Sakai 2.0 release.AffectsAffects faculty, students, staff and researchers in higher educationImpactThe impact of which is that Sakai end users have to spend a lot of effort to use the tools and have an inconsistent mental model of the how Sakai works Successful SolutionA successful solution would provide:Users a consistent interaction model across tools so expectations are met (e.g. how do I navigate, what is a link and whats not, where certain types of actions can be found, etc).Change all legacy tools across system at the same level in given timeTTeam UpdateUCDIDEOProblem StatementResearchModelingRequirements DefinitionFramework DefinitionDesignDevelopment Support

  • ResearchUser ResearchObserve users in the field Interview users and stakeholdersUtilize existing user dataSupport issuesLogsSurveysEtcDesign and usability principles

    TTeam UpdateUCDIDEOProblem StatementResearchModelingRequirements DefinitionFramework DefinitionDesignDevelopment Support

  • ModelingPersonasPersona MapScenarios / Activity DiagramTTeam UpdateUCDIDEOProblem StatementResearchModelingFramework DefinitionRequirements DefinitionDesignDevelopment Support

  • PersonasTTeam UpdateUCDIDEOProblem StatementResearchModelingRequirements DefinitionFramework DefinitionDesignDevelopment Support

  • Persona MapTTeam UpdateUCDIDEOProblem StatementResearchModelingRequirements DefinitionFramework DefinitionDesignDevelopment Support

  • Scenarios/Activity DiagramsScenarioSystem use in story formActivity DiagramSame use in diagram formIncludes context of workMore real than task flow TTeam UpdateUCDIDEOProblem StatementResearchModelingRequirements DefinitionFramework DefinitionDesignDevelopment Support

  • Requirements DefinitionUse Case DiagramsUse Case MatrixHigh-level requirements docTTeam UpdateUCDIDEOProblem StatementResearchModelingRequirements DefinitionFramework Definition DesignDevelopment Support

  • Use Case DiagramTTeam UpdateUCDIDEOProblem StatementResearchModelingRequirements DefinitionFramework DefinitionDesignDevelopment Support

  • Use Case MatrixTTeam UpdateUCDIDEOProblem StatementResearchModelingRequirements DefinitionFramework DefinitionDesignDevelopment Support

  • Framework DefinitionInformation architectureNavigation characteristicsUse case detailStyle guideTool interoperabilityTTeam UpdateUCDIDEOProblem StatementResearchModelingRequirements DefinitionFramework DefinitionDesignDevelopment Support

  • DesignTask FlowsSite DiagramsMock-upsTTeam UpdateUCDIDEOProblem StatementResearchModelingRequirements DefinitionFramework DefinitionDesignDevelopment Support

  • TTeam UpdateUCDIDEOProblem StatementResearchModelingRequirements DefinitionFramework DefinitionDesignDevelopment Support

  • TTeam UpdateUCDIDEOProblem StatementResearchModelingRequirements DefinitionFramework DefinitionDesignDevelopment Support

  • Development SupportFunctional specificationsRelentless communicationUser testing

    TTeam UpdateUCDIDEOProblem StatementResearchModelingRequirements DefinitionFramework DefinitionDesignDevelopment Support

  • ConclusionBig picture understanding of UCDUCD for final core releaseEstablish UCD as best practice for future of SakaiWhat would be helpful for December conference?

    TTeam UpdateUCDIDEOProblem StatementResearchModelingRequirements DefinitionFramework DefinitionDesignDevelopment Support

    I borrowed this user-centered design process diagram from Cooper.com, Alan Coopers software consulting firm. Some of you may have heard of Alan Cooper, hes a recognized guru in software design and usability. Hes written books like The Inmates are Running the Asylum and About Face 2.0: The Essentials of Interaction Design, also well recognized in the field.Although there are many variations of this process, I think this does a good job of covering the overall idea.Research is spending time with stakeholders and users, interviewing them and watching them do work.Modeling is creating models that describe what youve learned in your research. This is an easy step to skip but is extremely valuable in helping us keep focused in our design. Ill talk more about this in a minute.Requirements definition takes modeling to the next step to decide what the tool needs to provide users at a high level.Framework definition describes the details of the user interaction and system requirementsDesign includes, detailed task flow and mocking up what the tool will beDevelopment support includes communication the system in way that make sense to the development team. At face value this process can seem a little overwhelming. The first 5 phases are prior to any coding.Thats why its important to be flexible and decide what is important for a specific project.A good way to make mistakes faster and move through this process quickly is to time box activities. Most of the time the goal isnt perfection but to be agile and continue to learn more as you move through the process.Youll see IDEO go through a similar process in a 24 hour period in the video well be showing.

    Im going to fairly quickly walk through some activities and possible artifacts produced for each of these steps. Again, each project is different so Im not suggesting this presentation is entirely inclusive nor that each of these activities be completed for every tool but rather my goal is give an overview of some example activities and artifacts that can be used in user centered design and how they might apply to Sakai tool design. Problem statement wasnt outlined in the process slide but wanted to share it with you because of the value it brought to us in the refactor project.This is a basic outline to help think about the problem to be solved.And next Ill show you the problem statement for the refactor project.This isnt the exact statement we used for the project. 2.0 project plan required detail but general idea in less words.

    Read the statement.

    Notice success can be tested when the project is complete. We continued to come back to this statement throughout the project to keep us from getting into scope creep.There were many additional usability changes we would have liked to tackle during this work but it wasnt part of our initial problem.So they became feature requests.Saw a good example of getting out in the field to see how users really do their work in the IDEO video.In our case, not quite as easy as going to a public place where users are in abundance. For us it likely involves scheduling interviews and observations with users. Even in a scheduled observation, the key is not to interrupt users flow. You want them to be as natural as possible to capture how they really do their work. Sit quietly and watch users. Save questions about the work until they are done.

    With interviews dont directly ask users what they do and how they do it since we know they arent good at filling in the details.Ask them questions like what is the most challenging part of your work? What do you like and dislike? Who do you communicate with in your work?

    In addition, at Michigan we have quite a bit of data weve gathered over the past couple of years and continue to gather. Support issues, surveys, user testing data, etc. supplement the more ethnographical research. NO big interaction changes so Observe users in the field users BUT used some of our existing information to inform minor usability enhancements.

    Also used UCD principles like preventing users from making errors. For example, web content required users to set window display size by inputting pixel size in a free text entry box. We changed this to a drop down with a handful of more meaningful choices, although still in pixel size.There are tradeoffs, from a user perspective the solution should be to automatically size the window for the content but given resource constraints we made an incremental improvement.Modeling activities help further understand and communicate what was learned in the research phase. Process of creating the models can also tighten understanding.To practice UCD, get feedback along the way to clarify understandingThese artifacts can be great tools for early feedback.The feedback doesnt need to be formal. Brief meeting or simply hanging out in a place like a local coffee shop where you know users frequent and ask them if they have 5 minutes. At Michigan, we have just implemented a coffee card policy.We accost them in the hall of a busy building like the Media Union.And then we give them a card for a free cup of coffee to spend a couple minutes with us.

    The three models Ill talk about today are: personas, the persona map and scenarios.Dont expect you to be able to read all of this, general context.Large persona map

    Sarah primary persona the TTeam uses for Sakai work. Collectively came to this conclusion in a face to face meeting.Talk more in a minute.Personas are an archetype of a typical user.If we design for Sarah we will create a system that meets the needs of the rest of our users.Focusing on personas or the archetype users helps: keep us from designing for individual idiosyncrasies and functional edge cases.

    We can learn a lot from Sara.Her focus is on teaching and learningnot software design.In fact, the part of her job she enjoys the least are the administrative tasks.She teaches on-line courses so her communication with some students may be limited to virtual types.She is interested in using technology to improve her teaching and interactivity with students.Understanding that students are technically savvy and like to use it, means shes more likely to put in effort to make sure she takes advantage of technology available to help in her teaching.She has a basic understanding of technology both with desktop applications and the web.She doesnt want to appear stupid to students or colleagues which means she doesnt want to make mistakes on her sites that these other people use.

    Take a look at the persona map when you have a chance and see what you pull out of them that affect how we design Sakai Tools.Which brings me to the persona map.

    Tools team collaboratively created this persona mapStarted out with over a dozen personas:varying jobsGoalstechnical skills.Havent included researchers in the mix yet but plan to. The focus for 2.0 was on the LMS side since that is what many of our schools are replacing.Looking forward to thinking about the research side things in the near future.

    Narrowed to focus on primary and secondary personas.Along with Sara, Ed, Sandra, Yu Jin on the 2nd ring are extremely important to design decisions. Brad, Raul and Jauque are on the fringes. We need to keep them in mind as they have different needs but they are not are primary focus.If it comes down to a design decision, Sara wins over everyone else.Again, these are the personas that if the system is built for them, they will meet the rest of the users needs.Not going to go into the process here but Im sure anyone from the tools team would be happy to talk more

    Key decision factors: Sara is less technically savvy than some other personas.Her on-line courses mean that Sakai is likely her primary interaction with many of her students.Shes used other LMSs and will have expectations based on that.Sakai is a means to end for her. She doesnt enjoy the administrative duties of her job. If Sakai can save here pain here, it will be a big a win.

    Further understanding of user work, scenarios and activity diagramsScenarios describe a system usage in story form. Activity diagram is more of a task flow.Decision about which to use depends on the learning style of the people using them or the audience if they will be shared with others.

    Scenarios can seem more real since they are a story about the user so they are good for sharing with project stakeholders.I find activity diagrams particularly useful in analysis of the task but writing a scenario first can help create the activity diagram and make sure steps arent inadvertently left out. Diagrams in general tend to lend themselves to conciseness and leaving out the details like, the user needs to go to another tool or site to get information to complete a form.These kind of details that have design implications that UCD tries to capture. Scenarios and activity diagrams are typically tied to a particular persona.Includes things the user may have to do outside the system. A classic example is interruptions. So, while Sara is creating her class website she may get a phone call or have a student drop in.This kind of thing is important to design.It tells us that there may be breaks in activities so we need to be mindful to provide cues as to where the user is in the system or a particular activity.Also affects things like system time-outs.Sakai, in its Chefs days timed users out after several minutes. Weve increased that to 30.Didnt create any formal scenarios or activity diagrams for the refactor project since we were constrained to implementing style guide changes. There was no time for major interaction or functionality changes.Requirements definition takes the modeling one step further to define the high level goals users need to complete in the system.Many people refer to this stage and some combination of the previous ones as needs analysis.This stage is still focused on what the user needs to do and not how. By jumping to how to quickly before understanding the big picture, uses...

Recommended

View more >