Google Maps Redesign
Individual Project | UX Design

Google Maps Redesign
Individual Project | UX Design

Quick Facts:

Role:

UX designer

Time:

Fall, 2013

Client:

Google Maps
(CMU 05-863 half-semester individual project)

[Skills]
Methods:

Contextual inquiry, Sketching, Paper prototyping, Wizard of oz, Usability evaluation, Hi-fi prototyping, Interaction design, Heuristic evaluation, Cognitive walk-through

Tools:

Axure RP 6.5, Balsamiq, MS Visio, Adobe Illustrator

Deliverable:

Prototype in Axure, Mobile optimized mockup

Quick Facts:

Role:

UX designer

Time:

Fall, 2013

Client:

Google Maps
(CMU 05-863 half-semester individual project)

[Skills]
Methods:

Contextual inquiry, Sketching, Paper prototyping, Wizard of oz, Usability evaluation, Hi-fi prototyping, Interaction design, Heuristic evaluation, Cognitive walk-through

Tools:

Axure RP 6.5, Balsamiq, MS Visio, Adobe Illustrator

Deliverable:

Prototype in Axure, Mobile optimized mockup

Project goal: Redesign a complex system/device (applications that at least more than 30 controls, 10 different pages, or more complex), and make it better the user experience enforcing decent interaction rules. I chose Google Map on iPhone for the reason that I noted Google Maps was pitched as the world’s most popular mobile app at that time around. Then I thought whether its experience is really as top-notch as it claimed? In what possible directions is it able to be improved and will that help in a broader sense? The idea strikes me a lot and then kept me working on refining the design for a period of time.

Contextual Inquiry & Analysis

I invented some tasks to decide the focus for the users to help understand their real world needs. Then I made models directly from the transcript, in order to force summarization and conciseness for analyzing the result.

Interview with novice user: Tasks and Interview Scripts (9 pages, 377kB)
If you would like, please see above the complete contextual inquiry process, including interview questions, tasks settings, interview scripts(line numbers ready to be referred later in the analysis), and summarized do's and don'ts.

Revealed by the social model, influences (often invisible) that impact how workers do their jobs can be clearly mapped;  also, using the flow model, I am able to capture the flow of people, actions, information, and artifacts from the perspective of one individual roles. Generating flow models illustrated successes and breakdowns in communication between workers. The models served as visible documentation of a worker’s concrete responsibilities as they were enacted during interviews.

Contextual Models

Click left to view:

  • Flow Model
  • Social Model

 

Other models I used:

  • Artifact Model
  • Sequence Model

To inform following design process, I then made a list of things need to be retained and those need to be redesigned for the user interface, that I learned as a result of this study, that will guide my alternative design for the device:

Don’ts: 

  1. Zooming area is not clear without any direction indication (line 21-23)
  2. Exploring function is not clearly mapped with the drawer, which will be opened on the left side of the screen to help users see road information in various capabilities. (line 89-106)
  3. Once a place is searched out, it is not obvious to see the direction to it (line 76-81, line 85-93, line 113)
  4. When starting a new search from the existing place the user is looking at, the historical data remained in the typing area, which can be a very huge distraction for the user to quickly identify a place to input new destination. (line 165-171)
  5. There is no indication to know if the traffic information has been taken into account the transportation time calculation shown in minutes. (line 158-160)
  6. Direction button is not as obvious as expected, thus making it too small to recognize (line 49-59, line 211-213)

Dos: 

  1. Retain zoom in and zoom out function for exploring the map itself (line 7-11)
  2. Give a thumbnail of preview about the best option of driving direction(line 121-132)
  3. Always show GPS option on the car driving routes with traffic information indicated (line 145-147)
  4. Always show preview for the walking options (line 189-190)
  5. Remain different routes options on a single map (line 152-156)

Paper Prototype

Using the information collected in contextual inquiry for what is good and bad about the real appliance’s user interface for the tasks I designed, I made sketches and a paper prototype of a (hopefully) better design.

I sketched 3+ different design directions:
The differences between versions are carefully discussed in this document (2 pages, 340kB).

Design decision: I chose to go further with the version that has a magnifier for the Google Maps interface. The reason is that it has the affordance for users to manipulate in a natural pattern just like a magnifier – a quicker and more fluid preview of the places. Also from the preview, the user can get directions to/from it just as simple as other versions. The advantage is that with a magnifier, going back and forth from the exploring function and the direction function becomes identifiable for any users, regardless of their levels experience. It can be easier and less error-prone for the user to map exploring function with the magnifier, than what is in the version 2 toggle between functions by shaking and clicking buttons. The flow as a whole is connected comprehensively and more smoothly than other versions in my initial design directions.

Prototypes on paper

