Diffbot Extract Feature

Starting from (near) scratch

A fresh, clean, blank slate: no existing interface

Diffbot is a machine learning startup in Menlo Park, CA that provides developers with tools to transform websites into usable data. Their goal is to make it easier for people to search and understand information on the web. Their services can read sites like a human brain, and then transform the content into structured information to present users with facts that people want to know. Without Diffbot, people run internet crawls to do this, but that requires custom-written codes which can become expensive and tricky to upkeep. When we began this design sprint, Diffbot had no user-facing interface for their Extract feature.

Duration:
3.5 week sprint

We started off by defining the problem:

Diffbot’s current Extract tool does not have clear directions for users to be able to navigate on their own to fix errors. Users need to be able to edit fields and customize the API rules but there are major points of disconnection in the interface which make it difficult to find solutions. This causes users to become frustrated with the tool and forced to contact support or quit the service.

A major point of disconnection

Understanding our starting point

For this project, we focused on the Extract feature which didn’t have an interface. Diffbot recognized a growing need for a more user-friendly experience because more non-developers were starting to use the platform. The site uses a lot of highly technical developer language, such as APIs (a set of rules that programs use to speak to computers) and CSS Selectors. Though it’s primarily been built with developers in mind, one of the company’s goals is to provide tools that are accessible to all people, no matter their prior knowledge or background.

Prior to this, the Extract feature came in two separate parts, Test Drive and Custom APIs. Test Drive is not an actual developer tool, but an interactive feature to allow users to see if their URLs will extract data properly. It does not allow users to edit the data or change the API type. Custom APIs is an entirely separate tool which gives users a lot more flexibility and freedom.

In the original design, users would create or edit by building off a pre-existing API or starting from scratch. This allows a good amount of user freedom and flexibility, but definitely requires developer knowledge of CSS Selectors.

Because the two tools were entirely disconnected in the navigation, even experienced customers still sometimes require help going through this process. New customers were also having a hard time drawing any connection between the Test Drive Extract and Custom APIs. Customers were reaching out on a regular basis to ask for help.

Diffbot is capable of more user freedom than this, but was not equipping users with the connected interface to be able to unlock that freedom.

Getting to know the Efficient Engineers

Developing a focused persona

Each of our research findings gave us information about Diffbot’s target users. At this point we’d developed a sense of understanding and appreciation for our users, and put them together into a persona. 

Meet our Efficient Engineer.

About
The Efficient Engineer works for a company that needs to extract data on an ongoing basis to populate information for their website. Their company is known for providing reliable and trustworthy data, which are also their personal values. It’s critical for them to uphold that reputation. They want to save time and would rather not write their own code to do web scrapes, as their main duty is to ensure large amounts of data are extracted consistently and accurately.

Motivations
- Getting the job done quickly
- Data that is accurate and trustworthy
- Staying organized

Goals
- Be able to work independently on extractions and solve problems on their own
- Spend less time on tedious tasks
- Extract accurate, reliable, and structured data

Frustrations
- Disorganized information
- Having no options to resolve errors or incomplete data
- No indication of incomplete data
- Lacking the information they’re looking for
- Having to contact support

Embarking on an enjoyable journey

Mapping the current user journey to identify the ideal path

Our Efficient Engineer had been going through Diffbot’s program without being able to find clear solutions to their issues, and go on a negative emotional path. Our job was to be sure they’d stick to the upward path, getting exactly what they need without having to ask for help.

When users are at the high point of using Diffbot for the first time, we want to be sure they don’t drop from that. We want to retain as many users as possible, encouraging them to keep going up by finding the program intuitive and knowing where to go to edit rules and fix errors. After they make sure one page is extracted with complete, accurate data, they can scale the process to as many pages as they need.

A gap in the flow

Understanding the problem by creating user flows

One of the most helpful steps in understanding the current experience was mapping out the current-state user flow. This is a lot to look at. The crucial point of disconnect here is the conditional that comes when edits need to be made: “Do you know where to go?” At this point users either know that they can go to Custom APIs to edit the rules, or they can contact support or quit. If they do know where to go, they’re taken on a happy path to edit their API rules. Usually this knowledge is gained with help from customer support, as it was not connected to the Extract process.

The pre-existing flow with every possible path mapped out looked like this (don’t worry about grasping this):

