Design for the RUDES: The Value of Design Principles
•
36 gefällt mir•3,121 views
This document discusses user experience design principles and practices. It emphasizes designing products and services that are simple, reliable, and easy to use. It advocates starting by making things informal and then progressing to more formal processes. It stresses the importance of measuring designs against goals and personas, and tracking quality over time through product evaluations. The overall message is that creating a positive user experience requires accountability to design principles as well as cultural shifts within teams to prioritize how designs matter to users.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Design for the RUDES: The Value of Design Principles
- 2. YOU KNOW IT WORKS WHEN SNARKY BECOMES DELIGHTFUL. Name: Jeff Occupation: Software Architect Experience: 12 Years Username: SarcasmOMatic foosball, coding, Hobbies: annoying coworkers Jeff
- 5. IT NEEDS TO MATTER TO SOMEONE.
- 6. User Interface Product Design UX Research Content Design USER EXPERIENCE TEAM
- 7. QUALITY
- 8. EXPERIENCE DESIGNERS FOCUS ON QUALITY PRODUCTS AND SERVICES.
- 9. CHOOSE MEANINGFUL, MEASUREABLE WORDS.
- 10. “PLEASE SELECT 5 WORDS FROM THE FOLLOWING LIST THAT We adapted this activity from Microsoft’s Desirability Toolkit (http://www.microsoft.com/usability/uepostings/desirabilitytoolkit.doc). BEST DESCRIBES YOUR EXPERIENCE WITH _____. EXPLAIN…” Accessible Desirable Gets in the way Patronizing Stressful Appealing Easy to use Hard to use Personal Time-consuming Attractive Efficient High quality Predictable Time-saving Busy Empowering Inconsistent Relevant Too technical Collaborative Exciting Intimidating Reliable Trustworthy Complex Familiar Inviting Rigid Uncontrollable Comprehensive Fast Motivating Simple Unconventional Confusing Flexible Not Valuable Slow Unpredictable Connected Fresh Organized Sophisticated Usable Customizable Fun Overwhelming Straightforward Valuable
- 11. “PLEASE SELECT 5 WORDS FROM THE FOLLOWING LIST THAT We adapted this activity from Microsoft’s Desirability Toolkit (http://www.microsoft.com/usability/uepostings/desirabilitytoolkit.doc). BEST DESCRIBES YOUR EXPERIENCE WITH _____. EXPLAIN…” Accessible Desirable Gets in the way Patronizing Stressful Appealing Easy to use Hard to use Personal Time-consuming Attractive Efficient High quality Predictable Time-saving Busy Empowering Inconsistent Relevant Too technical Collaborative Exciting Intimidating Reliable Trustworthy Complex Familiar Inviting Rigid Uncontrollable Comprehensive Fast Motivating Simple Unconventional Confusing Flexible Not Valuable Slow Unpredictable Connected Fresh Organized Sophisticated Usable Customizable Fun Overwhelming Straightforward Valuable
- 12. IAS CARD SORTS.
- 13. Reliable Useful Delightful Engaging Simple Credible Comprehensive Appealing Collaborative Accessible Empowering Customizable Attractive Connected Easy to Use Fast Flexible Beautiful Engaging Efficient Motivating Relevant Delightful Inviting Familiar Reliable Sophisticated Desirable Open Fast Stable Useful Exciting Personable Findable Trustworthy Valuable Fresh Social Organized Fun Predictable High Quality Simple Innovative Straightforward Unconventional Time Saving Universal Usable
- 14. SUCCESS IS WORKING AS A TEAM.
- 16. ENGAGING
- 17. RELIABLE
- 18. SIMPLE
- 20. http://www.flickr.com/photos/louganmanzke/2722701187/ START WITH INFORMAL, THEN GET FORMAL.
- 25. UX TEAM REVIEW FORM
- 29. “IT IS MUCH SIMPLER, BUT IT’S NOT THE SIMPLEST THING I’VE EVER USED.”
- 30. http://www.flickr.com/photos/louganmanzke/2722701187/ BUT EASY ALWAYS WINS. COMPLEXITY HAS A PLACE,
- 32. DEVELOPMENT TEAM EVALUATION FORM
- 34. “WHAT WOULD IT TAKE TO MAKE THIS PRODUCT SIMPLER?” test participant
- 35. DEFINE THE DAMN THING ;)
- 36. Our products are easy to use. Our designs enable success without training.
- 37. http://www.flickr.com/photos/21204781@N07/2320933117/ SIMPLE FOR A STUDENT?
- 38. Get Test Take a Test Answer Hand in Questions
- 39. http://www.flickr.com/photos/marcwathieu/3570647204/ ”Marc Wathieu” SIMPLE FOR A COLLEGE DEAN?
- 40. Select Review Goals Find Results Courses Evaluate Contact Samples Teachers Assess a Assign Evaluators Program Request Examples Find/Build Review Rubric Reduce Work Samples
- 41. SIMPLE? Select Get Test Review Goals Find Results Courses Evaluate Contact Samples Teachers Take Assess a Program a Test Assign Request Evaluators Examples Answer Hand in Questions Find/Build Review Rubric Work Reduce Samples Our products are easy to use. Our designs enable success without training.
- 42. http://www.flickr.com/photos/evilpeacock/5092384612/ PERSONAL. WHAT MAKES IT POWERFUL IS MAKING IT
- 43. Be accountable to your design principles! Be accountable to your design principles! Be accountable to your design principles! Be accountable to your design principles! Be accountable to your design principles! Be accountable to your design principles! Be accountable to your design principles! Be accountable to your design principles! Be accountable to your design principles!
- 44. Our products are credible. Our designs are consistent and error free. Our system is stable and fast.
- 45. *This org chart is simplified and is not a comprehensive representation
- 46. *This org chart is simplified and is not a comprehensive representation
- 47. *This org chart is simplified and is not a comprehensive representation
- 48. MEASURE THE DESIGN AND COMPARE TO YOUR GOALS.
- 49. MEASURE PRINCIPLES AGAINST TARGET PERSONAS.
- 50. DATA DRIVEN DESIGN MEANS TRACKING QUALITY OVER TIME.
- 51. PRODUCT EVALUATION ROLL UP
- 52. IT STARTED BECAUSE IT MATTERED TO SOMEONE.
- 53. IT GREW BECAUSE IT MATTERED TO THE TEAM.
- 54. IT SUCCEEDS BECAUSE IT MATTERS TO EVERYONE.
- 55. http://www.stickycomics.com/product-development/ CULTURAL SHIFT JUST HAPPENS.
- 56. LET’S HAVE A DRINK… LATER J JoAnna Hunt Rob Fay @johunt0311 @robfay
- 57. CHOOSE MEANINGFUL WORDS INTEGRATE INTO DAILY LIFE SET GOALS EVALUATE, EVALUATE, EVALUATE MEASURE PROGRESS
Hinweis der Redaktion
- So I want to tell you about this meeting I was in about 3 or 4 months ago. I’m an product designer at Blackboard so, of course, you all know what that means. Figure out the interaction design and pay attention to the needs of our users. Then try and convince everyone else why this interaction is the right thing. I’ve been working with the same team for a long time and this one day we were sitting in a design meeting and something very strange happened. Jeff (my team’s architect) turned to me and said, “You know JoAnna, I really don’t see how this interaction is all that delightful for our users”. Well I had to do a bit of a double take. I honestly wasn’t sure I had heard Jeff right. And it wasn’t at all because I disagreed with his comment. It was because I was stunned to hear those words - “interaction and users and delightful” - coming from him in a scenario where he wasn’t being snarky or sarcastic or making fun of us ‘crazy UX people’. That was the moment that I knew something had significantly changed for us. People outside of the UX team were really starting to think about how users were going to use these products. And more importantly, they were starting to speak up when they didn’t think we were building something that really engaged the user. But, how did we get to this moment?
- [JOANNA]; Well Rob is going to take you back to the early parts of 2010 when a few things were rattling around that kind of got this whole thing going for us. [MOUSE CLICK][ROB]: Well, I started working at Blackboard about three and a half years ago. When I started, there wasn’t really a defined “User Experience” team like there is today.
- At that time, we didn’t validate our designs with users. Well, we did, but it most often took the form of focus groups validating WHAT we should design rather than involving users in activities to determine if the designs were easy to use and enjoyable. There was no usability testing, no observation of users actually using the product. After all, many of the people who had been with the company for many years felt they could design for themselves. The problem was, they were no longer users of the product like they once were. For the first couple of years I wore a variety of hats, most notably leading the user and design research practice. As the UX team grew and became more involved in these research activities, we shifted the focus from simply creating a design to meet requirements to aspiring to create a design that meets the expectations of our users.
- But about two years ago, after experiencing some successes and some failures trying to get buy-in for user centered design practices outside our immediate team, I found myself asking the existential question: is my work making a difference?Business experts like Jack Welch or the late Peter Drucker might tell me that I need to have a set of objectives, values, and/or principles that can help me define what it means for me to make a difference at Blackboard. I knew Blackboard had a mission, but I wasn’t quite sure how my day-to-day work aligned with this mission in a meaningful way.I reviewed some company mission statements and goals. I even looked at companies like Google and Yahoo! to see what guidance they provided with their design principles. While I am sure those principles work well for those companies, they just did not resonate with me.So, I still didn’t have an answer and needed to look elsewhere.
- Around the same time I was asking these questions, our team was growing. So I refocused my question. Instead of asking how my work is making a difference, I asked myself how my team’s work makes a difference.
- Our entire team, in our own ways, focuses on quality.
- Some people focus on making sure we build features that meet the needs and goals of users. Others provide the front-end designs for these features. Still others write copy both in the product as well as in help documentation to enable success. But quality can mean different things to different people. More importantly, even if we as a UX team can come up with a shared understanding, how do we communicate this understanding to the rest of the organization?
- So, first we needed to define what quality meant to us. I wasn’t sure where to begin, but then I remembered how much our senior management loved the word clouds we create to communicate some of the results of our usability testing.
- In typical IA fashion, I put together a card sort with just the positive words, and asked everyone on the UX team to participate.
- Next we had to figure out what each of the words really mean. How can each principle be applied to our work and how can we measure our work against each principle?
- Last year about this time our team met to wrestle with these words. At an offsite, we divided into 5 teams to define what each principle means to us.
- We also brainstormed what it means to meet each principle and ways we might measure the quality of our work.
- We also brainstormed what it means to meet each principle and ways we might measure the quality of our work.
- We also brainstormed what it means to meet each principle and ways we might measure the quality of our work.
- We wound up with a UX team pledge and a set of principles that unites us across disciplines. The design principles we lovingly refer to as “RUDES” are comprised of the terms: reliable, useful, delightful, engaging, and simple.This framework helps us add a little objectivity to analyzing our work and it guides our thinking, problem-solving, and creative efforts. While these design principles give us the ability to communicate the value we bring in a measurable way, the ultimate value is that it defines what is important to us in a user-focused way.
- For us, just coming up with words, definitions for these words and a pledge for what it meant to be an ‘experience designer’ wasn’t enough. If we were going to be successful in using these words to help us design for a quality product we really needed to think about how to apply them to our daily life. How were we going to use this with our development teams? We decided that we needed to start with a very informal approach to this and move into something that ended up being more formal. http://www.flickr.com/photos/louganmanzke/2722701187/
- We started by thinking about how these principles applied to our designs. We began using the words in conversations about our designs, with other UX colleagues and with our development teams. We didn’t tell anyone anything about them, we just started integrating them into our vocabulary.
- In design sessions with our clients we started asking them how we could make the task simple. We talked about what could make a feature more delightful or more engaging. We discussed what could be done to make the system more useful and reliable.
- As we started to become more comfortable with applying these concepts to our daily work we branched out a little bit. We started to think about ways we could formalize the process but still keep it easy for everyone to understand and get on board with. We came up with a really easy metric to start working with our internal teams. We started to ask them if they thought the design “missed” , “met” or “exceeded” each of the design principles.
- And to keep a little humor in the process we asked our graphics people to design three icons that represented our ‘scale’: Misses (with a slightly embarrassed blush), Meets (looking pleasantly pleased), and Exceeds (cheering because we’d just hit a home run). While slightly cheesy, this really did give us a way to start talking about these principles with the rest of our development teams. And it worked.
- But before we took this to the development teams, we starting incorporating it into our design team reviews. We built this quick little table that provides a general overview of what it means to meet, miss or exceed any design principle. Before we ‘sign off’ on a feature design we have a working session with our bigger UX team. It gives us a chance to review the design ideas, find holes and things that could use a bit more work before we present the ideas to the development team. In each of these working sessions the UX team does a quick peer review against the design principles. It’s been a great way for us to get feedback about the work we’ve been doing before we get too far into the development cycle.
- Now our content development group took this one step further. If you remember, they are a rather recent addition to the UX team and they already had a method for evaluating the documentation and training materials they develop. After the creation of our design principles though they modified what they’d be using to focus more on things like how engaging or useful is the material. Is it delightful? How reliable or simple is it? They developed a detailed 4 point scale to assess each principle.
- They added letter grades to quickly refer to this scale and clearly articulated what it means for their training and help materials to receive an A, a B, a C or a D for each principle.
- The review process they use is quite formalized. They pull together a cross functional team – including people from the Content Development group, the Product Designers, the QA folks, and I think even a few members of the engineering team – to complete a detailed review of all the training and help materials. Each member of this cross functional team reviews the item – the training plan or product help document – and evaluates it against the design principles scale.Since the team had defined a very clear understanding of what it meant to achieve a 3 or a 4 on each principle they were able to set clear Quality Targets for each piece of documentation they were evaluating. Once all the evaluations were collected from the cross functional team they were able to aggregate the data and get the “Overall Score” which could be compared to the previously set targets.
- Each person is also able to add feedback to his or her assessment of the materials they are reviewing. As the design principles became more deeply ingrained in our daily lives they started cropping up in the feedback the Content team was receiving from the cross functional review team. For example, this person (when evaluating a particular series of training materials) commented that while they were much simpler than the previous materials they were still not the simplest thing to use. This is a pretty clear indicator that something was amiss and that these training materials needed a bit more work. The most interesting thing here though is that the reviewer referred to their experience in terms of the design principle.
- So, our Content Designers took the design principles and figured out how to apply them to the work they were already doing to gather metrics about the quality of the training and help materials they were developing. It was complex but it worked beautifully for them. However, for the rest of our feature development work we’ve discovered that things are much more successful if we stick with something easy. Something that can be assessed quickly but still give us the information we need to improve the product. http://www.flickr.com/photos/louganmanzke/2722701187/
- Our little happy faces work really well when we’re trying to get a quick assessment from the development team. It’s really easy for them to select which represents how they feel about the features we’ve been working on. In a typical development project each team is working on a bunch of different features. And a complex assessment of the quality of the user experience wouldn’t fly with them. They just don’t have the time. This works because it’s easy.
- This template is used with the development team to assess any feature they are working on. At a few points within our development process (at the end of our design period, the end of each sprint of development, and just prior to release) the development team gets together and talks about where they think the feature stacks up. It’s a discussion that results is a single evaluation of the feature. It takes about 30 mins and gives everyone a chance to offer up their thoughts about where they’d place the feature on this easy scale. You’d be surprised and how quickly people start to notice the things that could have been done better. Teams start to recognize where scoping constraints and design compromises end up having a direct impact on the end user. And next time they are less likely to push for the same kind of compromise.
- And it was in one of these meetings – where we were assessing the design of a new feature – that Jeff spoke up and called out that we were really missing the mark in terms of Delight. It was amazing to see the awareness he and the rest of the team had on what the impact of these features would really be for our end users. Up until that point it had been a bit like pulling teeth to get them to ‘give’ anything that would improve the experience just for experience sake. We could start to see these really minor shifts in our organization. We started moving (however slightly) away from being a very engineering focused company to much more of an experience focused company.
- Once we had the development team thinking more about the user and starting to assess the features we were building we needed to start incorporating our design principles into the formal user and design research we were doing. Of course we’ve been testing our features for some time now. But after developing these design principles and working them into our daily lives we really needed to validate the information we were gathering. We had peer reviews with the UX team, we did formal but easy assessments with our development teams, and we started adding explicit questions related to these principles into our client testing. We’d ask them to ‘grade’ the feature against each principle and then we’d compare the reaction we were getting from clients to the assessments we’d gathered from our peer review and team assessment of the feature. It’s really started to give us a well rounded picture of the overall quality of the products and services we’re providing.
- But, as you can imagine… defining these things… well it’s a bit of a challenge. If you remember, in the beginning we did come up with a general definition or statement that summed up each principle.
- Take simple for example. Simple to us means that our products are easy to use and our designs enable success without training. In theory that seems pretty straight forward. But..
- Think about what simple means for a 4th grade student taking a test. http://www.flickr.com/photos/21204781@N07/2320933117/
- What do they really need to do? They need to get the test from the teacher. They need to answer the questions in the test and they need to hand it in. This is a fairly simple and straight forward task.
- Now think about what’s involved when a Dean is assessing a program.http://www.flickr.com/photos/marcwathieu/3570647204/ ”MarcWathieu”
- The task itself may sound as straight forward as the student taking the test. But there is a significantly higher number of things involved in this process. It’s inherently more complex. Yet we still need to strive to make the system as SIMPLE as possible.
- But simple can’t really mean the same thing in both of these situations. What makes something easy to use for a 4th grader is vastly different that what a Dean can handle when trying to do something as complex as assessing the Business program for Harvard University. We have some very good general definitions for each principle, but we’ve realized that each project demands that we slightly rethink how we apply that general definition to what we’re trying to achieve in that particular scenario.
- What makes our Design Principles successful is that we made them our own. We didn’t just adopt some standard how-to template that worked for someone else. Instead, we grappled together to define quality. We identified words that were meaningful for us, and then together we determined how we can measure our work against these principles.Would I use these words if I worked elsewhere? Probably not. Much of the value was in the process to find principles that were meaningful for us right now. Some of these principles are stretch goals for us right now because we identified some challenges to the user experience that we wanted us to focus more on. Not only us, but we wanted others throughout the organization to have more of a focus on the user experience.Even if I worked as a consultant, I could see myself engaging a client to identify their goals for quality that we could validate with client stakeholders and their customers alike.http://www.flickr.com/photos/evilpeacock/5092384612/
- I’m really excited about how we validate our work. As JoAnna mentioned, there’s 3 groups of people that we validate against: our immediate UX peers, our larger, Product Development team, and our customers. With that said, we have to be willing to improve our process so we can be held more accountable.http://www.addletters.com/bart-simpson-chalkboard-wallpaper-generator.htm
- One principle we know we do not have right from a measurement perspective is the principle of RELIABILITY. When we conduct a point-in-time usability test remotely using web conferencing software with a choppy connection using a single development box to test the feature, can a test participant confidently provide us with their assessment of a feature’s reliability? One solution may be to change the way we assess reliability from our customers. One idea I’ve had is to use a variation of the Net Promoter Score. The NPS asks, “How likely is it that you would recommend [Company X] to a friend or colleague?” Although the NPS is a measure of customer loyalty, if we instead asked if they would recommend the tested feature to a friend or colleague, this might be a good indicator of the feature’s reliability, trustworthiness, and credibility. I’ll have to test my hypothesis.(http://www.netpromoter.com/ NPS: “How likely is it that you would recommend [Company X] to a friend or colleague?” NPS = % Promoters 9-10s minus % Detractors 0-6)
- That still may not give us exactly what we need because reliability may be something that can only be assessed over time rather than a single point in time.Besides looking to tweak this principle with our customers, maybe the UX team can look to others in the organization for assistance. We do not have to be the owners of all design principle data.
- For example, the performance engineering team tests the system to find ways in which they can optimize the speed that transactions are performed. Maybe we could use some transaction speed measurement.
- Or perhaps we deepen our relationship with our client support team even though they are outside the department. They “own” an important data point of reported bugs, and since they already track bugs at a feature level, we could use this data source to give us an understanding of reliability from a different angle.We are constantly looking to evolve our process and we know we still have some things to sort out.
- So we have some future plans to improve the process. In addition to thinking about how we can improve our measurements, we want to be more intentional about identifying our goals prior to any design effort.Currently, we begin the design process with the goal to meet or exceed each principle. But this vague target means that we haven’t really raised the bar high. As JoAnna mentioned earlier, a principle like SIMPLE may mean one thing if we are focused on middle school students completing a test, still another for a dean who must undertake a multi-year program assessment project.
- If we start measuring each principle against target personas and the needs and goals of these people, we can start making decisions about what we are shooting for with each principle. Perhaps it means that some principles will matter more than others depending on the people we are designing for and the tasks they need to accomplish. Then, when we assess the “state of the design” with our various stakeholders at milestones throughout the Product Development Lifecycle (PDLC), we can see how our user scenarios change and make decisions about whether or not we need to hold up a feature because it has not met our design principle goals.
- I mentioned in the beginning of our talk that our senior management loved the word clouds we used to convey the results of the desirability metric we collect in our usability tests. This was most profound when we compiled all of the words people selected in our usability tests for a given software release. It was a really cool way to get the pulse of the product.Similarly, we want to collect this data, not just point in time, but we want to see if we can improve product quality over time. This means we have to collect metrics for these principles at a feature level and roll them up so we can track progress over time. If we can, in a similar way, show how each principle has increased over time for a given feature, this will obviously please our senior management.On the other hand, if we see a negative trend, the hope again is that we can use this data to hold up a release due to “user experience” quality concerns.
- Here’s an example of how we are starting to collect data at a product level. We are mapping the feature and the release so that we can look for historical patterns. But right now we are just setting the baseline. As we touch new or existing features for development, we are applying our design principle metrics and want to start to gather more definitive data elements.
- But it succeeded because we managed to get everyone on board. UX matters more now to everyone in Product Development than it did when we started. Sure, we still have a way to go but we really are seeing some interesting transitions already.
- But it succeeded because we managed to get everyone on board. UX matters more now to everyone in Product Development than it did when we started. Sure, we still have a way to go but we really are seeing some interesting transitions already.
- But it succeeded because we managed to get everyone on board. UX matters more now to everyone in Product Development than it did when we started. Sure, we still have a way to go but we really are seeing some interesting transitions already.
- We didn’t start this with the thought that we would change the way people think about quality. We wanted to come up with a vocabulary that would let us talk to the rest of our department about usability and experience. But the unexpected benefit was that not only did we change the way people think about their work, we, in a sneaky way, brought about a significantly increased focus on user centered design and we’re pretty excited to see what can happen next. Image from http://www.stickycomics.com/product-development/
- Assign numeric values to qualitative information.Define what you think these principles mean to your discipline. What is good, what is bad?Blackboard is an education company, many of our execs have an education background, so they understand the 4 point scale.Keep it simple.content development peer review, detailed rubricshow simple validations with team and users