Launched in July 2016
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.
- Simplify search across Origin by showing all results
- Support multiple categories of results at once
- Provide consistent search experience no matter where the user is in the application
- Future proof search by making a flexible system that would allow any new type of result to be displayed
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.
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.
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.
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.
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.
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
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.
- Sometimes the simpler solution is better for both your team members and the users
- Search can be more complicated than it initially seems, especially when you need to account for multiple types of results
- Modular systems are awesome
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.