Cover.png

ESRI UX Internship Project

Re-designing the Search Experience

of ESRI ArcGIS Hub 

 

 

 

My Role

UX / UI Designer

Practices

Responsive Web Design

Tools

Adobe XD

Project Time

June 2018

 

 

 

 

 

My story with ESRI 

I spent 3 months in Summer 2018 working with ESRI R&D Office in Washington D.C., during which I joined as a UX designer intern in the ArcGIS Hub team. I felt really blessed working with a group of extremely talented and passionate people there, where we worked together to conquer all kinds of design challenges along the way. At the same time, we explored the city with curiosity and had a lot of fun.


As for the product I was working on, Hub was at a phase where changes are made at large scale, I felt very glad to be trusted and assigned with the task of re-designing the search experience of the product. It was a journey full of challenge but at the same time full of senses of achievements.

 

 

 

 

What is ArcGIS Hub?

ArcGIS Hub is an enterprise product, it is designed to increase mutual engagements between governments and their fellow communities.

On government and organization side, it is a platform where large civic campaigns are launched and monitored, public data are published and social engagement activities get released out.

For the community side, it is a place for people in the community to look up recent civic motions, search for published data, and better know what's important amongst the activities going on.

Know more about ArcGIS Hub

arcgis hub.png

Part I

Project Overview

 

Shifting of product position from Open Data to Hub

The product was originally named "ArcGIS Open Data", it's a web application where governments and organizations use this as the channel to publish civic related datasets.

In order to transform the product to be capable of holding more contents and serve a border group of people, the concept of Hub is been raise. Hub aims to be a platform where civic engagement happens in all dimensions, public campaigns get announced, events get created, discussions are formulated.

previous and now.png

Problems with existing search experience

The existing search interface is built a year back and did not have many updates since then, there are some major problems with the interaction flow that made it incapable of handling searching experience on Hub.

  • Information structure is made to search for datasets only.

  • Redundant features. (e.g. data visualization on maps)

  • Under-utilized filters.

  • Not mobile friendly

Design Process

The following graph summarized my approach and process for tackling this design problem. I started my project after the discovery phase, where the main persona had just been defined, with only an ambiguous product vision.

 

 

double diamond.png

Project Deliverable

At the end of my internship, I finished building the mid-fidelity mockup for both mobile and desktop environment.

Results.png

 

 

Part II

Challenge One: Conflicting persona

Bringing in new user groups always brings in new problems. There are in total three personas being build for the hub, two of which are highly associated with building the search experience. Each persona represents a group of the user whose usage scenarios are very different from each other.

The first persona, Mira, represents a typical ordinary citizen, who has less professional knowledge about GIS. The second persona, Lilith, represents a typical GIS analyst, who is proficient in data analytics and is always looking for the dataset from credible resources.

Build empathy - Find what’s common & what’s not

It is essential to understand how the user perceives Hub. To them, how can Hub be a useful tool for them to build a stronger bond with their community?  For each persona, I investigated into their corresponding user group to analyze their search pattern.

Empathy.png

Insights

"How might we balance feature requirements between power user and ordinary user?"

On the one hand, for ordinary citizens, they are looking for a website that is simple to use and does not require advanced knowledge to perform a search. On the other hand, for legacy user groups from Open Data, who are highly skilled in data analysis, they want a search experience that is powerful and highly customizable.

Breakdown Challenge: Constrain search capability on mobile platforms

One design could not meet two conflicting user requirements. However, for ordinary citizens, their main platform of use is on mobile. As a result, when the website is been visited on mobile, advanced features will be hidden from the user to keep the search environment simple and concise.

different.png

Challenge Two: Presenting search results for rich content types

Originally, datasets were the only elements that are searchable in the product. As the product moving to the concept of Hub, more types of data become available to the end users. While the search becomes more powerful and complex, we need to keep the interaction experience simple.

shift.png

Insights

"How might we provide better navigation in search results?"

Having too much content itself is not a problem, but instead, with a massive amount of content being presented to the user in the search result, how to facilitate the user navigate through the content is the root of the problem.

Breakdown Challenge: Create meaningful groups

While Hub contains dozens of new elements that are searchable, from the user’s perspective, it is not necessary for the users to specify the type of element they are searching.

Group things by what the user can do with them

Search is not only about giving user relevant item but more to that, the whole search experience is about answering people’s question. When a list of items gets presented to the user, things they care about is what value could they draw from it? The instant question would be “what can I do with all the stuff”, and that is the ideology behind designing the category.

In total, the results would be grouped into 6 categories, each has a common theme on what the user can do with them.

 

 

search groups.png

 

 

 

