Background

We had made improvements to the model building process in the original Addy redesign, but it was still a complex process, having between 7 and 11 steps depending on the user’s selections.

While it was easier to build models, it was still far from a quick win for first time users.

The Idea

Since starting at TenPoint7, I’d spent months thinking about how to simplify the model building process without sacrificing the flexibility and control that made Addy unique. By this time, I’d built many Addy models myself, and almost every model I built followed the same flow:

1. Name my model

2. Input data through web search only

3. Enter my query, no boolean

4. Conduct search, skim results

5. Ingest the top 200 results

6. Set a 1 year date range

7. Review and click build

Reflecting on how automatic this process had become for me, I had a thought - What if we determine the average best settings for the most common use case (building a model with a web search), and automatically apply them behind the scenes?

The more I thought about this, the more I thought it could work as an alternate build method. That way, the process would be quick and easy most of the time, but for power users and special cases, the fully customized model option would be available.

I pitched it to the Addy team (U.S.) as “quick search”, and everyone agreed that this would be a real game changer. We couldn’t think of any reason it wouldn’t work, and the lead data scientist was certain it was feasible, so the feature was green-lit. At the time, the redesign was still in development, and the CEO decided that Quick Search was essential for our official product launch. With less than 3 months until launch, this became my new top priority.

Designing the Feature

Initial Concepts

The idea was to reduce the build process to a simple web search, the results being a topic model. All that was needed was a text input. This let us take advantage of a design pattern familiar to users - search bars.

Because the model would still take about 10 minutes to run (though the engineering team was working on ways to optimize quick search to reduce this), I included the option to preview results before building, which is a required step in the original build flow.

Feature Location

One of the first questions that needed to be answered is where this feature would exist within the application. The point of the feature is to avoid the tedious build process, so it would not go there. That left the home/project page, or within a model. Putting it with the model view didn’t make sense either, so the link to Quick Search would have to go on the homepage somewhere.

To make a new project (and a model within it) the user would click on a button labeled “New Project”, so one idea was to also have a “Quick Search” button. The CEO wanted Quick Search to be highly visible, so I also considered putting it in the navigation bar, which would make it omnipresent.

The other idea that I had was to use the same tabs that are used in a project to switch between models, but in this case, they would switch between Quick Search and the user’s projects. When I presented my initial sketches to the team, this is the version we decided to go with. This clearly separated Quick Search from the traditional process of starting with a new project, and by making it the first tab and thus the new homepage, it would be impossible for users to miss.

Compatibility with regular models

At the same time I was thinking about where to put Quick Search, I also had to figure out where to put the Quick Search models in relation to the user’s Projects.

In the existing structure, naming, tagging, and filing a model within a project was done at the beginning. When a model didn’t come out as intended, or wasn’t useful, that effort was wasted. Because of this, I had envisioned users first creating and viewing the Quick Search model, and then deciding if they wanted to save it. If so, that was when they could name it.

This raised another question - if Projects are basically just “folders” for models, could we have models separate from projects in the same way that Google Drive files can exist outside folders?

The Addy team discussed this idea, but ultimately felt it was too big of a change to include in our upcoming product launch, but it might be right for a later release.

Saving Quick Search models after they’ve been completed also raised further issues. If the user navigates away, how would they get to it again? Will users have to then put the model into an existing project? What if it didn’t fit into any and they needed to make a new one? Will it be lost if they accidentally closed the tab?

It still felt important to not make the user name and categorize it upfront, so after a brainstorming session, we decided to automatically name models after the user’s search terms. Every user would have a Quick Search project, which is where the models would be saved. Then, I added the ability to move the model to another project.

Taking advantage of model wait time

Traditional Addy models take between 15 minutes and 2 hours to run, with the intention for users to start it, leave it and do something else, and then come back to view the results. Because Quick Search models were going to take about 10 minutes to run, it seemed like there was an opportunity to keep users engaged in the app until their model completed.

At this time, students were our primary target audience, so my first thought was gamification. I suggested adding a simple snake game, which went over well with the team. The developers quickly found some open source code for it, and added it.

As a team we discussed other things users might want to do in the meantime. One idea was to embed the training videos we had on the Addy website. We decided to add the videos that show users how to interpret their results. Around this time we were also working on adding supervised learning options, so we considered adding an option for them to start that process, but didn’t include it since that feature was too premature and wouldn’t be in this release.

Testing - Quick Search becomes Quick Build

After the team had made decisions on which versions we were going to move forward with, I began on the mockups. Because we were short on time, I tested the design internally, using interns and coworkers who weren’t on the Addy team. These went well. With the search bar being such a familiar design pattern, everyone knew immediately what to do.

However, this familiarity also posed an issue: the expectation of speed. People expect a web search to be nearly instant, but Addy’s Quick Search took 10 minutes. Relatively, Quick Search was far faster than building a model the other way. But in calling it a “search” and using the search pattern, it seemed incredibly slow.

So, we decided to take the word “search” out and instead call it Quick Build. This made more sense, since it’s not the search that is quicker, but the build process. This doesn’t solve the speed issue, but it does at least reframe the feature, and nod to the fact that the Quick Build search creates an NLP topic model rather than a list of URLs.

Final Mockups

Development

This time around, the handoff was really simple. Once I had finished the first rough sketches, I emailed them to the front end development team for input. They were excited about the new feature, and didn’t see any feasibility issues aside from the model/project grouping mentioned previously.

For the final, hi-fi mockups I again used Zeplin. Because the design used the same components as the rest of Addy, aside from Snake, development went more quickly than expected. Within days, we could test it for functionality, and within a couple weeks, the UI was fully implemented.

Results

Quick Build launched with the product in January 2020. We started ramping up marketing campaigns in February, and then in March, amid the COVID-19 crisis, the company, unfortunately, dissolved.

After launch, 82 new users build at least 1 Quick Build model.

• In the initial beta launch in early 2019, 0 users created a model without having a session with a TenPoint7 analyst.

• Of the 100 or so post-launch user sessions I observed with Hotjar, only 2 people built a non-Quick Build, customized model.  

Reflection

While I never quite got to do a full assessment of our post-launch success, I believe Quick Build played a large role in the successes we did have. Because it was easier to understand than the original build process, it was used in product demos and marketing materials.

If a model has been built incorrectly, it doesn’t come out right and the rest of Addy doesn’t impress. With our January release, the original build process had been much improved, however, it still required a significant time investment to start creating decent models. On the other hand, Quick Build was essentially fail-proof, increasing the odds of a positive first experience with the app.

Anecdotally, our 2 long term users from the original beta product loved it. Internally, coworkers used Quick Build almost exclusively, though our analysts sometimes needed the extra control of the regular build process. To my surprise, the addition of Snake was most enthusiastically received by some of our older executives, leading to some fun internal competition.

I’m proud of the work I did on Quick Build, and I would have liked to have been able to continue to improve it though ongoing user research and iteration.