UX Quackery by @uxbear All images used in this webinar are from http://giphy.com, Twitter, or made by myself. View this presentation at http://uxquackery.com.
First let’s Define User Experience (UX) UX Job Title Generator –Aaron Weyenberg (@aweyenberg), User Experience Lead at TED Talks Google Translate us·er ex·pe·ri·ence (ˈkwak ə rē), n. 1. the overall experience of a person using a product such as a website or computer application, especially in terms of how easy or pleasing it is to use.
My “Alternative” Definition of UX 1. "UX is a thing that happens whether you design it or not… UX Design is the process of making that work in a way that makes the user not homicidal, which is always a plus. Good UX Design is something that too few companies do." –Laura Klein, (@lauraklein), Principal at Users Know 2. "You're only a UXer if you're doing usability testing, or at least you're involved in a team that does." –Harry Brignull (@harrybr), Independent User Experience Consultant 3. “UX is helping the business or organization map their objectives with the consumer or end-user goals. If we can generate a win/win we’re on a path to growth… it’s really the perfect marriage of those two sides.” –Shefik Bey (@shefikbey), Co-Founder of Loop11 & U1 Group
Now, let’s Define UX Quackery UX Quackery ux•quack•ery (ˈux kwak ə rē), n. dishonest practices and claims of special knowledge and skill in the field of user experience.
Why is There UX Quackery? For those that don’t understand User Experience, UX Quackery is because: 1. People don’t know what UX is or know its UX principles 2. People don't understand UX’s role, value, and how it’s included
For Those that Don’t Understand UX People don’t know what UX is, know its principles, and often treat UXers as: ● Content Strategists ● Front-End Developers ● Graphic Designers ● Marketing Specialists ● Test Writers ● User Interface Designers ● Web Designers
For Those that Don’t Understand UX People don't understand UX’s role, value, and how it can help perform: ● Business/Consumer Alignment ● Design Research ● Information Architecture ● Interaction Design ● Prototyping/Wireframing ● Service Blueprinting/Mapping ● Testing for User Data
Why is There UX Quackery? For those that do understand User Experience, UX Quackery is because: 1. The UX skill sets are all-encompassing and vast 2. UX is cool, everyone loves UX, and everyone wants to do UX 3. Everyone thinks they completely understand UX and can just do UX
For Those that Do Understand User Experience The UX skill sets are vast, are duplicative to some degree, and cross over into: ● Content Strategy ● Data Visualization ● Design and Development ● Design Management ● Psychology ● Service Design ● Statistics and more...
For Those that Do Understand User Experience Right now UX is cool, everyone loves UX, and everyone wants to do UX because of: ● The UX Buzzword ● Blogs, Conferences, eBooks, Podcasts, Speakers ● It’s an Ever-Changing Field ● It’s Proven to Actually Work!
For Those that Do Understand User Experience Everyone thinks they completely understand and can just do UX 1. All you do is make comps/wireframes 2. Anyone can bend data to prove their point 3. I can find a study that supports anything I want to do 4. It’s just design 5. You’re just making tests
Crazy, Right? What all of the previous reasons are getting at is that the field of UX is really rough on practitioners. UXers are sometimes viewed as weirdos, that we’re too touch-feely, that we don’t know what we’re doing, or that we’re practicing in an ‘undefined magical field’... When, in fact, we’re actually sorting out other people’s quackery, having conversations to build collaborations, and trying to help both employers and users.
Yessir… a lot Contributes to UX Quackery So, over the course of the last five years – in three different UX positions and team structures – every time I encountered quackery I wrote it down. I now can share some insights on… Where, When, and Why UX Quackery Occurs … and help other stop it from occurring.
My UX Quackery Breakdown In my experience there is UX Quackery everywhere, and in every step of ‘the process’... Initial Stakeholder Meetings Conducting Usability Tests and Making Recommendations
Let’s Shed Light on UX Quackery from stakeholders, in understanding users, with identifying users, in considering user age, with testing rationales, when writing tests, from developers, when prototyping, for recruiting participants, A/B tests, and when conducting tests.
From Stakeholders ● “Accessibility isn't the concern of UX.” ● “UX people can't build prototypes in HTML and CSS.” ● “You build static designs, not interactive prototypes.” Truth: UXers are multiclass characters. ● “We don't have time to get user data.” ● “We don't have the money to hire someone.” ● “Let’s hire a contractor/get an out-of-the-box solution.” Truth: Stakeholders dislike stabilizing, building the right way, and often prefer to opt for ‘quick wins’ (AKA triage). ● “When it comes to our design we should just look like our peers.” ● “We can't launch until it's perfect.” ● “This is why we design by committee; has everyone signed off?” Truth: Stakeholders fear change and are risk averse. ● “Our PM can act as PdM… we’re Lean.” ● “Why do they want to razzle dazzle and brandify everything?” Truth: Stakeholders often have bad ideas, and your team maybe has staffing problems.
From Stakeholders ● “You’ll just find a study to support whatever agenda you want to push.” ● “You bend user data to push your own agenda.” ● “Just do exactly what they want so we don’t have to argue about it… that’s what will happen anyways.” ● “You're not building what the users want because you're not building what the stakeholders want.” ● “We should make the changes that the stakeholders want before we have user data” ● “The stakeholders treat me like a mouse, and tell me what to do down to colors and pixels.” ● “I know design, UX, and our user!” ● “Do what the stakeholders want or they will kill the project.” ● “The stakeholders will interpret the user data on their own.” ● “If you feel passionate about A UX issue, you'll fight to prove your point.” Truth: Stakeholders can be difficult to work with. Larger conversations and win/wins are ideal, but sometimes you need a mediation process, or just find a new job.
Understanding Users ● “Users like cool terms not delivery dates.” ● “Users don't care about search or sorting by price, date, or author.” ● “Let's just keep throwing more product ads up… it will increase conversion.” ● “Put in another link to the event.” Truth: Users appreciate clarity and saving time when they use your products. ● “We should follow Apple or Google’s example.“ ● “People don’t scroll, put all content on the page.” Truth: You need to observe and study your own users’ behavior to make successful decisions.
Understanding Users ● “Of course undergraduate students use interlibrary loan.” ● “We haven't heard any complaints, so users must love the website.” ● “We don't need to conduct survey because Google Analytics is enough user data.” Truth: Sometimes you need to ask your users questions to get answers. ● “The website make sense to me, so it must not make sense to our stupid users.“ ● “I don't know anyone who uses a tablet to read.” Truth: You are not your user.
Identifying Users ● “We know who our user is!” ● “We see how they use the app, and we know they don’t do this.” ● “Our users are of three distinct groups, and have very different needs. There is no crossover.” ● “Nobody uses ad blockers.” Truth: Every business or organization needs real data personas. Top task surveying or marketing information, combined with analytics, creates personas based on real user data. This often requires stitching together both qualitative and quantitative data (unless you have Google AdWords or Adobe Marketing Cloud).
User Age ● “Everyone knows what the floppy disk icon means.” ● “There is no such thing as generational knowledge.” Truth: Generational knowledge is real, as well as gaps in technology. Generation Z have had iPhones since they were four, whereas Generation X grew up when there were electric typewriters. ● “It doesn’t matter if there is an age difference between our stakeholders and our users.” Truth: Be aware of age gaps. If your users are 17 to 22 but your stakeholders are over 45, there is a huge gap between affordances, cognitive load, expectations, interactions, and technologies. Likewise, a 24-year-old designing for people over 40 that have visual impairments, contrast and layout is important you’re trombone-ing devices.
User Age ● “Younger users like serious design versus playful designs.” ● “Nobody will ever use emojis!” ● “We can’t design for customers that are 21 and 51.” Truth: Design for all of your users and not some of your users who you understand. For the next 30 years we're going to be in this place where we're serving different generations, from different technologies, until we all are at a place where we all have adopted smartphones. ● “Our users need the tutorial for our web app.” Truth: Different users want to read to learn, while millennials just want to do trial-and-error. Ensure that application tutorials can be dismissed.
Testing Rationales ● “We don’t have to do usability testing at the beginning.” ● “There’s a problem we didn’t think of.” ● “Why would we test before we launch?” Truth: Formative and summative usability testing are different types of usability tests, and yield different types of user data. ● “Our navigation makes sense to all of the other librarians we asked.” ● “After the content audit we are seeing less help emails; we should make the help button even larger.” ● “Why would we perform a label audit?” Truth: Ultimately information architecture (IA) needs to make sense to your users, not just the content writers. IA should be tested regularly against user’s expectations. ● “We don’t test our emails and social media; that’s marketing not UX.” Truth: More businesses and organizations are moving to include a Chief Experience Officer (CXO) position because analytics, CX, UX, marketing, and social media deal with user data and research.
Writing Tests ● “We should test the data that we want to get back.” ● “Anyone can write user tests… anyone.” Truth: Usability test scripts should be reviewed by multiple UXers to ensure there is no bias, leading, and that test objectives align with stakeholder objectives. ● “If we’re going to recruit testers, let’s add more tasks to the test.” ● “Let’s stitch together a multifaceted test that tests a couple of different problems.” Truth: User can experience cognitive overload and their concentration can be taxed. Tests should be short and focus on details of a specific task for the best user data results.
From Developers ● “We can disable clicking enter on forms because people will click the buttons.” ● “Users don’t need affordances for buttons and links.” Truth: Just because a developer can do something (even as a workaround), doesn’t mean we should, or that it works for our users. ● “Don’t worry about running accessibility.” ● “Developer time is precious; they can’t be bothered” ● “Default HTML and CSS needs to be changed.” Truth: Developers need to be aware of user interactions and expectations. Default HTML/CSS meets the user’s understanding. ● “Web developers build with users in mind.” ● “Developers can start coding without prototypes.” ● “Developers use computers the same way our users do.” Truth: Developers aren’t our users.
When Prototyping ● “The prototype just needs to have one way for the user to complete the action.” Truth: Don't design prototypes that have a one-path solution or predetermined solution. Users will try to complete things in multiple ways. ● “We don’t need to worry about the other input fields on the page during the user test.” ● “Let’s see if the user completes the task the right way.” Truth: Don't construct a prototype to meet your own testing goals. This is winning the race but losing the war. ● “Let’s have the user test the current website against .JPG of the new design.” Truth: Don't use a static images or wireframes and compare it to a functional website. There are too many metrics and variables for accurate data. It’s like comparing golf balls to oranges.
Recruiting Participants ● “We only need to test our current customers.” Truth: When you test your own customers, you're not testing your competitors customers, and you're not getting a look at what you're not offering. ● “Remote user testing is all we need.” Truth: If you're going to an external panel or doing remote usability testing, you have to work really hard with screener questions to get the right participants. Otherwise you could get paid actors that articulate, but don't really represent your audience, or testers who are just filling out surveys and completing tests while they're watching TV (just trying to get credit). ● “We’ll give users free iPads if the sign-up to test!” Truth: It's important that the incentive for the users doesn’t alter or change their behavior by paying too much or too little.
A/B Tests ● “We have to A/B test everything.” ● “We don't have time to get user data, but we can run an A/B test.” Truth: A/B tests should be used in combination with other key performance indicators (KPIs), and not solely unto itself to make decisions. ● “We’re changing a couple of different variables with each optimization split.” ● “We can combine different optimization results together to see if we get a better result.” Truth: A/B tests only count clicks, not the effect on users minds, and should be informed by user data and research. ● “We don't need to track conversion loss… just gain.” Truth: Not tracking loss in A/B tests is a reckless behavior, and biases results to employers.
Conducting Tests ● “Don’t tell the user anything. We don’t want to bias them or know what they’re testing.” ● “Don’t lead the test participant.” ● “We don’t want the tester to know we are in dev.” Truth: Provide context to your testers. Explain to users what the test is about, if they're testing a prototype, and if they are in a development environment. ● “We need to read all of the legalese.” Truth: Don't take up too much of your valuable time by reading and not testing. ● “iPhones are the only devices we need to test for.” Truth: Let users test on their own devices, this way the have context, and they won’t be in an unfamiliar environment.
Remember The Following: Stakeholders: ● UXers are multiclass characters. ● Stakeholders dislike stabilizing, building the right way, and often prefer to opt for ‘quick wins’ (AKA triage). ● Stakeholders fear change and are risk averse. ● Stakeholders often have bad ideas, and your team maybe has staffing problems. ● Stakeholders can be difficult to work with.
Remember The Following: Users: ● Users appreciate clarity and saving time when they use your products. ● You need to observe and study your own users’ behavior to make successful decisions. ● Sometimes you need to ask your users questions to get answers. ● You are not your user. ● Every business or organization needs real data personas. ● Generational knowledge is real, as well as gaps in technology. ● Be aware of age gaps. ● Design for all of your users and not some of your users who you understand. ● Different users want to read to learn, while millennials just want to do trial-and-error.
Remember The Following: Testing: ● Formative and summative usability testing are different types of usability tests. ● IA needs to make sense to your users, ● Analytics, CX, UX, marketing, and social media deal with user data and research. ● Tests should have no bias, leading, and that test objectives align with stakeholder objectives. ● Tests should be short and focus on details of a specific task
Remember The Following: Developers ● Just because a developer can do something (even as a workaround), doesn’t mean we should ● Developers need to be aware of user interactions and expectations ● Developers aren’t our users. Prototypes: ● Don't design prototypes that have a one-path solution or predetermined solution. ● Don't construct a prototype to meet your own testing goals. ● Don't use a static images or wireframes and compare it to a functional website.
Remember The Following: Recruiting: ● Decide to test your customers or your non-customers. ● Screen participants ● Test incentives shouldn't change behavior. A/B Tests: ● A/B tests should be used in combination with other KPIs ● A/B tests only count clicks ● Not tracking loss in A/B tests is a reckless
Remember The Following: Conducting Tests: ● Provide context to your testers. ● Don't take up too much of your valuable time by reading and not testing. ● Let users test on their own devices
timbroadwater
drumath2237
uzulla
aiji42
korodroid
oogfranz
safie_recruit
miura55
motok1
line_developers_tw
sattosan
toshiaizawa
chiroruxx
danielanewman
revolveconf
caitiem20
kneath
skipperchong
dotmariusz
addyosmani
brianwarren
jrom
akmur
pauljervisheath
lara