Part III

Develop

Construct search flow

There are two phases of search. Inputting a search query and displaying a search result. The full search flow is shown below. It is built with regard to two personas of both ordinary citizen and skillful analyst.

Web 1920 – 1.png

 

 

Fast Iteration under low fidelity

Given the limited time period on my internship, I kept the mockup in low fidelity so that I could have fast iterations on the design and do more explorations.

Part IV

Three Deliverables

Design Principle

A balance between power / ordinary usage scenario

Search is designed to have different capabilities when accessing from desktop and mobile. For the search on mobile, the main usage is designed to be lite for fast browsing. While for desktop, the user is able to get the full power of complex filtering on the result.

Design Principle.png

Deliverable One: A fast feedback query experience

The search experience starts instantly when the user types in a character into the search bar. Before they even hit the “Enter” button, help user input the right query is also an important part of the search experience.

While the user is typing, I designed three types of quick look-up options to be shown in a dropdown list.

  • Relevant items that contain query keywords / synonyms

Enables users to get instant feedback of things they would get after hitting the enter button.

basic search.gif
  • Option to search within a category

Provide quick access to constrain search under a category, shortening the interaction steps.

  • Option to search near a geolocation  

Unleash the full power of geological search capability and perform quick search around an area.

Complete interaction flow

full resolution

Search Flow.png

A balance on affordance (feature indicator)

On the desktop environment, in order to educate user the usage of complex search commands, a cheatsheet bar would be appended to the end of the search dropdown list. While on the mobile environment, the cheat sheet is hidden.

full resolution

Deliverable Two: Rich type search result

For every query the user enters, the results are organized into six categories. The user is able to toggle between every category to switch from one search context to the other.

Search Results.png

A balance on search result details

Search is designed to have different capabilities when accessing from desktop and mobile. For the search on mobile, the main usage is designed to be lite for fast browsing. While for desktop, the user is able to get the full power of complex filtering on the result.

A typical example is when the dataset search result gets presented. When data is searched on the desktop, users would be given the ability to fine-tuning search results with filters. Besides, more details regarding each dataset would be displayed.

full resolution

datasets.png

Complete layout for search results categorization

full resolution

Search Results.png

Deliverable Three: Multi-language compatibility & accessibility

Hub is targeting to serve a vast group of people, it is essential to make sure the product is equally usable in other countries and amongst people with disabilities.

Multi-language compatibility: Leave substantial line length

A few things we check to determine if a layout would work is to make sure text would not be hidden when being translated to languages that tend to have long text structure. With that in mind, we tested the design in multiple languages. German, Japanese and Russian are the top three languages we tested that tend to grow a lot in text length after translation.

Accessibility: Comply with WCAG AA standard

In order to make Hub accessible to all citizens and caring for people who have visual disabilities, it is indispensable to push accessibility to every pixel of the design. Thus, I built my design to comply with WCAG AA standard to make it readable for all.

accessibility.png

Full UI kit (mid-fidelity)

The UI kit contains the desktop and mobile designs for:

Item Cards.png

Part V

Future works

User testing on item card & filter design

The current information structure on item card design is created based on past client interview experience. It has to be tested with real user groups to see if the information presented help them find contents faster.

What’s the best way to perform geographical search?

A question I was curious about to find out is that: “Is traditional search the best way to search for Geo-data?

I did an exploration on making a map search interface, where people would be able to perform the search using a map interface. The map provides an extraordinary amount of affordance that the traditional search interface is not able to provide. Features such as drawing areas on the map so constrain search context makes the search experience more visual, and easy to interpret.

However, due to the time limitation, I was not able to fully flush out it. A screenshot of a mid-fidelity mockup is shown below.

Part VI

Reflection

Move fast under low fidelity

In the re-designing of ArcGIS Hub, it is critical that I keep the design in low fidelity to move things fast and gets more iterations done. Fast iteration allows me to receive more feedbacks and keeping the design flexible to requirement changes.

Working with enterprise product

Different from designing consumer-facing product, it’s usually hard to do user testing on an enterprise product. The way I gained user knowledge that is in depth is to have frequent conversations with client facing analyst and user researcher team.

Build viable design

While the design usually is not restricted by the implementation, it is still important that the design should be viable and achievable under the development constraint.

Initially, I developed a concept of “Topics”, which intends to group things by content rather than their type. However, this decision is pushed back by the development team due to the drastic changes on existing search indexing database.

From this un-successful exploration, I learned that even though designers should not constrain itself to a existing technology stack, getting frequent inputs from the developer side is of equal importance that we build a shippable product.

A non-viable exploration, group elements by its content