Subsequent points of friction show up after API edits are made, whether or not the users know to go to Diffbot Docs to find their API link or know to get their token from the dashboard. After each of these critical pieces of information are collected, they can add their token to the newly edited API link in order to run extractions and integrate the data into their projects. 

And so we identified the problem:

Diffbot’s current Extract tool does not have clear directions for users to be able to navigate on their own to fix errors. Users need to be able to edit fields and customize their APIs but there are major points of disconnection in the interface which make it difficult to find solutions. This causes users to become frustrated with the tool and forced to contact support or quit the service.

And our design hypothesis: 

We believe that if we design the experience with all the required tools connected, include buttons for available options, and provide information where needed, then Diffbot’s Extract users are going to be self-sufficient and happy to continue using the service.

The design process started with a revision of the user flow to create a smoother process for users. We focused on a cleaned-up, single happy path along the top of the flow, and made sure to give users plenty of connected options that would lead back to that path but still allow users to feel free to explore.

One of the key changes is allowing users to change the API type before extracting the data. Depending on the page type, if the API is just set to the default, Analyze, then the formula can sometimes be ineffective. If users know the type they’re trying to use, they don’t have to waste time performing an Analyze extract first.

We were also sure to include every possible troubleshooting option throughout the flow, and still direct users back up to the happy path in order to accomplish their unique goals.

A fresh, new, entirely connected interface

Designing a user-friendly prototype and conducting usability testing

With more refined sketches in hand, we put together a design kit and created wireframes of some essential screens. In considering how each one would connect, we left some room for further discussion, development, and development before putting together a working prototype.

This design kit was based on Diffbot’s pre-existing design systems, with some elements designed by me. Working off their original color palette, we added more elements in orange, and upped the contrast in colors. It was important to make sure we designed for accessibility, and had enough contrast and flexibility for a responsive design.

Our biggest design consideration: we are building an interface that allows users to troubleshoot independently. This means connecting users with edit options, settings, advanced options, and tools that were previously hidden or entirely disconnected. Instead of creating a straightforward, problem-free path for our usability testers, we built in several types of errors to see how they would solve them.

One of our additional key design considerations was to include multiple ways of viewing the extracted data. Our final working prototype connects Extract with the ability to edit API rules. Our goal with usability testing was to find out if these features would function properly and make a difference in the experience. Though the platform would mostly be used by developers on desktops, it was still key to be sure the design would be responsive to any viewport size. Allowing the extracted data to appear top to bottom rather than left to right would accommodate a stretch test.

Our usability testing was run with five people, one current Diffbot user and four software developers who had never touched the program. Each came from unique backgrounds but were all familiar with the concept of running extractions or web crawls. After bringing our testing notes together, we found several unified insights.

“I don’t like it when it feels like the computer is lying to me.”
– Test User (referring to second save button)

Some of these findings are unique to new users, because seasoned Diffbot users would understand the basic terminology and navigation. It was still imperative to remember our Efficient Engineer and think about new users while reconsidering elements of our design.

So moving forward, we came up with a few iterations we would recommend for the Diffbot team to take.

1. Use the error page as an educational opportunity

   • Communicating clearly to show that it isn’t user error

   • Using a neutral or encouraging message to create a more positive experience overall

   • Leading to clear next steps, either with more explicit buttons or that offer more explanation

2. Change the second save button into a feedback message

   • Providing a clear message with copy such as “your changes have been saved” would feel more trustworthy to users

   • Adding clear messaging will help users understand what is happening so they can feel in control as they use the tool

3. Add more tool tips

   • Presenting helpful information on specific APIs, advanced settings, etc.

   • Taking advantage of opportunities to teach users and help them familiarize with the tool

   • Considering the non-expert users that Diffbot hopes to attract and retain

Looking back and looking ahead

Wrapping up with final reflections and next steps

To close up this project, we presented our research and design to Jerome, Head of Growth and our main point of contact at Diffbot, and to Mike, the founder and CEO. We enjoyed sharing our research and design processes with them and getting to know even more of their long term goals and company dreams in follow-up conversations.

Mike emphasized wanting this new interface to be able to be understood by non-developers alike. Our strongest recommendation was to add more tool tips and pointers to give direction and definition to each step of the way.

We also presented the design to other design colleagues, who agreed that the new tool seems straightforward and simple to navigate. The interface design considers both experienced and brand new users, developers and otherwise. As the developers work on integrating our design choices, we hope to see updates on the business impact.