Mobile application usability audit

"FLICK DAT" USABILITY AUDIT
5544 Lawton Ave, Oakland CA • telephone: 415.606.4811 • www.twoa ngstr oms. c om
5544 Lawton Ave.
Oakland, CA 94618
T 415.606.4811
ddt@twoangstroms.com
www.twoangstroms.com
DANIEL DREW TURNER

Report Overview
With the goal of helping streamline the iterative development of Flick Dat, we conducted a usability review of the current
build (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. It's 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 not
review all features of the app, nor did we evaluate all areas of it. We focused on two of the necessary tasks that users must
undertake to get any value out of the app.
This review consisted of two phases:
1. Pre-Evaluation Survey
2. Usability Audit and Heuristic Evaluation
This report outlines the ﬁndings of our review.
Research assistance provided by Corinne Longman and Loe Lee.
C lient: Damon Wayans and Aniya Productions. Inc.
3

Participants
We 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 and
those 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 meetups
and 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 place
in 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 the
respondents said that they contact people, two said "nothing", and a third of respondents replied along the lines that
3

they just toss the cards on their desk or put them in a drawer. This speaks to a real confusion about how to deal with
business cards, despite intentions.
Almost all iOS users said that they do not put business contacts into their iOS Contacts list, or maintain multiple contact
lists.
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 could
represent LinkedIn's 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 ﬁelds 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 and
email is enough to easily connect with people on professional and most social networks.
3

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 user
sample (see "Methodology"). We attempted to balance these evaluators between those who had used or do use an app for
managing and/or sharing business card information, though we found the it difﬁcult to ﬁnd many who had. (It's incon-
clusive at this scale whether this represents a market need for Flick Dat or poor penetration of this kind of app, including
competitors.)
3

Methodology
In the usability audit, we collected usage/behavioral data through a hybrid approach, combining cognitive walkthroughs
with heuristic evaluation methods. This approach take the following steps:
1. Define the users and their goals
2. Define the tasks they would attempt
3. Walk through the tasks step-by-step through the lens of the user (what terms they use, the things they'd look for and
likely paths they'd take)
4. Look for and identify problems based on a set of heuristic criteria
5. Specify where in the interface the problem is, how severe it is and possible design fixes
This methodology is known to return actionable results with a limited time and sample. The goal is to uncover and rate
usability 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 need
to perform these tasks, and these tasks would be among the most common tasks performed.
Task 1: Add/Remove a Field on a Card
Task 2: Share a Card
As 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 full
usability test of the app would extend to more tasks, more users, and offer more detailed feedback on each user and sys-
tem action.
3

Modified Heuristics
After Nielsen's 10 heuristics and later work in the field, we chose a modified set of heuristics, specifically focused on the
needs 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, phrases
and 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" to
leave 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 mean
the same thing. Follow platform conventions.
Error prevention: Even better than good error messages is a careful design, which prevents a problem from occurring
in the first place.
Recognition rather than recall: Minimize the user's memory load. Make objects, actions, and options visible. The
user 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.
3

Flexibility and efﬁciency of use
Aesthetic and minimalist design
Help 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 documentation
3

Task 1: Add/Remove Field on a Card
3
Step 1-2:
Users expected iOS-standard "swipe left" to delete
field. Many attempts, frustration.
Recommendation: Use iOS standard control
Severity: High
Heuristic Principle: Consistency and Standards
"Back" button gives error message, destroys user
data. Stress!
Recommendation: Save user action by default
Severity: High
Heuristic Principle: User Control and Freedom
Users had trouble getting to "Card Edit" page --
"Edit" button contrast is low.
Recommendation: use iOS standard. Better: see
"Task 1: Recommended Changes"
Severity: Medium
Heuristic Principle: Recognition Rather than Recall
Users overwhelmingly failed to find the "left touch"
area to add a field. Fail state.
Recommendation: Save user action by default
Severity: Severe
Heuristic Principle: Recognition Rather than Recall

3
Step 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 user
task (e.g., "Add field").
Severity: Low
Heuristic Principle: Match Between System and the Real
World
If user "touched left" an already populated field, and then
selected a different field name in this screen, that data is
moved to this field name, no system indication, not use
expectation
Recommendation: Do not show existing card fields on
this "Fields" screen
Severity: High
Heuristic Principle: Error Prevention, Match Between
System and Real World
"Back" behaves differently in same context: goes to card Edit
page here, but "Back" in Edit page leaves and destroys
changes; confounds user learning
Recommendation: different names for "Back"
Severity: Medium
Heuristic Principle: Error Prevention, User Control and Free-
dom
Selecting a field that already does nothing, wastes user
action. Users showed confusion and irritation.
Recommendation: Do not show existing card fields on this
"Fields" screen
Severity: Medium
Heuristic Principle: Match Between System and Real World

3
Step 4: Touch in last screen switching
screen back to "Edit" screen,
confused users
Recommendation: see larger
recommendation about iOS
standard add/edit list behavior
Severity: Low
Heuristic Principle: Recover
from Errors, Consistency and
Standards, User Control
(after touching
"Job" in last screen)
Touching "Save" with no text returns
error message "Please add title to all
ﬁelds". Users confusing: Unclear what
"title" means or how doing some-
thing to "all ﬁelds" relates to user
action. It confused us, too!
Recommendation: Just return to
"Card" page
Severity: High
Heuristic Principle: Visibility of Sys-
tem Status, Recover from Errors
Note that "Save" acts differently if
user enters text.
Recommendation: See #4 on this
page
Severity: High
Heuristic Principle: Consistency
and Standards
"Back" goes to "Card" screen
and destroys user changes
Recommendation: Default be-
havior is to save user actions, or
at least change error message
to "Save Changes? Y/N"
Severity: Medium
Heuristic Principle: Error Pre-
vention, Consistency and Stan-
dards, User Control
"–" confused users -- asking users right
off to delete what they just selected to
add is a confusing message.
Recommendation: no "–" here. Use iOS
standard way (see how Edit works in
iOS Contacts)
Severity: Medium
Heuristic Principle: Consistency and
Standards, Recognition Rather than
Recall

3
1. Users had trouble getting to this screen ("Flick Biz
Card" does not go to an existing card)
2. Users confused at check icon, right arrow
icon, and list-style button all combined
3. 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, recognition
5. Confusing wording in error message
6. Confusion at mix of new and existing fields
7. Hidden: users did not discover
8. Reconsider taxonomy: "Job" AND "Title"?
9. "Back" button destroys user input. Disable?
10. Users reported potential bugs:
a. They could add more than one title
b. They tried to drag and reorder fields
c. Depending on if they had "touched left" on popu-
lated field in Card screen, tapping on a different
field in Edit screen would seem to overwrite their
previous choice. Not expected behavior (little
connection between actions on different screens)

Task 1: Recommended Changes
One of our higher-level conclusions is that the user interaction for this task is so complicated because the interface is
trying to do double- or triple-duty. That is, the interface is trying to support multiple user tasks (add a field, remove a
field, 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 users
to tasks first, then selecting the subject of the task. Since the days of the first Xerox STAR and Mac OS interfaces, users
have learned and worked with a noun-verb structure. For instance: click on a folder and drag it, or click on an item and
select 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 following
the Apple iOS Human Interface Guidelines
(https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/MobileHIG.pdf); we
would 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.
3

3

Task 2: Flick a Card
3
Step 1-2:
Blank "No Name" card appears after "Flick Biz Card"
even if user has created their own card.
Recommendation: "Flick Biz Card" should load
user's card by default
Severity: High
Heuristic Principle: User Control and Freedom
Users did not recognize "Pic" and "Note", confused after
selecting.
Recommendation: Make these tasks sub-tasks tied to cards
Severity: Medium
Users confused, not seeing a card. See "Task 1: Recom-
mended Changes" for noun-ﬁrst convention.
Recommendation: See "Task 1: Recommended Changes"
Severity: Medium
"Flick Biz Card" --> "No Name" card screen. Users very con-
fused. Show stopper. "Whose card is this?"
Recommendation: See "Task 1: Recommended Changes"
Severity: Severe
Heuristic Principle: Match Between System and Real World,
Consistency and Standards, User Control and Freedom

3
Step 3-4:
After users were guided back to the Home screen, it took multiple
tries (and errors) to locate and select "Cards". Multiple icon bars
added to confusion.
Recommendation: See "Task 1: Recommended Changes", or "Flick
Biz Card" --> user's card
Severity: High
Heuristic Principle: Match Between System and the Real World
Multiple selection elements (check, arrow, list button itself) in a sin-
gle UI element. Users a) didn't know what they were for b) how they
were different c) did not see system feedback.
Recommendation: Rethink user ﬂow, IOS standards and controls.
Severity: Severe
Heuristic Principle: Consistency and Standards
Confused, users hit "Back". Error messages caused confusion -- they
hadn't made any changes, on top of not wanting to see empty card.
Recommendation: See "Task 1: Recommended Changes", or "Flick
Biz Card" --> user's card
Severity: Severe
Heuristic Principle: Error Prevention, User Control and Freedom
Users eventually tapped the check. Confused by it turning red. Is
that selected? Is that good, bad? No system feedback. Do we need
both check and arrow?
Recommendation: As in #3, this page.
Severity: Medium
Heuristic Principle: Recognition Rather than Recall. System Status

3
Fail States: If users attempted to Flick from Step
4, they saw one of two error mes-
sages. On left, the wording gave a
hint as to why the user action failed,
but no direction as to how to select a
card. Users often did not learn how.
The other error message, if a card
was selected (in our testing, more
often than not by chance). Users had
a showstopper: "Share" tab does not
exist to users.
Note: There should be no need for the
Share ("Flick") and Settings screens that so
confused users. Other apps can share data
over 3G, 4G, LTE, as well as Bluetooth and
WiFi. Also see "Task 2: Recommended
Changes" for handling app invites. The app
should once, when needed, ask to use the
phone's email settings and import those
automatically.

3
Step 5: Users often did not recognize check as interactive control. If
they tapped on it, was by chance. Confused as to next step.
Recommendation: Standard iOS controls
Severity: High
Heuristic Principle: Recognition Rather than Recall, Consistency
and Standards, User Control
Step 6: If users understood the red check, they found the Flick gesture.
Recommendation: User testing to ﬁne-tune
Severity: Low
Heuristic Principle: Recognition Rather than Recall, User Control

Task 2: Recommended Changes
As 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-
ﬁrst user ﬂow). We would have loved to have taken on the challenges of making note taking, drawing, and sharing of both
more easy. (Though we admit we were not able to understand how the Groups feature worked.)
We were confused ourselves at the app's 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 dig
into the app to discover this. It seems to be designed in case one Flick Dat user wants to use the app to share cards with
an iPhone user who does not have the app. In our experiences and testing, the app user usually asks the other person to
go download the app over the air; we can see the value of having the app automatically send a link to the App Store app
download page.
However, this should happen as seamlessly as possible. Currently, failed attempts send users to complex or confusingly
labeled other screens, taking them away from the task. We saw many showstopper moments here.
The app should ask to use the phone's email settings, and if permission is granted, do so behind the scenes (this could be
before 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.
3

General Recommendations
Global:
The exchange of business cards can sometimes be an awkward social interaction, and in our research seems often to be
done in a crowded, busy environment. The interaction also has the aspect of asking for a favor, and so should minimize
the 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, no
having to go through multiple steps to send one's own card
2.If the potential sharer does not have the app, the app must have quickly demonstrable value, be a quick download, and
the email request sent to the potential sharer must be positive, demonstrate value and ease, but still be professional
3.All app actions should not require an app-specific learning curve, but leverage affordances people are familiar with
through the OS, or mimic physical interactions
Center the app around the user's card. Though our research was preliminary, not one evaluator mentioned the desire or
experience of sharing another person's business card. It's a truism in this industry that doing a small thing well is much
more compelling than doing a large thing poorly; refocusing the app on the user's card first, with a library of received
cards 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 could
help show users what one or the other is for: for example, a received card could shrink and "fly into" the icon, as in iOS's
Mail app when you move a message to a different folder.
3

Editing:
As above: stick closely to physical mental model. People write notes on cards, not on screens where they also see the
card. As above, a little animation can help, if used sparingly.
3

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 a
competitive 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 that
offer different functionality depending on where the user touches without sufﬁcient 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.
3

Analysis and Reporting
3
HEURISTIC [TASK 1] [TASK 2] TOTAL
OCCURRENCE
Visibility of system status 1 1 2
Match between system and the
real world
3 4 7
User control and freedom 4 5 9
Consistency and standards 5 3 8
Error prevention 3 1 4
Recognition rather than recall 3 3 6
Help users recognize, diagnose,
and recover from errors
2 0 2
TOTAL ISSUES Low: 2
Medium: 5
High: 4
Severe: 1
Low: 1
Medium: 3
High: 3
Severe: 3
Low: 1
Medium: 2
High: 3
Severe: 4

Mobile application usability audit

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

Similar to Mobile application usability audit

Similar to Mobile application usability audit (20)

More from Daniel Drew Turner

More from Daniel Drew Turner (15)

Recently uploaded

Recently uploaded (20)

Mobile application usability audit