Information Organization
for Scale

Context

We wanted to build better information organization capabilities into the product to support larger deployments that have both organic content creation - dashboards and charts that are generated every day by users; as well as structured content - the dashboards and datasets built and managed over time by content owners in various departments.

Role & Responsibilities

I led the research & design for this initiative. The project commenced in Nov 2018. Since then, my engineering team has been shipping features in phases. As of April 2019, the project is in its last phase of delivery.

Research

I partnered with my Product Manager to conduct discovery research amongst 10-15 customers with large deployments to uncover their pain points. The outcome was a detailed experience journey map of the user which helped identify areas of opportunities.

Vision

This project was a design-driven initiative. I created frameworks and prototypes to share the vision & design principles. This helped gain alignment and drive decision making.

Design execution & validation

I was responsible for creating all the design mocks and prototypes. I tested prototypes with internal and external users to validated ideas and solutions at various stages of design. The project culminated with handoffs and design specs to the engineering team.

Leadership

This project was the testing ground for us to kick start our React Component Library. I worked with the Lead Engineer to lay down ground rules and use the design style guide as the foundation for a working reusable library.

Goal

Users can organize their Periscope instances so relevant content is easy to find and access.

Challenges

The project started with a vague hypothesis that our users face problems with "Organization" in the product. Everyone had a different understanding of what that meant, including the users and our stakeholders.

The first step to unravel the myth was to conduct discovery research which would help us understand the matter in depth. This meant throwing a wide net to the users, figuring out the trend and narrowing it down to relevant problem definition.

I did not know what I was going to find out until I found the pattern emerging.

Users & Research

This project touched upon both our user base i.e Data Analysts & Business Users, so the interviews were to be conducted with both.

I had two strategies to pick my research sample:

Method 1

I used our CSM's repository of healthy accounts with happy customers and large deployments. This would help us understand how customers with a large user base and scale of operation use our product. We would be equipped to help them with their workflows.

Method 2

Talk to customers who have complained about the content organization, user management, bulk operations, the structure of the content etc. This would help in gaining insight into the pain points users face today and tackle them at the outset.

I along with my manager took turns in speaking with our customers. We had a transcript, and we stuck with it, to ensure that we stay on track. This process also made it simpler for us to tally user responses and identify the differences and similarities.

Hypotheses

• Customers use tags for dashboard organization.

• Tags are inefficient, and people want a more sophisticated organization for all objects.

• One of the reasons for cruft building over time is the lack of bulk edit/delete options.

• Users are unable to identify the “right objects” to refer to.

• There are a lot of hacks/workarounds around object organization.

• Admins want permissions to be tied to object organization model. E.g. group level, tag level permissions

User Needs

The product is used by a wide variety of organizations, many of which are evolving very rapidly - so it was essential that we consider Organization from the perspective of enablement rather than from prescription.

Although we know that the general strategies employed by our customers are similar - naming conventions and tagging conventions used to express ownership, workflow state, topic and use case - the specifics of each organization would dictate the particulars of an information hierarchy.

The goal was to implement building block technologies rather than end-to-end workflows and be cautious when we provide specific methods of doing something.

Solutions & Strategy

Landing Pages

User Mental Model

What are the established entry points into the information structure of an organization that can be used as starting points for discovery and navigation?

Solution

Landing pages would become the established entry point for our users. We would give them the flexibility to select or create their personalized landing pages based on their preference.

Why is this a solution?

• To encourage reactive or proactive responses.

• To make sure that users get a bird’s eye view of everything that needs to be able to start off their Periscope workflow

Theme Based Organization Structure

User Mental Model

How is content arranged, explained, related, and described?

Solution

Introduce a new (tag-based) concept to the users called Topics. "Topics" would be curated collections of objects. Authors would be able to use Topics organize and group objects around common themes. Objects and Topics can be inter-linked. Topics will appear in the primary left navigation.

Why is this a solution?

• Topics would be valuable to express relationships between an object and other related objects.

• Users would be able to access and find related objects based on theme or usage.

• Authors can curate the experience for their users.

Powerful & Intuitive Search

User Mental Model

How do users find the information they are looking for when they do not have a starting point, or when they have a starting point but not a clear path?

Solution

The search function is required whenever a user is seeking a particular object - dataset, view, dashboard, chart - but does not have either a starting point for exploration or a path to navigate to the object.

Why is this a solution?

• Improve the Search flow by making it more intelligent, predictive and intuitive.

• Help users find the right object within the least amount of time

• Support more reactive elements on the UI for users to find objects before they search for it.

Accessible Navigation

User Mental Model

How do users travel to the information they are looking for when they have a starting point and a general idea of the path?

Solution

List of objects ordered by most relevant logic preferred by user.
(Recency, Alphabetical, Status, Topics)

• Paginated results to have a manageable “above the fold” set.

• Object to be shown alongside set of information to rapidly identify the desired object

• Support navigation with visual markers for retention and memorability.

Why is this a solution?

• Navigation and workflow support go hand in hand.

• Main elements of a good navigation structure include:

  • Quick access.

  • Ability to jump back and forth between objects.

  • Where am I? Cues.

Lifecycle Management

User Mental Model

How is the workflow or production state of an object expressed in the information hierarchy? What tools are available in creating and managing production workflows? What happens to an object that is no longer needed?

Solution

• Automatic clean-up process for users

• Auto archival can be switched on/off by adminsConditions can be customized and defined based on organization needs

• Users with the right permissions can manually override archival and/or restore objects to life.

Why is this a solution?

Auto archiving is essential to keeping a site useful and straightforward to navigate.  By continually sweeping away abandoned dashboards, views, and CSVs, the site will be fresh and up to date.

Validating, Shipping & In-Between

Feature design and development followed a part-agile part-waterfall methodology. I led the design for all the features. Each feature phase was serialized for UI and parallelized for the backend. The engineering team would start on the backed work while I would work on designs, get them tested-validated-approved. Upon approval, the designs were handed off to the team for implementation.

We released all of the features internally. This phase was called “dogfooding”. We would meet our internal champions and our customer support experts to gather feedback and triage bugs. We also Beta-released the features to all of our customers who helped us in our discovery phase. That became our external testing channel. All of the comments and feedback poured into our dedicated Slack channel for feedback, and we used it to add improvements to our backlog.

We are currently in the last phase of our release.

Learnings

This project was a massive undertaking. I was touching all different parts of the product, and it felt like a mini redesign project in itself. I was radically changing the way our users were going to interact with the product and their experiences.

After I passed the first hurdle of knowing what to build, the other dilemma came in the form of operational intensity. At a given time, I found myself switching contextual between planning for a feature, designing another and testing the third feature. I overcame this by being very diligent about taking notes and recording my thoughts and all the meetings. I eventually starting sharing these notes as MOMs at meetings to keep all my stakeholders informed about the status of the project and its velocity.