1. UX is ... a person’s perceptions and responses that result from the use or anticipated use of a product, system or service.
2. Elements
2.1. Focus should be on 20% of the product that provides 80% value. Essential part of the product should be exceptional, rest could be acceptable.
2.2. Findability
2.2.1. Search engine strategy
2.2.2. Marketing
2.2.3. Brand management
2.2.4. Naming
2.2.5. Word of mouth
2.3. Utility (Usefulness)
2.3.1. Appropriate for purpose
2.3.2. Expected functionality
2.3.2.1. Ensure the suitability of a task
2.3.3. Expected information
2.3.3.1. Focus on information of interest to users, not on the things you want to promote
2.3.3.2. Communicate immediately at the top of the page that your content is indeed interesting and useful to users
2.3.4. Uniqueness
2.3.5. Differentiation
2.4. Usability
2.4.1. Usability is ... the extent to which a system, product or service can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.
2.4.2. "Nowadays acceptance for bad Usability decreases permanently"
2.4.3. Usability experts prioritize the problems with impact to the user, product managers prioritize with impact to the achieved result
2.4.4. Learnability
2.4.4.1. Simple things should be simple, complex things should be possible.
2.4.4.2. In most products, consumers value practicality and simplicity over abstract concepts and emotional obstacle courses.
2.4.4.3. Choose appropriate UI patterns
2.4.4.4. Strive for consistency
2.4.4.4.1. “users spend most of their time on other websites than your site.”
2.4.4.4.2. “The most important consistency is consistency with user expectations”—William Buxton
2.4.4.4.3. Use standards
2.4.4.4.4. Use signifiers
2.4.4.4.5. Over time, strive for continuity, not consistency
2.4.4.4.6. Adhere to Gestalt Principles
2.4.4.4.7. UI Text Styleguide
2.4.4.4.8. UI Text Standard
2.4.4.4.9. Konsistenz mit der Plattform
2.4.4.4.10. Konsistenz mit früheren Versionen
2.4.4.4.11. Konsistenz mit Marke
2.4.4.5. If your way offers no clear advantage, go with what your users expect
2.4.4.6. Use affordances
2.4.4.6.1. Things that are not only designed to do something, but that are designed to look like they are designed to do something. A button that looks like a physical object you can push, for example, is an affordance designed so that someone unfamiliar with the button will still understand how to interact with it.
2.4.4.7. Use animated transitions
2.4.4.7.1. The user feels time passing faster than it does
2.4.4.7.2. Acceleration of animation makes its duration feel shorter
2.4.4.8. Use Active Discovery to guide people to more advanced features
2.4.4.8.1. Progressive Revelation
2.4.4.9. Group 5-9 elements
2.4.4.10. Give feedback
2.4.4.11. Dopamine from positive emotions improves learnability
2.4.5. Efficiency
2.4.5.1. Enterprise software: It has to be designed not for 'understanding', but for rapid repeated actions.
2.4.5.2. Performance
2.4.5.2.1. Waiting times
2.4.5.2.2. Time to complete a task
2.4.5.2.3. Look at the user’s productivity, not the computer’s
2.4.5.3. Navigation
2.4.5.3.1. Wo bin ich?
2.4.5.3.2. Woher komme ich?
2.4.5.3.3. Wohin kann ich gehen?
2.4.5.3.4. Warum sollte ich da hingehen?
2.4.5.3.5. Consider Fitts' Law
2.4.5.3.6. Ensure controllability
2.4.5.3.7. Ensure self-descriptiveness
2.4.5.3.8. Smartphone: Consider the thumb zone
2.4.5.3.9. Touch: Adhere to minimal element sizes
2.4.5.3.10. Filter: Do not refresh too soon
2.4.5.3.11. Smartwatch: Use well-known gestures
2.4.5.4. Cognitive Workload
2.4.5.4.1. “The trick is to find the middle ground—the ‘sweet spot’—that enables people to benefit from variety and not be paralyzed by it. Choice is good, but there can be too much of a good thing.”—Barry Schwartz
2.4.5.4.2. Emphasize the Call To Action (CTA)
2.4.5.4.3. Eleminate unnecessary features and then hide what you can't eliminate
2.4.5.4.4. Make the impact area of actions clear
2.4.5.4.5. If the user cannot find it, it does not exist
2.4.5.4.6. Reduce elements
2.4.5.4.7. Reduce the need of interactions
2.4.5.4.8. Keep users in autopilot mode
2.4.5.4.9. Chunk in 4 parts
2.4.5.4.10. Categorize well
2.4.5.4.11. Reduce choices
2.4.5.4.12. Reduce Opportunity Costs
2.4.5.4.13. Keep the expected work load low
2.4.5.4.14. Assess task load with NASA TLX
2.4.5.4.15. Smartwatch: Avoid complex inputs
2.4.5.5. Readability
2.4.5.5.1. Make text size changeable
2.4.5.5.2. Use short sentences
2.4.5.5.3. Write in active voice
2.4.5.5.4. Smartphone: Show most important info on the top 2-screen-heights
2.4.5.6. Comprehension
2.4.5.6.1. Use an inverted-pyramid writing style
2.4.5.6.2. Use pictures
2.4.5.6.3. Build on existing mental models
2.4.5.6.4. Standardize dialog texts
2.4.5.6.5. Overview first, zoom and filter, then details-on-demand
2.4.5.7. Individuality
2.4.5.7.1. Allow Individualization
2.4.5.8. Device inertia
2.4.5.9. Momentum behavior
2.4.5.10. Selective attention
2.4.6. Errors
2.4.6.1. Error messages should actually help
2.4.6.2. Ensure that users never lose their work
2.4.6.3. Offer error tolerance
2.4.7. Memorability
2.4.7.1. Use metaphors
2.4.7.1.1. Choose metaphors that will enable users to instantly grasp the finest details of the conceptual model
2.4.7.1.2. Do Icon Testing
2.4.7.2. Use a new object when you want a user to interact with it in a different way or when it will result in different behavior
2.4.7.3. Offer users stable perceptual cues for a sense of “home”
2.4.7.4. Try making your concepts visually apparent in the software itself
2.4.8. Accessibility
2.4.8.1. Content / presentation separation
2.4.8.2. WCAG-2 /section 508 compliance
2.4.8.3. Standard compliance
2.4.8.4. Browser compatibility
2.4.8.5. Response time
2.4.8.6. Besides colors, use secondary cues
2.4.9. Satisfaction
2.4.9.1. Use priming
2.4.10. Consider the Kulturmodell von Hofstede
2.5. Joy of Use
2.5.1. Aesthetics
2.5.1.1. "It has been shown that perceived aesthetics has a correlation with the perceived usability"
2.5.1.2. Senkt Stresspegel und vermindert Fehler
2.5.1.3. Why does one choose to use Gmail over Yahoo, Medium over Blogger — if the features are 99% the same? It’s definitely not about disrupting usability standards. It’s about that additional layer of sophistication that can only be achieved when you put enough time and brainpower into the tiniest details, the most subtle animations, the most elegant transitions – not just for the sake of creating whimsical dribbble shots.
2.5.1.4. Graphic elements
2.5.1.5. Colorscheme and contrast
2.5.1.6. Typography
2.5.1.7. Flat Design 2.0
2.5.1.8. Media use
2.5.1.9. Don't overshoot: Life is a much more stressful and demanding environment than an app’s delights and subtle effects.
2.5.2. Innovation
2.5.3. Challenge
2.5.3.1. Rewards
2.5.3.1.1. Use rewards for hardest tasks
2.5.3.1.2. Loading Screens
2.5.3.1.3. 404 pages
2.5.3.1.4. Case studies
2.5.4. Credibility
2.5.4.1. Verifyability
2.5.4.2. Prove with Community
2.5.4.3. Conformity
2.5.4.4. Tone of voice
2.5.4.4.1. Use good copy
2.5.4.5. Trustworthiness
2.5.4.5.1. Make clear what you will store & protect the user’s information
2.5.4.5.2. Sei supernett
2.5.5. Exclusivity
2.5.5.1. Symbolism
2.5.5.1.1. Gruppenzugehörigkeit
2.5.5.1.2. Status
2.5.5.2. Hedonic Quality
2.5.6. Positive Emotionen erhöhen Anwendungserfolg
3. Phases
3.1. http://practicaluxmethods.com/
3.2. Research
3.2.1. Die Gestaltung basiert auf einem umfassenden Verständnis der Benutzer, Arbeitsaufgaben und Arbeitsumgebungen
3.2.2. Das Gestaltungsteam vereint fachübergreifende Kenntnisse und Gesichtspunkte
3.2.3. Landscape
3.2.4. Generate ideas
3.2.4.1. 635 Method
3.2.4.2. Braindumping
3.2.4.3. Brainstorming
3.2.4.4. Passt die Idee zu unseren Zielen?
3.2.4.4.1. Hilft uns die Idee dabei unsere Geschäftsziele zu erreichen?
3.2.4.5. Ist die Idee organisatorisch machbar?
3.2.4.5.1. Stehen die notwendigen Ressourcen und das notwendige Know-how zur Verfügung?
3.2.4.6. Ist die Idee wirtschaftlich machbar?
3.2.4.6.1. Sind die erwarteten Erträge höher als die Aufwände für Forschung und Entwicklung? Können die notwendigen Mittel beschafft werden?
3.2.4.7. Ist die Idee zeitlich machbar?
3.2.4.7.1. Kann das Produkt innerhalb eines nützlichen Zeitrahmens entwickelt werden? Beispielsweise auf ein wichtiges Marktereignis hin?
3.2.4.8. Ist die Idee technologisch machbar?
3.2.4.8.1. Stehen die notwendigen Technologien für die Entwicklung eines solchen Produkts zur Verfügung?
3.2.4.9. Ist die Idee rechtlich machbar?
3.2.4.9.1. Gibt es Patente, Normen oder Vorschriften, welche es unmöglich machen, ein solches Produkt auf den Markt zu bringen?
3.2.5. Sort
3.2.5.1. Card Sorting
3.2.5.2. Affinity Diagramming
3.2.5.3. OO Analysis
3.2.5.4. Use cases
3.2.5.4.1. Abgeschlossene Handlung mit sichtbarem Resultat
3.2.5.4.2. Aufbau eines Use Case
3.2.5.4.3. Scenarios
3.2.5.4.4. Use case slices
3.2.5.4.5. UML use case diagram
3.2.5.4.6. UML sequence diagram
3.2.5.5. Entity-Relationship-Modelle
3.2.5.5.1. Methode zum Entwurf eines semantischen Dantemodells
3.2.5.5.2. Mehrwertige Attribute haben eine Dopelllinien-Umrandung
3.2.5.5.3. Abgeleitete Attribute haben eine gestrichelte Umrandung
3.2.5.5.4. Zusammengesetzte Attribute gliedern sich in Unterattribute
3.2.5.5.5. Kardinalitäten
3.2.6. Prioritize
3.2.6.1. Impact and Story Mapping
3.2.6.2. MoScoW Method
3.2.6.2.1. Must
3.2.6.2.2. Should
3.2.6.2.3. Could
3.2.6.2.4. Won't
3.2.6.3. Action Priority Matrix
3.2.6.4. Business Value
3.2.6.4.1. Turnover
3.2.6.4.2. Savings
3.2.6.5. Define Relevance (Kano)
3.2.6.5.1. Basis-Merkmal
3.2.6.5.2. Leistungsmerkmal
3.2.6.5.3. Begeisterungsmerkmal
3.2.6.5.4. Unerhebliches Merkmal
3.2.6.5.5. Rückweisungsmerkmal
3.2.6.6. Top task analysis
3.2.7. Observe/Understand
3.2.7.1. Start by not being a stakeholder!
3.2.7.2. Process Mapping
3.2.7.3. Hypothesis Testing
3.2.7.3.1. "Declaring our assumptions up front and testing those that present the highest risk are key steps in defining the problems a product or service team must solve"
3.2.7.3.2. “It’s healthy, but rare, for a team to be able to list out their assumptions, so the team can determine what questions they need to ask along the way to better define needs as part of user understanding, as well as discover insights that inform product and service design"
3.2.7.3.3. 1. Have a conversation and list out everyone’s assumptions.
3.2.7.3.4. 2. Determine how you can turn those assumptions into questions.
3.2.7.3.5. 3. Have the team map their questions to research approaches that would enable the team to discover answers and validate or challenge specific assumptions.
3.2.7.3.6. 4. Through greater user understanding, determine whether these assumptions lead to other assumptions that may provide additional questions that would lead to further discovery over time.
3.2.7.3.7. Have a hyptohesis testing phase before implementation (e.g. in Scrum a permanent Pre-Sprint)
3.2.7.4. Survey
3.2.7.4.1. Halte Umfragen kurz
3.2.7.4.2. Behindert dich irgendetwas darin, deine Arbeit zu erledigen?
3.2.7.4.3. Was würde dir helfen, produktiver zu sein?
3.2.7.4.4. Gibt es einen Bereich deines Jobs, in dem du dir mehr Unterstützung wünscht?
3.2.7.4.5. Gebe Feedback
3.2.7.5. Interview
3.2.7.5.1. O'Reilly Webcast: Interviewing Users - Uncovering Compelling Insights
3.2.7.5.2. Bedürfnisse hinter Lösungen erkennen
3.2.7.5.3. Glaube nicht, dass Kunden immer alles wissen
3.2.7.5.4. Hinterfrage Prozesse immer
3.2.7.5.5. Nutze Forschungsdaten um Aussagen zu hinterfragen
3.2.7.6. A Day in the Life
3.2.7.6.1. Understand what their current tools are, how they organise their workspace, what their frustrations are and what they’d like to improve. Involve them in the product ideation. By doing that, they’ll bring a huge amount of knowledge to the table and they’ll naturally transition towards the new tool you’re designing for them
3.2.7.7. Requirements elicitation
3.2.7.7.1. Automated Requirements Elicitation
3.2.7.8. The Problem Brief
3.2.7.8.1. 1. Problem Space
3.2.7.8.2. 2. Goal Space
3.2.7.8.3. 3. Consequence
3.2.7.8.4. 4. Gaps and Barriers
3.2.7.9. Focus groups
3.2.7.10. Customer Journey Map
3.2.7.10.1. Epic
3.2.7.10.2. Storyboard
3.2.7.10.3. Personas
3.2.7.11. Develop empathy with stakeholders
3.2.7.12. Diary studies
3.2.7.13. Analytics report
3.2.7.13.1. Lead Users
3.2.7.13.2. Extreme Users
3.2.7.14. Why? Not what!
3.2.7.15. Mental models
3.2.7.15.1. Logik, die erklärt, wie Dinge funktionieren und wie diese verknüpft sind
3.2.8. Competetive analysis report
3.2.9. Conjoint Analysis
3.2.10. Contextual Inquiry
3.2.11. Presumptive Design
3.2.12. Content Audit
3.2.13. Define KPIs with target values
3.2.14. Define Output, Outcome and Impact
3.2.14.1. It would be better to instead measure progress in terms of new organizational behaviors created by their work.
3.2.14.2. For example, what is the ratio of users of the new system vs the old system? How many of those users are able to use a new business process as a result of the initiative? Are the new business processes unlocked by this initiative ones that in turn generate positive outcomes?
3.2.14.3. Instead of planning for some mythical “feature-complete” future state (remember, software is never complete), they can plan to deliver value early, then enhance that value through continuous, incremental delivery.
3.3. Design
3.3.1. Umso mehr Artefakte, desto bessere Ergebnisse
3.3.2. Unterstützt dies den Benutzer wirklich?
3.3.3. Do not create alternatives
3.3.3.1. You are the professional and you should be able to justify all your decisions in the one option you have created.
3.3.4. BRDs
3.3.4.1. Write user stories
3.3.4.1.1. Abgestimmt
3.3.4.1.2. Eindeutig
3.3.4.1.3. Notwendig
3.3.4.1.4. Konsistent
3.3.4.1.5. Prüfbar
3.3.4.1.6. Realisierbar
3.3.4.1.7. Verfolgbar
3.3.4.1.8. Vollständig
3.3.4.2. Write in MVP chains
3.3.4.2.1. Merkmal
3.3.4.2.2. Vorteil
3.3.4.2.3. Persönlicher Kundennutzen
3.3.4.3. Consider all interfaces
3.3.4.4. Consider exceptions
3.3.4.5. Separate business from technical solutions
3.3.4.5.1. Do not describe solutions
3.3.4.6. Add test cases ("branch coverage")
3.3.4.7. Consider Model Driven Architecture
3.3.4.8. Add Business Case
3.3.4.8.1. 1. An honored rule of thumb is to take their hourly wage and multiply it by three to include all the other overhead associated with an employee, from rent to heat, lights, computer support, etc.)
3.3.4.8.2. 2. Multiply the overhead cost x the number of affected employees x the time an activity takes x the difference in productivity, positive or negative, in carrying out the activity to find the actual cost of a change.
3.3.4.8.3. 3. A positive number will help you sell your group and your design. A negative number will help your company from making a costly mistake.
3.3.4.9. Exclude special user stories, if necessary
3.3.4.10. Nicht-funktionale Anforderungen
3.3.4.10.1. FURPS
3.3.4.11. Consider quality metrics
3.3.4.11.1. Eindeutigkeit und Konsistenz
3.3.4.11.2. Klare Struktur
3.3.4.11.3. Modifizierbarkeit und Erweiterbarkeit
3.3.4.11.4. Vollständigkeit
3.3.4.11.5. Verfolgbarkeit (Traceability)
3.3.5. Mockups
3.3.5.1. Only do mockups if its worth it
3.3.5.2. Schränken bereits etwas den Horizont ein
3.3.5.3. Avoid too sophisticated and hence distracting tools
3.3.6. Co-Creation
3.3.6.1. We tend to think that most of the users are like us.
3.3.6.2. Work with your colleagues beforehand
3.3.6.3. Users are involved in design and development
3.3.6.4. Nicht nur Ihre Mitarbeiter sollten fachübergreifend zusammenarbeiten. Auch Ihre Kunden sind wertvolle Ideengeber und sollten darum unbedingt in den Ent- wicklungsprozess einbezogen werden.
3.3.7. Consider the Elements of UX
3.3.7.1. Bei der Gestaltung wird die gesamte User Experience berücksichtigt
3.3.8. Design Studio
3.3.8.1. Generating lots of ideas
3.3.8.2. Giving the whole team—and/or users—a voice in the design process
3.3.8.3. Getting noncreative stakeholders to empathize with design challenges
3.3.9. Wireframes
3.3.9.1. Ensures Focus
3.3.10. Prototypes
3.3.10.1. Paper
3.3.10.2. Interactive
3.3.10.3. "The best way of having a good idea is having a lot of ideas"
3.3.11. Flowchart
3.3.12. Sitemap
3.3.13. Five Dimensions
3.3.13.1. 1D: words should be simple to understand, and written in such a way that they communicate information easily to the end user.
3.3.13.2. 2D: visual representations are all graphics or images, essentially everything that is not text. They should be used in moderation, so as to not overwhelm.
3.3.13.3. 3D: physical objects or space refers to the physical hardware, whether it’s a mouse and keyboard, or a mobile device a user interacts with.
3.3.13.4. 4D: time is the length that the user spends interacting with the first three dimensions. It includes the ways in which the user might measure progress, as well as sound and animation.
3.3.13.5. 5D: behavior was added by Kevin Silver in his article, What Puts the Design in Interaction Design. It is the emotions and reactions that the user has when interacting with the system.
3.3.14. Follow your Design Strategy
3.3.14.1. Designprinzipien helfen Entscheidungen zu treffen
3.3.14.2. Designprinzipien öffentlich machen
3.3.15. Galeriemethode
3.3.16. Styleguide
3.4. Evaluation
3.4.1. Internal
3.4.1.1. Ein Experte deckt statistisch betrachtet gerade mal 25% aller Probleme auf, wogegen drei Experten bereits über 70% der Probleme identifizieren (Nielsen, 1992)
3.4.1.2. Internal Survey
3.4.1.3. Internal Review
3.4.1.3.1. Wer da ist ist da, wer nicht da ist stimmt zu
3.4.1.3.2. Keine Rückmeldung ist Zustimmung
3.4.1.4. Feedback Workshop
3.4.1.4.1. Feedback Matrix
3.4.1.5. Inspection
3.4.1.5.1. ISO Standards
3.4.1.5.2. The mother of all usability checklists
3.4.1.5.3. Psychological Usability Heuristics
3.4.1.5.4. Nielsen Heuristiken (1994)
3.4.1.5.5. Enhanced Nielsen Heuristics
3.4.1.5.6. Quinones D. - Heuristics for transactional web apps (2014)
3.4.1.5.7. Style guides (own or external)
3.4.1.5.8. Usability Heuristics for transactional web sites
3.4.1.5.9. Usability Checklist (Web)
3.4.1.5.10. Gestural Heuristics
3.4.1.6. Whiteboard
3.4.1.7. Daily Scrum
3.4.1.8. Expert Review
3.4.1.9. Meeting Minutes
3.4.1.10. Cognitive Walkthrough
3.4.1.10.1. Untersucht hauptsächlich Erlernbarkeit
3.4.1.10.2. Annahme, dass der Benutzer immer den kognitiv einfachsten Weg wählt
3.4.1.11. Hallway Test
3.4.1.12. Heuristic Markup
3.4.1.13. Comparative Assesssment
3.4.2. External
3.4.2.1. Survey
3.4.2.1.1. AttrakDiff
3.4.2.1.2. IsoMetrics
3.4.2.1.3. Nach Kano
3.4.2.1.4. Single Ease Questions (SEQ)
3.4.2.1.5. System Usability Scale (SUS)
3.4.2.1.6. Free & Beautifully Human Online Forms | Typeform
3.4.2.2. User Testing
3.4.2.2.1. Das Verfeinern und Anpassen von Gestaltungslösungen wird fortlaufend auf der Basis benutzerzentrierter Evaluierung vorangetrieben
3.4.2.2.2. Guerilla Testing
3.4.2.2.3. validately.com
3.4.2.2.4. usabilityhub.com
3.4.2.3. Interview
3.4.2.4. Customer Meeting
3.4.2.5. A/B Testing
3.4.2.6. Observation
3.4.2.6.1. Complete Observer
3.4.2.6.2. Observer as Participant
3.4.2.6.3. Participant as Observer
3.4.2.6.4. Complete Participant
3.4.2.7. Google Analytics
3.4.2.8. Feedback System
3.4.2.8.1. Usabilla
3.4.2.8.2. Get Satisfaction
3.4.2.9. Heatmaps
3.4.2.10. Experiment
3.4.2.11. GOMS
3.4.3. Summarize
3.4.3.1. Discussion
3.4.3.2. Documentation/Wiki
3.4.3.3. Decision of Next Step
3.4.3.4. RoadMap
3.4.4. Establish Data-Driven Success
3.4.5. Check KPIs
3.5. Der Prozess sieht Iterationen vor
3.5.1. „Die geeignetste Gestaltung für ein interaktives System kann normalerweise nicht ohne Iteration erreicht werden.“
3.5.2. Menschzentrierte Gestaltungsaktivitäten
4. Effects
4.1. Better product
4.1.1. Increased customer satisfaction and loyalty
4.1.1.1. This is extremely difficult to measure, and should be used as a primary cost justification only in extreme cases. That said, one method of measuring customer loyalty is in terms of customer retention. (Important especially in organizations that know when their customers are most likely to defect to a competitor or a more mature product offering.) The calculation takes into account the cost of new customer acquisition and amortizes the cost over the average customer retention period. Increasing average customer retention is a cost savings for the company, and can cost justify UX & usability work related to customer loyalty. The metrics of success will come from sales and marketing.
4.1.2. Deeper insights
4.1.3. Revenue boost
4.1.3.1. Either incremental revenue from add-ons or through an easier sales process, which is typically called "conversion rate" though that often gets mixed up with "website conversions". The metrics for this are typically found in the sales and finance department. Coupled with the estimated costs of usability testing and UX development, you'll be able to work out over what timeframe it will take for the UX work to pay for itself.
4.1.4. Increased retention
4.1.5. Recommendations more likely
4.1.6. Decreased stress level
4.1.6.1. Stress => schnell, aber hohe Fehlerquote
4.2. Reduced costs
4.2.1. Reduced cost of late correction
4.2.2. Reduced training and support costs
4.2.2.1. If customers generate calls or support tickets or other uncompensated overhead costs to the business, then those costs should be measured. The easiest way to do this is how airlines handle the it. When a passenger, for example, calls an agent to check flight status, the airline knows how long that call will last, and based on the average cost/minute for phone agents (including salary, benefits, and overhead like the phone line, office space, electricity, etc), the airline can assign a $ value to the cost of the call. Because airlines handle large volumes of calls every day, if there is an increase of 2500 check flight status calls/day at a cost of $2.00/call (theoretical cost!), then we could expect that would increase uncompensated support costs by $5,000/day. If the airline wanted to do a $50,000 eye tracking usability study to get that number down to 1225 calls/day (assuming a clean 50% improvement), then that usability study would pay for itself in 20 days.
4.2.2.2. Be wary in cases where training and support are part of the company's core business model - otherwise it doesn't make sense to decrease these costs, (i.e., if the company's revenues are earned from consulting)
4.2.3. Increased productivity
4.2.3.1. Most often found when there are large pools of employees completing certain repetitive tasks. Metrics are found in operations, HR, and finance (for overhead items like office space, equipment, etc.) For example, if you optimize the UX on a series of screens so that what was once a 5 minute task is now a 2.5 minute task, then you've increased a person's productivity by 100%. That's huge. HUGE. If the company has 100 phone agents who have an average salary of $40,000 + benefits (~$8,000) (+ an unknown amount for overhead), you could either release or retask those agents on other activities with a savings of $2,4000,000/year. (half of 100 agents x $48,000)
4.2.4. Reduced code maintenance
4.3. Less risk
4.3.1. Reduces the risk of building the wrong thing
4.3.1.1. Though folks who make product decisions often claim an empirical approach to product work is unnecessary, it was found they cannot predict the results of A/B tests, which sort of puts the lie to their claim.
4.3.1.2. Or a PO (or someone higher up) takes requests from user groups, stores them in a backlog, and the focus is kept on work completion
4.3.2. Projects fails without happy users
4.3.2.1. 70% fail because not accepted by the user
4.4. Faster development
4.4.1. Avoids rework
4.4.1.1. Again, this is a function of the number of developers needed to complete project work. Bad UX is often a reflection of poor design and complexity in the underlying code. A hallmark of good UX is the elimination of unnecessary or marginal features. This reduces the complexity of the code base, making it more robust and less buggy. As a wise man once said, "there are no bugs in the code you don't write."
4.4.2. Reduces Development time
4.4.2.1. Measured in terms of development resources and time to market. For example, if moving to a system with design patterns and object oriented CSS will decrease the need for an additional UX hire and 5 developer hires (a reasonable ratio), then that's a cost savings of all of those non-hires salaries + benefits + overhead (computers, software, office space, desk, etc). Similarly, if a strong UX framework decreases the development time from 6-months to 3-months for a project that will increase revenues by $100k per month, then bringing the project to market 3 months early adds $300k to this year's revenues.
4.4.3. UI is major part of Dev Phase
4.4.4. Better ability to deliver to deadline
4.4.5. Reduced development waste
4.5. Higher ROI
4.5.1. Always estimate ROI in terms of annual dollars
4.5.1.1. Of course, all of these increases/savings must be compared to the costs associated with UX, usability, and development endeavors. I recommend that all metrics be stated in the terms of increases/decreases over the course of a year - annualized costs - because that’s a term the folks in budgeting will understand, and a dollar amount that provides the most realistic impact. (Not too much, not too little.) So, if your project is designed to increase revenue by 20% on a million dollar revenue stream, then the dollar amount should be reported as "$200k annually."
4.5.2. Companies focusing on UX peform better than their peers
4.5.3. Spend 10% to get 83%
4.6. Sell UX
4.6.1. Show horror video clips from usability test sessions to executives.
4.6.2. Don't talk about theoretical effects, show them results in your own area.
4.6.3. Start with ...
4.6.3.1. Management
4.6.3.2. Corporate Vision
4.6.3.3. R&D
4.6.3.4. Product Development Process
4.6.3.4.1. Is there time for user research?
4.6.4. Capture your audience’s attention—using emotion versus logic.
4.6.5. Hold your audience’s attention and maintain their interest.
4.6.6. Understand what benefits a company wants from UX.
4.6.7. Move senior leaders to a favorable action—an offer.
4.6.8. What Sells?
4.6.8.1. Positive emotion
4.6.8.2. simple UX tools everybody can understand
4.6.8.3. listening
4.6.8.4. case studies
4.6.9. What doesn't sell?
4.6.9.1. Representing UX as the only answer
4.6.9.2. Relying too much on ROI arguments
4.6.9.3. Using UX jargon