Your SlideShare is downloading. ×
0
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Mobile application usability audit
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Mobile application usability audit

1,334

Published on

This is a rapid usability audit we conducted for a client's first stab at a mobile app. We took a hybrid approach, using heuristic evaluations a cognitive walkthrough, with the goal of discovering top …

This is a rapid usability audit we conducted for a client's first stab at a mobile app. We took a hybrid approach, using heuristic evaluations a cognitive walkthrough, with the goal of discovering top usability issues and making recommendations. Nielsen and Molich originally thought of heuristic evaluations as a "discount method" to get quick on user interfaces; we found that that, plus the cognitive process, returned solid knowledge in a short time frame.

Published in: Design, Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,334
On Slideshare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
0
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. "FLICK DAT" USABILITY AUDIT5544 Lawton Ave, Oakland CA • telephone: 415.606.4811 • www.twoa ngstr oms. c om5544 Lawton Ave. Oakland, CA 94618T 415.606.4811ddt@twoangstroms.com www.twoangstroms.comDANIEL DREW TURNER
  • 2. Report OverviewWith the goal of helping streamline the iterative development of Flick Dat, we conducted a usability review of the currentbuild (v. 1.0.3). The goal was discover how users prioritized features of the app and major pain points in the current in-formation architecture. Its our hope that this work can help expedite the imminent redesign of the app.This is a subset of the originally planned report, and so is not a deep dive nor a complete review of the app. We did notreview all features of the app, nor did we evaluate all areas of it. We focused on two of the necessary tasks that users mustundertake to get any value out of the app.This review consisted of two phases:1. Pre-Evaluation Survey2. Usability Audit and Heuristic EvaluationThis report outlines the findings of our review.Research assistance provided by Corinne Longman and Loe Lee.C lient: Damon Wayans and Aniya Productions. Inc.3
  • 3. ParticipantsWe immediately began surveying potential app users to collect demographic data and insights on how people share busi-ness cards, their goals in doing so, and what they do with the cards and information once the cards are shared. We at-tended a range of professional events in San Francisco Bay Area and handed out 20-question surveys, screening for peo-ple who regularly faced the problem of card sharing and a balance of those who have a system for dealing with it andthose who did not. We received back 12 completed surveys, which we felt was a representative sample for discovery.All of our survey respondents have and exchange business cards. Multiple people said they did so at professional meetupsand networking events. conferences, meetings, and talks; some unique responses were "dinners", "troubleshooting situa-tions", "drinks", and "when appropriate". What we learned from this was that business card exchanges usually take placein public situations, with distractions, and some time limitations and pressures.The question "What do you do with the cards?" was intentionally vague, and returned some interesting answers. Half therespondents said that they contact people, two said "nothing", and a third of respondents replied along the lines thatC lient: Damon Wayans and Aniya Productions. Inc.3
  • 4. they just toss the cards on their desk or put them in a drawer. This speaks to a real confusion about how to deal withbusiness cards, despite intentions.Almost all iOS users said that they do not put business contacts into their iOS Contacts list, or maintain multiple contactlists.However, the majority of respondents indicated that they use business card exchanges to initiate connections with peo-ple on social and professional networks. LinkedIn was the leader (7), Twitter second (5), and Facebook last (1). This couldrepresent LinkedIns use as a job-seeking service, but this is not conclusive. But easy connections to social and profes-sional networks would seem to be a desirable feature.When asked what the most important data fields in a business card, respondents replied name (12), email (7), phone (4),social media (4). The low number on the last does not contradict the above; we have personal experience that name andemail is enough to easily connect with people on professional and most social networks.C lient: Damon Wayans and Aniya Productions. Inc.3
  • 5. For the heuristic evaluation, we took a subset of survey respondents. This is standard practice; heuristic evaluations,conducted with professional guidance, can provide vital insights into pain points and areas to improve with a small usersample (see "Methodology"). We attempted to balance these evaluators between those who had used or do use an app formanaging and/or sharing business card information, though we found the it difficult to find many who had. (Its incon-clusive at this scale whether this represents a market need for Flick Dat or poor penetration of this kind of app, includingcompetitors.)C lient: Damon Wayans and Aniya Productions. Inc.3
  • 6. MethodologyIn the usability audit, we collected usage/behavioral data through a hybrid approach, combining cognitive walkthroughswith heuristic evaluation methods. This approach take the following steps:1. Define the users and their goals2. Define the tasks they would attempt3. Walk through the tasks step-by-step through the lens of the user (what terms they use, the things theyd look for andlikely paths theyd take)4. Look for and identify problems based on a set of heuristic criteria5. Specify where in the interface the problem is, how severe it is and possible design fixesThis methodology is known to return actionable results with a limited time and sample. The goal is to uncover and rateusability issues as to their impact on user actions and attachment to and acceptance of the app being evaluated.Task assignment:We gave the users two tasks to complete. These tasks were core functionalities of the Flick Dat app: all users would needto perform these tasks, and these tasks would be among the most common tasks performed.Task 1: Add/Remove a Field on a CardTask 2: Share a CardAs is standard in a usability testing situation, we did not offer solutions unless a user was stuck to the point of giving up,we encouraged users to "talk aloud", and we recorded facial and bodily expressions of happiness and frustration. A fullusability test of the app would extend to more tasks, more users, and offer more detailed feedback on each user and sys-tem action.C lient: Damon Wayans and Aniya Productions. Inc.3
  • 7. Modified HeuristicsAfter Nielsens 10 heuristics and later work in the field, we chose a modified set of heuristics, specifically focused on theneeds of mobile applications and users. Using this lens, we can better categorize user pain points and offer better rec-ommendations for design iterations.Visibility of system status: The system should always keep users informed about what is going on, through appro-priate feedback within reasonable time. Match between system and the real world: The system should speak the users language, with words, phrasesand concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making informa-tion appear in a natural and logical order.User control and freedom: Users often choose system functions by mistake and will need a clearly marked "exit" toleave the unwanted state without an extended dialogue. Supports undo and redo and a clear way to navigate.Consistency and standards: Users should not have to wonder whether different words, situations, or actions meanthe same thing. Follow platform conventions.Error prevention: Even better than good error messages is a careful design, which prevents a problem from occurringin the first place.Recognition rather than recall: Minimize the users memory load. Make objects, actions, and options visible. Theuser should not have to remember information from one part of the dialogue to another. Instructions for use of the sys-tem should be visible or easily retrievable whenever appropriate.C lient: Damon Wayans and Aniya Productions. Inc.3
  • 8. Flexibility and efficiency of useAesthetic and minimalist designHelp users recognize, diagnose, and recover from errors: Error messages should be expressed in plain lan-guage (no codes), precisely indicate the problem, and constructively suggest a solution.Help and documentationC lient: Damon Wayans and Aniya Productions. Inc.3
  • 9. Task 1: Add/Remove Field on a CardC lient: Damon Wayans and Aniya Productions. Inc.3Step 1-2:Users expected iOS-standard "swipe left" to deletefield. Many attempts, frustration.Recommendation: Use iOS standard controlSeverity: HighHeuristic Principle: Consistency and Standards"Back" button gives error message, destroys userdata. Stress!Recommendation: Save user action by defaultSeverity: HighHeuristic Principle: User Control and FreedomUsers had trouble getting to "Card Edit" page --"Edit" button contrast is low.Recommendation: use iOS standard. Better: see"Task 1: Recommended Changes"Severity: MediumHeuristic Principle: Recognition Rather than RecallUsers overwhelmingly failed to find the "left touch"area to add a field. Fail state.Recommendation: Save user action by defaultSeverity: SevereHeuristic Principle: Recognition Rather than Recall
  • 10. C lient: Damon Wayans and Aniya Productions. Inc.3Step 3:"Save as" screen title does not match task or user expecta-tions (or iOS standard phrasing). Confused users.Recommendation: Test phrasing that better matches usertask (e.g., "Add field").Severity: LowHeuristic Principle: Match Between System and the RealWorldIf user "touched left" an already populated field, and thenselected a different field name in this screen, that data ismoved to this field name, no system indication, not useexpectationRecommendation: Do not show existing card fields onthis "Fields" screenSeverity: HighHeuristic Principle: Error Prevention, Match BetweenSystem and Real World"Back" behaves differently in same context: goes to card Editpage here, but "Back" in Edit page leaves and destroyschanges; confounds user learningRecommendation: different names for "Back"Severity: MediumHeuristic Principle: Error Prevention, User Control and Free-domSelecting a field that already does nothing, wastes useraction. Users showed confusion and irritation.Recommendation: Do not show existing card fields on this"Fields" screenSeverity: MediumHeuristic Principle: Match Between System and Real World
  • 11. C lient: Damon Wayans and Aniya Productions. Inc.3Step 4: Touch in last screen switchingscreen back to "Edit" screen,confused usersRecommendation: see largerrecommendation about iOSstandard add/edit list behaviorSeverity: LowHeuristic Principle: Recoverfrom Errors, Consistency andStandards, User Control(after touching"Job" in last screen)Touching "Save" with no text returnserror message "Please add title to allfields". Users confusing: Unclear what"title" means or how doing some-thing to "all fields" relates to useraction. It confused us, too!Recommendation: Just return to"Card" pageSeverity: HighHeuristic Principle: Visibility of Sys-tem Status, Recover from ErrorsNote that "Save" acts differently ifuser enters text.Recommendation: See #4 on thispageSeverity: HighHeuristic Principle: Consistencyand Standards"Back" goes to "Card" screenand destroys user changesRecommendation: Default be-havior is to save user actions, orat least change error messageto "Save Changes? Y/N"Severity: MediumHeuristic Principle: Error Pre-vention, Consistency and Stan-dards, User Control"–" confused users -- asking users rightoff to delete what they just selected toadd is a confusing message.Recommendation: no "–" here. Use iOSstandard way (see how Edit works iniOS Contacts)Severity: MediumHeuristic Principle: Consistency andStandards, Recognition Rather thanRecall
  • 12. C lient: Damon Wayans and Aniya Productions. Inc.31. Users had trouble getting to this screen ("Flick BizCard" does not go to an existing card)2. Users confused at check icon, right arrowicon, and list-style button all combined3. Users by icon bar at bottom and icons in blue be-low the card. Features (email, contact) are hidden.4. Use iOS standard "Edit" button for increased con-trast, discoverability, recognition5. Confusing wording in error message6. Confusion at mix of new and existing fields7. Hidden: users did not discover8. Reconsider taxonomy: "Job" AND "Title"?9. "Back" button destroys user input. Disable?10. Users reported potential bugs:a. They could add more than one titleb. They tried to drag and reorder fieldsc. Depending on if they had "touched left" on popu-lated field in Card screen, tapping on a differentfield in Edit screen would seem to overwrite theirprevious choice. Not expected behavior (littleconnection between actions on different screens)
  • 13. Task 1: Recommended ChangesOne of our higher-level conclusions is that the user interaction for this task is so complicated because the interface istrying to do double- or triple-duty. That is, the interface is trying to support multiple user tasks (add a field, remove afield, edit field content) when it may not be able to.Another major source of confusion (for users) and complexity (for the developers) is that the home screen sets the usersto tasks first, then selecting the subject of the task. Since the days of the first Xerox STAR and Mac OS interfaces, usershave learned and worked with a noun-verb structure. For instance: click on a folder and drag it, or click on an item andselect a command.Users are also accustomed to managing lists in a very different way than presented in this build of the app. We recom-mend studying other models, some from Apple that ship with the iPhone. Also, we recommend more closely followingthe Apple iOS Human Interface Guidelines(https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/MobileHIG.pdf); wewould be glad to consult in more detail on that.With that in mind, we prototyped new home and edit screens for Flick Dat. These would need to be user tested, of course,but we believe they would offer a more natural and less frustrating user interaction.C lient: Damon Wayans and Aniya Productions. Inc.3
  • 14. C lient: Damon Wayans and Aniya Productions. Inc.3
  • 15. Task 2: Flick a CardC lient: Damon Wayans and Aniya Productions. Inc.3Step 1-2:Blank "No Name" card appears after "Flick Biz Card"even if user has created their own card.Recommendation: "Flick Biz Card" should loadusers card by defaultSeverity: HighHeuristic Principle: User Control and FreedomUsers did not recognize "Pic" and "Note", confused afterselecting.Recommendation: Make these tasks sub-tasks tied to cardsSeverity: MediumHeuristic Principle: Match Between System and Real WorldUsers confused, not seeing a card. See "Task 1: Recom-mended Changes" for noun-first convention.Recommendation: See "Task 1: Recommended Changes"Severity: MediumHeuristic Principle: Match Between System and Real World"Flick Biz Card" --> "No Name" card screen. Users very con-fused. Show stopper. "Whose card is this?"Recommendation: See "Task 1: Recommended Changes"Severity: SevereHeuristic Principle: Match Between System and Real World,Consistency and Standards, User Control and Freedom
  • 16. C lient: Damon Wayans and Aniya Productions. Inc.3Step 3-4:After users were guided back to the Home screen, it took multipletries (and errors) to locate and select "Cards". Multiple icon barsadded to confusion.Recommendation: See "Task 1: Recommended Changes", or "FlickBiz Card" --> users cardSeverity: HighHeuristic Principle: Match Between System and the Real WorldMultiple selection elements (check, arrow, list button itself) in a sin-gle UI element. Users a) didnt know what they were for b) how theywere different c) did not see system feedback.Recommendation: Rethink user flow, IOS standards and controls.Severity: SevereHeuristic Principle: Consistency and StandardsConfused, users hit "Back". Error messages caused confusion -- theyhadnt made any changes, on top of not wanting to see empty card.Recommendation: See "Task 1: Recommended Changes", or "FlickBiz Card" --> users cardSeverity: SevereHeuristic Principle: Error Prevention, User Control and FreedomUsers eventually tapped the check. Confused by it turning red. Isthat selected? Is that good, bad? No system feedback. Do we needboth check and arrow?Recommendation: As in #3, this page.Severity: MediumHeuristic Principle: Recognition Rather than Recall. System Status
  • 17. C lient: Damon Wayans and Aniya Productions. Inc.3Fail States: If users attempted to Flick from Step4, they saw one of two error mes-sages. On left, the wording gave ahint as to why the user action failed,but no direction as to how to select acard. Users often did not learn how.The other error message, if a cardwas selected (in our testing, moreoften than not by chance). Users hada showstopper: "Share" tab does notexist to users.Note: There should be no need for theShare ("Flick") and Settings screens that soconfused users. Other apps can share dataover 3G, 4G, LTE, as well as Bluetooth andWiFi. Also see "Task 2: RecommendedChanges" for handling app invites. The appshould once, when needed, ask to use thephones email settings and import thoseautomatically.
  • 18. C lient: Damon Wayans and Aniya Productions. Inc.3Step 5: Users often did not recognize check as interactive control. Ifthey tapped on it, was by chance. Confused as to next step.Recommendation: Standard iOS controlsSeverity: HighHeuristic Principle: Recognition Rather than Recall, Consistencyand Standards, User ControlStep 6: If users understood the red check, they found the Flick gesture.Recommendation: User testing to fine-tuneSeverity: LowHeuristic Principle: Recognition Rather than Recall, User Control
  • 19. Task 2: Recommended ChangesAs with Task 1, we saw users come to a complete stop in progressing on this task; we believe that some of the similar un-derlying causes (overburdening the UI with multiple tasks per screen, non-standard controls, "hidden" features, a verb-first user flow). We would have loved to have taken on the challenges of making note taking, drawing, and sharing of bothmore easy. (Though we admit we were not able to understand how the Groups feature worked.)We were confused ourselves at the apps inability to share data over a cell network connection; other apps are able to.One particular example of overburdening the UI is the "invite" feature, which users did not seem to unravel; we had to diginto the app to discover this. It seems to be designed in case one Flick Dat user wants to use the app to share cards withan iPhone user who does not have the app. In our experiences and testing, the app user usually asks the other person togo download the app over the air; we can see the value of having the app automatically send a link to the App Store appdownload page.However, this should happen as seamlessly as possible. Currently, failed attempts send users to complex or confusinglylabeled other screens, taking them away from the task. We saw many showstopper moments here.The app should ask to use the phones email settings, and if permission is granted, do so behind the scenes (this could bebefore the prototypes shown below or in between). Any fail state should take users to a screen that could resolve the is-sue or offer simple and clear guidance.C lient: Damon Wayans and Aniya Productions. Inc.3
  • 20. C lient: Damon Wayans and Aniya Productions. Inc.3
  • 21. General RecommendationsGlobal:The exchange of business cards can sometimes be an awkward social interaction, and in our research seems often to bedone in a crowded, busy environment. The interaction also has the aspect of asking for a favor, and so should minimizethe emotional, cognitive, and temporal burden on the person sharing his or her card. This has design priority implica-tions:1.If the potential sharer has the app, the action of sending should be almost automatic: no configuring email settings, nohaving to go through multiple steps to send ones own card2.If the potential sharer does not have the app, the app must have quickly demonstrable value, be a quick download, andthe email request sent to the potential sharer must be positive, demonstrate value and ease, but still be professional3.All app actions should not require an app-specific learning curve, but leverage affordances people are familiar withthrough the OS, or mimic physical interactionsCenter the app around the users card. Though our research was preliminary, not one evaluator mentioned the desire orexperience of sharing another persons business card. Its a truism in this industry that doing a small thing well is muchmore compelling than doing a large thing poorly; refocusing the app on the users card first, with a library of receivedcards the user can annotate, would ease development and improve user experience.Tie icons for actions on cards to the cards. Keep global actions in menu bar.Use Animation Sparingly:Users did not understand the difference between and use of "Cards" versus "Inbox". We are still not clear on it ourselves,and would like to analyze that from a user perspective, perhaps to find a way to reduce complexity. But animation couldhelp show users what one or the other is for: for example, a received card could shrink and "fly into" the icon, as in iOSsMail app when you move a message to a different folder.C lient: Damon Wayans and Aniya Productions. Inc.3
  • 22. Editing:As above: stick closely to physical mental model. People write notes on cards, not on screens where they also see thecard. As above, a little animation can help, if used sparingly.C lient: Damon Wayans and Aniya Productions. Inc.3
  • 23. Social Media:We would recommend more research into whether users want to use received cards to connect on LinkedIn, Facebook,Twitter, etc., and if so, how. This could take the form of surveys or qualitative research.A few other apps center on scanning business cards and using them to connect on social networks. We recommend acompetitive analysis to see how Flick Dat could compete, or offer added value.Controls and UI:We strongly recommend closer adherence to the Apple iOS HIG. This could reduce user confusion. We saw this immedi-ately: lower-contrast custom controls made it harder for users to see, recognize, and use buttons and other controls.Non-standard and multiple-use controls (see "touch left or touch right") confused users: do not create UI elements thatoffer different functionality depending on where the user touches without sufficient context.Testing:We recommend the next version of Flick Dat include code from http://magitest.com to help get a leg up on user testing.C lient: Damon Wayans and Aniya Productions. Inc.3
  • 24. Analysis and ReportingC lient: Damon Wayans and Aniya Productions. Inc.3HEURISTIC [TASK 1] [TASK 2] TOTALOCCURRENCEVisibility of system status 1 1 2Match between system and thereal world3 4 7User control and freedom 4 5 9Consistency and standards 5 3 8Error prevention 3 1 4Recognition rather than recall 3 3 6Help users recognize, diagnose,and recover from errors2 0 2TOTAL ISSUES Low: 2Medium: 5High: 4Severe: 1Low: 1Medium: 3High: 3Severe: 3Low: 1Medium: 2High: 3Severe: 4

×