Making the Case for UX

Editor's Notes

• #2: Hi, how’s everyone? Thanks for joining us today! I’m Dorian Freeman, and here with me is Andrew Malone, Dan Cabral, JaZahn Clevenger, Mike Petroff, Roderick Morales, and Vittorio Bucchieri. We’re part of the Harvard User Experience group, which has members from all across Harvard. Our goal in forming the group was so that those of us focusing on User Experience could connect with each other and to provide UX best practices and standards for all of Harvard. Today we’re making the case for UX while building applications and websites. Just a note: we’re covering a lot today and we’ve saved time for questions at the end. If you can hold your questions until then, that would be great. Also, we’ll be providing these slides for you on our brand new Harvard User Experience Group website.
• #3: So, a quick overview of user experience: it essentially has to do with behaviors, attitudes, and emotions you have about a product, system or service. This definition is from usability.gov, which is a great resource. useful, desirable, accessible, credible, findable, usable, mobile, and valuable. source: usability.gov
• #4: When you make design decisions based on business needs balanced with user needs, it saves you from making mistakes, which end up costing you time and money Using things like styleguides and pattern libraries which follow best practices make life a lot easier for users and also for developers. For those of you in HUIT, you’ll recognize these core values
• #5: Now we’ll present 5 5-minute case studies in some ways we’ve managed to keep the user in mind for our website and application projects. We’ll talk about how to incorporate UX into the Agile process, some user research methodologies, and we even have a case study about how to use analytics as user research in order to make our websites better.
• #6: My name is Vittorio Bucchieri, Senior User Experience Lead, Teaching and Learning Technology, primarily working on Canvas, the University’s suite of technologies for teaching and learning.
• #7: Vittorio You may already know about user centered design, the practice of creating engaging, efficient user experience: every step of the product design and development takes the user into account. Following this principle, here is a very high level journey of our user centered design cycle, from initial detection of opportunities, the gathering of user feedback, and the definition, prioritization, and implementation of the feature lists.
• #8: 1:00 - 2:00 - Vittorio Here is a more detailed description of a critical step of the user centered process - Testing Thursday. Testing Thursdays is a continuous user research effort that generates regular and reliable feedback of users’ experience. Every week we meet with a few members of each School to present new or ongoing design projects and to gather as candid as possible reactions, ideas, and criticism (each school is not contacted every week.) This feedback helps us to define and plan the next testing session. Prototypes built with users’ feedback or existing interfaces are often used at Testing Thursdays. Improvements are often presented back to the Schools.
• #10: source unknown
• #11: JaZahn Hi, I'm JaZahn Clevenger from Academic technology. Unlike the others presenting today, I'm not a UX person, and further we don't have UX people on our team. I think this is the case with a lot of teams, especially small teams so I wanted to talk a little about how UX happens without UX.
• #12: JaZahn I'm going to say, for us, it all revolves around agile. This is the first principle listed in the agile manifesto. But it's not just an agile thing. This is a theme that seems to gravitate toward the buzzwords of the day. Agile, devops, UX -- the theme is iterative development that allows for course correction. We, like everyone, do a modified scrum thing. We have time boxed work that we presumptuous call sprints. At the end of those sprints, we have demos. Those demos are supposed to be to the clients, and we try to have that be the case as often as possible. When we can’t get them at exactly the end of the sprint, we get them scheduled a day or two after. We want clients in front of our product as often as possible. They need to see it, they need to experience it, let them drive it in a test environment as often as we can. We want to catch where we’re off target and I catch it quickly.
• #13: JaZahn But we don’t get it done all the time. Getting clients in is hard work. And it needs to be prioritized. Here in academic technology, our projects tend to be lumpable into two distinct categories. Administrative and Academic. One way to describe the two is that administrative applications have a captive audience. They are applications where the users don’t have a choice in their use. I’m sure you can think of some examples around the university. Academic, on the other hand, have a more targeted audience. The users make use of these applications optionally. They can choose a different product. Given that, function is the most important aspect of administrative apps, so UX tends to get less attention. But with the academic, UX becomes just as important as function, otherwise the app won’t be used and it will have been a wasted effort. Which, I can tell you from experience, creating an application and having it go completely unused is the worst.
• #14: JaZahn A good user experience doesn’t start with user testing or client feedback. It starts with a solid base. One thing we find helpful are wireframing tools. We use Balsamiq, To be able to show the client what they’re getting before we start coding is super valuable. Helping them visualize the product with a minimum of effort on our part can course correct us at the concept phase. We find style frameworks to be important in providing good styling without much work. We use Bootstrap, but anything that assists in providing a proven good look and feel is helpful. We often build tools within other systems. iSites and now Canvas. Which means we want the way our applications look and feel to be similar to the designs of other tools. This often means adopting the styles and patterns of other projects. But the point is to make sure the user isn’t jarred into a context switch. It’s important to us that our applications work well on mobile devices. It’s easy to forget “mobile first” if someone’s not constantly saying it in the meetings. And we actually have interest in making sure things are accessible. Gaining an appreciation for how differently abled people use your application can open your eyes to how everyone experiences it. We know and use patterns associated with accessibility and mobility. And we build our designs off of those patterns. What to walk away from this with: UX fits into processes you probably already have in place. By making it part of your agile process, it doesn’t feel like something extra to do, it’s just part of the process. And it’s easy to start small. You’re not going to be able to do everything talked about by all of these people, but you can do some of it. Figure out what you can do and evolve your process. This is why I’m here, to listen to what these people have to say and figure out what tweaks I can make to my process.
• #15: Intro - summary of FSS and my team Summary of our project and the “planning” phase
• #16: Andrew As part of our project planning phase, we wanted to do user research to make sure that we understood: How are people currently using our application What are the biggest gaps and areas to prioritize We have 3 main roles, UX best practice says we could get good information from 5-10 user interviews.
• #17: Andrew This is an image from PowerPoint for now (will change depending on final version) As part of our project planning phase, we wanted to do user research to make sure that we understood: How are people currently using our application What are the biggest gaps and areas to prioritize We have 3 main roles, UX best practice says we could get good information from 5-10 user interviews.
• #18: Andrew More challenging overall (especially logistics) scheduling finding rooms designing the focus group sessions more raw data to coordinate and synthesize
• #19: Andrew
• #20: Andrew
• #29: I’m Dorian Freeman, user experience lead for Harvard Web Publishing, this is Dan Cabral, we’d like to talk today about a project we’re working on: overhauling the user interface of OpenScholar
• #30: Problem: Frustrating UX When I first started as User Experience lead for Harvard Web Publishing, I created a strategy for understanding the experience our users were having with OpenScholar, with a combination of emailed feedback surveys, in-person interviews with both stakeholders and users, and the SUS (system usability scale). The SUS is a standard survey to measure the perceived usability of your product. Our results were marginal (about a C- as a letter grade), so I knew we had room for improvement.
• #31: Also, the feedback from the interviews showed frustration with inconsistent interaction flows, labeling and language. This told me then that some work needed to be done on the UI to combat this. First hurdle: buy-in There’s a move at Harvard now to improve the user experience of our applications and websites, and the trend caught on with our group. We were lucky to have a top-down directive to go ahead with this project of redesigning the user interface.
• #32: * Hi. I’m Dan Cabral. I’m the themer and UI designer for OpenScholar. * With support from management, we assembled a six person team to tackle the project from a usability, design, technical and product management standpoint. * The team from left to right: Merce Crosas, Elizabeth Quigley, Dan Cabral, Richard Brandon, Bilsi Balakrishnan and Dorian Freeman (and Sammy)
• #33: We started the project by conducting contextual inquiry interviews with about 15 existing OS users. This involved going out into the field and watching these users administer their sites as they normally would, and verbalize their thoughts, feelings and frustrations. We recorded the sessions with screen capture software and took notes.
• #34: We then took the information, translated it into data points and created an affinity diagram. With the affinity diagram we were able to see where the pain point patterns were and which categories they fell into. This helped us determine what to tackle first.
• #35: We then turned our affinity diagram revelations into several functional requirements documents. The documents highlighted the issues by category.
• #36: Using a simple tool called Balsamiq, we created low fidelity wireframes to show new usability ideas and interaction flows. After a few iterations we printed and displayed the wireframes on the walls of our office as a way to encourage feedback, and maintain support and enthusiasm for the project through transparency.
• #37: * Once we had the wireframes in a state where we wanted to validate our ideas, we were able to turn them into a clickable prototype using the link feature in Balsamiq. We then wrote up a script with tasks that we wanted to test, and met with 30 users over a 2 week period. Within 2 days of testing and 4 or 5 testing sessions, a flaw in one section of our wireframe prototype was revealed. Given the fact that we had so many users yet to be tested, we were able to create a revised version and use that through the end of our testing schedule. * With a lot of help from the Harvard User Experience group, we were able to handle a rigorous and condensed testing schedule. So thank you again, to the group. * With testing complete, we handed the wireframes off to development.
• #38: At this point, the dev team is working on technical feasibility of the proposed changes, along with a timeline for when development can be complete. We’re being told its sometime between next weekend and 13.7 billion years. After development is complete and the improvements are launched, guess what, we’ll start the process all over again to be sure we’ve eliminated the old frustrations and haven’t created new ones in the process
• #39: Are you about to ask this? I’m guessing that this case study is fairly unique in that we have a UX team, and we had buy-in from leadership to spend the time on this. What do you do if you don’t have the luxury of time to do a complete overhaul as we are doing? We’ll have a list of quick, lightweight user research techniques on the Harvard UX group website. Even if you spend as little as one hour a week talking to your users, over time you will have the data to start designing improvements based on what you’ve learned. The most important thing is to get in front of the people who use your application or website and observe what’s happening. That’s the only way you’ll know for sure what needs improvement.
• #40: We’ll put these and other resources on the Harvard UX group website, which you can get to by http://tinyurl.com/harvarduxgroup . Also, if you’d like to join the UX group, you can email me at dorian_freeman@harvard.edu
• #41: One bit of housekeeping and then on to questions!