More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (16)
Similar to Making the Case for UX
Similar to Making the Case for UX (20)
Recently uploaded
Recently uploaded (20)
Making the Case for UX
- 1. Making the Case for User Experience (UX) Members of the Harvard User Experience Group: Andrew Malone, Dan Cabral, Dorian Freeman, JaZahn Clevenger, Mike Petroff, Roderick Morales, Vittorio Bucchieri IT Summit June 4, 2015
- 2. What is UX? UX is an end user’s behaviors, attitudes, and emotions about using a particular product, system or service. Successful UX must be: ● Useful: Content should be original and fulfill a need ● Usable: Must be easy to use ● Desirable: Image, identity, brand, and other design elements are used to evoke emotion and appreciation ● Findable: Content needs to be navigable and locatable ● Accessible: Content needs to be accessible to people with disabilities ● Credible: Users must trust and believe what you tell them ● Mobile: Must be cross-device compatible Good UX equates to data-driven (validated) design!
- 3. Why is it important? UX best practices and goals are always user-focused. ● Benefits of inserting UX into your project: ○ Design decisions are based on business needs, balanced with user needs ○ Standard best practices make the experience more consistent for the users and the developers ○ Follows the HUIT core values: user-focused, collaborative, innovative, and open
- 4. Lightning Round: Case Studies From User Research to Implementation Roderick Morales and Vittorio Bucchieri UX for Developers JaZahn Clevenger User Research Within the Harvard Environment Andrew Malone Using Analytics In User Research For Web Redesigns Mike Petroff Interface Design Decisions Based on User Research Dorian Freeman and Dan Cabral
- 5. From User Research to Implementation Vittorio Bucchieri | Roderick Morales
- 6. From User Research to Implementation
- 7. From User Research to Implementation
- 8. From User Research to Implementation
- 9. Take away
- 10. UX for Developers JaZahn Clevenger
- 11. Agile and UX “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
- 12. Priorities and UX Administrative (Captive Audience) Academic (Targeted Audience) DevDev Dev Dev Dev UX
- 13. - Wireframing Tools - Style Frameworks - Unified Design - Accessibility / Mobility patterns Where to Start
- 14. User Research in the Harvard Environment Andrew Malone
- 15. User research: What we wanted
- 16. User research: What we had to do
- 17. Our user research phase expanded from ~2 weeks to ~6 weeks.
- 18. Benefits of expanded research - Stakeholder engagement and buy in - Easier prioritization - Increased overall goodwill across the userbase
- 19. Challenges of expanded research - More expensive (time and money) - Didn’t significantly improve what we learned - Difficult to sustain and scale for the future
- 20. Using Analytics in User Research for Web Redesigns Mike Petroff
- 21. Researching user behaviors and trends
- 22. Researching user behaviors and trends
- 23. Exploration, strategy, and goals •More contemporary look and feel •Marry mobile and desktop experiences •Increase and improve overall traffic •Elevate multimedia content •Draw more content from across University •Deepen coverage of key university themes •Enable easier posting from the archives
- 24. Detailed event tracking in Google Analytics
- 25. Detailed event tracking in Google Analytics NEXT box in Gazette 2.0 design
- 26. Detailed event tracking in Google Analytics The ‘NEXT’ box even drove more internal story clicks than the ‘POPULAR’ stories sidebar (since launching)
- 27. Using Analytics in User Research for Web Redesigns Allows you to: ● Design for specific business goals ● Test new website features for specific audiences ● Adjust website features through iterative processes ● Show value of new website features
- 28. Interface Design Decisions Based on User Research Dorian Freeman | Dan Cabral
- 29. The Problem
- 31. The Team
- 33. Affinity Diagram
- 35. Wireframes
- 37. Technical Feasibility and Timeline
- 38. What if we don’t have time?
- 39. Resources ● Safari Books Online (with Harvard PIN) ● Secrets of the UX team of One ● Rocket Surgery Made Easy, The Do-It-Yourself Guide to Finding and Fixing Usability Problems ● UX Project Checklist ● UX Myths ● What UX is Not ● Google’s Tag Manager ● Harvard.edu/guidelines ● Subscribe to the Digital Roundup newsletter ● Usability.gov website ● Harvard User Experience website http://tinyurl.com/harvarduxgroup ● Join the Harvard UX Group! email dorian_freeman@harvard.edu
- 40. Up Next: ● Afternoon Keynote by Frances Frei of HBS at 3:30 in Sanders Theatre ● Reception in Annenberg following the keynote
Editor's Notes
- 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.
- 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
- 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
- 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.
- 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.
- 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.
- 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.
- source unknown
- 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.
- 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.
- 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.
- 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.
- Intro - summary of FSS and my team Summary of our project and the “planning” phase
- 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.
- 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.
- Andrew More challenging overall (especially logistics) scheduling finding rooms designing the focus group sessions more raw data to coordinate and synthesize
- Andrew
- Andrew
- 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
- 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.
- 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.
- * 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)
- 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.
- 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.
- We then turned our affinity diagram revelations into several functional requirements documents. The documents highlighted the issues by category.
- 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.
- * 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.
- 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
- 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.
- 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
- One bit of housekeeping and then on to questions!