The low-fidelity prototypes are made in Balsamiq for 10+ screens

The prototypes are made in Balsamiq, and printed out on paper, then folded intentionally in a task flow sequence, for the ease of testing with the user later on.

The controls is also printed out seperately to prepare for later user testing session

 

Design rationale (enlightened from Contextual Inquiry): From the contextual inquiry, I learned that there are so many functions need to be reflected in a limited size screen, and the user always need to figure out what buttons to go with. Why not make the flow more fluid so that users will identify what to do quickly? For instance, according to the user, zooming area is not clear without any direction indication (line 21-23); exploring function is not clearly mapped with the drawer, which will be opened on the left side of the screen to help users see road information in various capabilities(line 89-106) – I redesigned the interface by having a magnifier so that where to move the map is directional to the movement of the magnifier, from which the map can be zoomed in, and within the zoomed-in area users can freely view street information by choosing the menu just on top of the preview pane. Also, to solve the problem of no obvious direction marked once a place is searched out (line 76-81, line 85-93, line 113), I placed the direction options just on top of the preview pane. In the original Google Maps application, the historical data always covers the input search box and thus generates distraction for the user to efficiently input new places to search, I also resolved the problem in my design that input boxes are always empty, it will only show options of history data when being clicked. In order to avoid confusions regarding searching a single place or searching a pair of from-to places, the search box is by default designed to be a single place search, and it will change to a directional search (needs to input both “from” address and “to” address) only when the user chooses to do so, by clicking a button next to the default search status.

The new design: In general, contextual inquiry of Google Maps indicated that the original design has patterns that are not at all natural to the users. There are so much tiny stuff that need the users to learn and figure out. It can be extremely troublesome for novice users. Inconsistent controls such as searching for a single place and searching for a pair of places, transitions between maps view and search view, identification between information pane and search bar appear to be annoying, and users are hard to remember where is the function, let alone mapping the functions with various specific icon/controls. User is confused about where to click on in order to do what they want. My design of the new version is to reduce the confusions by making a naturally appealing interface, eliminating unnecessary controls in some steps and reinforcing the immediate actions, so that users won’t be annoyed by so much options throwing at them at a time.

Usability Evaluations

To prepare for the user studies on paper prototypes, I wrote a short description of what tasks I will have users do with the device. I also wrote down the specific sequence of actions that the user should take with my prototype to achieve those tasks, along with the actual instructions I will give users to tell them to do those tasks. Preparation for user studies (3 pages, 346kB)

I conducted paper prototype user study sessions with 3 different users. Each remains around 30 min, and each was videotaped and recorded as transcripts in word documents for further references.

session records
headerOfUsabltEval

Usability evaluation report is conducted for each user session.

It includes: Problems that the user had; the feedback related to that problem; problem scope and severity justification; ways to rectify and possible design tradeoffs

Several changes are made to the prototype after the 1st user study session.

Please find below:

Usability Evaluation Report of 1st User
(22 pages, 647kB)

Summary of Changes (3 pages, 683kB)

changes

interview2-2

2nd round of user study session

Based on the refined prototype, I conducted the second round of usability evaluation sessions, and then made changes iteratively according to the study results.

Usability Evaluation Report of User 2
(14 pages, 454kB)

Usability Evaluation Report of User 3
(11 pages, 413kB)

Implementation of the Prototype

I implemented the re-designed interface based on low-fidelity paper prototypes, after applying changes that are learned from usability evaluation sessions.

implementing

Made in Axure RP6.5, the prototype mocked up the redesigned pages, controls and interactions for the previously settled tasks.

Heuristic Evaluation

We did peer heuristic evaluations based on Neilsen’s 10 usability heuristics. Each student in our 05-863 (“Human-computer Interaction for Tech Executives” course in HCII at Carnegie Mellon Univ.) class evaluates the user interfaces of two other people in the class.

I fulfilled the heuristic evaluation by applying categories to the right (this is later used in all my design projects), which covered the heuristics examined by other classmates and what actions, along with the justification, that the designer decide to do with it. I made design decisions and recorded them in the documents with related rationales carefully.

headerOfHE

For the peer heuristic analysis I received from our HCI class, I carefully responded to each criticism, and avoided changing each good thing mentioned. My action taken and justification are all annotated in the documents.

Revised Interfaces Based on HE

implemented

Resulting from responses to all the user studies and heuristic analyses, I applied changes and made a final revised prototype.

Prototype access from the desktop
(link to Axure site in new tab)

Prototype access from mobile device
(link to Axure site in new tab)

I discussed how I responded to each item mentioned by my HCI course classmates. You can also view the full summary of revisions here: Revisions Summary based on HE (pdf, 1.31M)