Origin Search

Launched in July 2016

About Origin

Origin is a PC game platform by Electronic Arts that allows users to purchase, download, and keeps installed games up to date. The service also supports social features like chatting with friends and broadcasting their gameplay to Twitch.tv.

About the Project

In 2016, we were redesigning the Origin client and decided to take this opportunity to fix an issue with how users found content on the platform with search.

The Problems with the Previous Search feature

The existing search feature was contextual to the page that you were on. The store search only searched the store, the filter in your game library only worked there, and finding another user was somewhere else entirely. We also wanted to add new search results to the client, but didn’t have a place for those results to appear.

Our Goals

Why this matters to the business

We want the app to be as streamlined and intuitive as possible, especially if the user may be trying to purchase a game. By simplifying the system, users are also less likely to get frustrated with the application and exit it. They can’t purchase content if they are not in the app.

Why this matters to the users

Intuitive and useful search results is expected. Having to find the right search field to get the results you are looking for is confusing, unnecessary, and degrades the perceived quality of the service.

Outcome of this Project

We shipped a future proofed search feature that provides users all the results they could want in a single place.

Team composition

My Role

As the lead designer on the project, I oversaw the entire project from concept to completion. My specific tasks included performing competitive analyses, user flows, sketching, creating low and high fidelity mockups, participating with user testing, documentation, and project sign off.

Additional Team Members

  • 1 Visual Designer / Prototyper
  • 1 User Researcher
  • 1 Producer
  • 2 Engineers
  • 1 QA Tester

The Design Process


This project started with a kickoff meeting with the project’s producer who filled me in on the goals, time frame, limitations, and business objectives. Our initial plan was to include several new types of search results to the existing three that we had. Later on in the project, the scope was reduced due to engineering bandwidth limits. I continued to design a modular solution that would ensure that we could easily add the other search categories back in without any design changes.

Search categories

Your games
Store Content
Store content
Other users
Other users
Future categories
Other secret
future things

Researching the Problem Space

In order to familiarize myself with the best practices of search, I did competitive analyses on a wide range of websites and apps that utilize search. I was specifically looking for examples that showed multiple categories of results since we had already established this as a core requirement of the project.

What I Learned From My Research

I noticed that there were two general ways of displaying results from a search. The first is a drop down list of autocompleted results and the other is a landing page of results. Any drop down list of autocompleted results always had a landing page, but not the other way around.

Another pattern I noticed when a site or app returned a list of results with multiple categories was that each section would only have a few results. They would often provide an indication that there were X more results on a different page. This pattern would later make it into the final design.

Brainstorming and Whiteboarding

The next thing I did was to map key user flows. This helped me establish what screens I would need to design and make sure that I covered all use cases.

High level user flow for the new origin search

I then worked out a flow of low fidelity mockups on a large whiteboard that I had in my cubicle. This allowed me to explore what the user would see in each step without worrying too much about the visual fidelity. It also made it much easier to call over the producer or another designer on the team to review the project and sketch out modifications or other ideas.

Iterating the Designs

Once some ideas had been flushed out reasonably well, I started creating high fidelity mockups in Sketch. I did a few different versions of the search results as I refined the experience.

After doing a few rounds of revisions on how to best present the search results, I ended up with a design that used a drop down list of predictive results. If the user hit Enter with the search field selected, it took them to a full page of results.

Search field provides a drop down list of autocompleted results

Why I Chose this Solution

The list of suggested results help the user by providing recognition rather than recall because they don’t need to enter in the full product title to see it. The list of results easily works well on mobile. Keeping the suggestions in the list kept the user in the context they were previously in and allowed them to click out of the search field to dismiss the list of suggestions. Content density was also very high.

Tweaking the design to help engineering hit their deadline

During a review with the Producer, he proposed an interesting question. “Why do we have both the search results page and the drop down if they show mostly the same content? Could we remove one of them?” The engineering team was overloaded at this time with work and he was looking to cut scope from any project.

He was right. The drop down and the search results page were doing duplicate work and one could go. We could combine both the live search results from the drop down with the full page of results by taking over the main content on the page when the user entered text.

I had not seen a full screen takeover of search results with multiple categories during my competitive analysis. Since this seemed like an uncommon behavior, I wanted to run this design through user testing to see if there were any usability issues with this experience.


As I was finalizing the mockups, the visual designer on the project was busy building out the prototype to my specs. The Origin team used prototypes as a handoff to engineering for visuals and animations as well as for user testing.

We ended up building two similar prototypes to test. Prototype A would update the main view of the client as the user typed in text, updating the entire view with search results. Prototype B was the initial design that had a drop down list of suggested results where hitting enter took you to a full page of results.

User Testing

With the assistance of our user researcher, we ran two rounds of 1 on 1 user testing. The first being primarily aimed at testing prototype A’s full screen search vs prototype B’s drop down list to see if users understood prototype A and which one was more useful. The second round of user testing was to verify fixes from the first test and identify any other remaining problems.

The results of the user test told us that users preferred the full screen of search results. They had no problem understanding the page updating and how to return to where they were before performing the search. Users felt that the full screen of search results was faster, more efficient, more interesting, and offered more content than the alternative.

This was a huge win for us. Not only did people prefer prototype A because they found it more useful, but it also helped cut down on our development time!

User Testing Results

Average feedback was higher in all categories for Prototype A


Origin client showing results for 'Sims'


The new version of search shipped when we launched the redesign of Origin in 2016. Users now could easily search one spot and get a live updating list of search results. Due to its modular design, any type of new content in the future will fit in without needing a redesign.

Lessons learned

Try it out for yourself!

You can go give this feature a spin at origin.com.

Note: you will need to log in to see all the search result categories.