FTI Consulting: Ringtail

Screen shot of the Ringatil website

Timeline: June - Sept 2016

Project Type: Internship

My Role: UX Designer + Frontend Developer

Tools: Sketch, Adobe Illustrator, HTML, CSS, Javascript, jQuery

Skills: User Research, Wireframing, Web Development

Context

Designing in the real world!

During the summer of 2016, I had an internship at FTI Consulting as a UX Design Intern. I worked on one of the company's largest enterprise software, Ringtail, a document review program that had millions of active users. Among the many projects I worked on, my main project was to completely redesign the search experience for Ringtail's main website. The company was working on releasing documentation for Ringtail so that it could have the same self-help support system that many tech companies have switched to, abandoning the phone call customer support system.

"Cedric and I worked together on a large project at FTI Consulting. He was given quite a bit of autonomy on a complex task that required a great deal of research, planning, design and implementation (including HTML, CSS, and Javascript). Cedric, as an intern, proved very eager to learn and worked tirelessly to make the final product the best possible experience for our visitors. We were very pleased with his attention to detail and desire to improve everything that came across his desk. I would recommend Cedric as an excellent asset to any company and look forward to seeing what he creates in the future." - Curtiss Patrick

Problem Space

Ringtail was about to get have over 500 pages of documentation but lacked a usable search engine to sift through that massive amount of information.

Previous Solution

The Ringtail search engine consisted of a simple key-word based search bar with results that were labeled by page type. Here's what it looks like when I search "ediscovery" in the search bar:

This is what the website was.

As you can see the search results page is very simple (not a bad thing) and just shows the results that come back. In this case, there are 69 results that a user could potentially have to sift through to find what they are looking for. You can imagine how bad it would be once they added on the 500+ pages of documentation. Their search engine was in desperate need of a filtration system to help target what they are looking for.

User Research

In order to properly redesign the search engine, I had to first understand what types of people would be using it and what their motives would be. After talking to the marketing department and other designers who conducted had usability tests in the past, I managed to aggregate my findings into these user groups:

Document Reviewer: This is the bulk of the users. The doc reviewer's job is to go through each document one-by-one and search for relevant information to the case. Experience varies from 1-10+ years. They would search for standard technical help for Ringtail.

Attorney: Attorneys manage doc reviewers by assigning them bulks of documents to review at a time. They commonly come from a law background. They would need help with the administrative side of Ringtail such as access rights.

Newbies: Newbies consist of doc reviewers who have just started on the job or independent doc review firms that consist of teams of 3-5 employees. They would need help learning the basics of Ringtail and sometimes even the basics of the document review industry.

Inspiration

After getting a strong understanding of the users, I stared looking around at what other websites were doing for their serach experience. There were a lot of different approaches and each one pertained to their specific product or desired experience.

Spotify

Spotify uses instant search results, not just showing a plain list of suggestions, but categorized results. Additionally, each result went straight to the result page, instead of just showing a results page of that search term.

Spotify's search experience

Yelp

Yelp asks for initial criteria before the user even types in their query. This works well because these are very basic filters that help narrow the results. Later on though, the user can add additional filters such as price or ratings.

Yelp's search experience

LinkedIn

LinkedIn uses complex queries within the search term itself to help define initial criteria. These could have only been filter buttons on the search page but they chose to also make it integrated into the text search which I thought was interesting.

LinkedIn's search experience

Wireframing

After getting a strong understanding of the users, I went on to design wireframes for the new search results page. For my first wireframe, I started off including as many ideas for necessary features for filtration as I could.

Version 1

Version 1 of my wireframe.

As each version progressed, I had it reviewed by the UX team each week and got feedback. At Version 4, I started accounting for things such as version number and extra support features. At Version 11, I cleaned up my design to make it less clustered and still maintain the minimal look it had before.

Version 4

Version 4 of my wireframe.

By the final versions, the fidelity started increasing and I started implementing the style guides given to me. And after 12 iterations of creating the wireframe, I finally came to a final design iteration.

Version 11

Version 11 of my wireframe.

Final Version

Final Version of my wireframe.

What I Learned From This Project

This job was quite unique because it entailed both UX design as well as frontend implementation. Because of this, my takeaways from this internship range across both domains.

  • Image lazy loading. This trick helps improve webpage speed by loading images right before they enter the viewport instead of all at once when the page first loads.
  • To get rid of the image flicker when hovered over, I would include the two different images in the same image file and simply change the background position so that there's no flicker at all.
  • I learned about the complexities of implementing filtered search results. I had to figure out a robust system to filter and sort all of the search results I got back since it was all done on the client-side. Many design decisions had to be made such as "Should we do the filtering and sorting on the server or client side?" and "Given the relatively low number of the results [500 is nothing compared to a true serach engine], how does that effect other decisions?"

What I'd Do Differently

This experience was an incredible opportunity to learn a diverse set of skills, but that diversity did decrease my time spent on the design process. My design process and decision should have been much stronger but time was not on my side. Here's what I would have done:

  • While I did conduct user research to understand the background of our users, I think I failed to validate the pain point that users were having with the search page. We simply assumed that given the increase of search results, users would want them to be more organizable. And while that was a pretty justified assumption, I didn't personally see the data behind these insights.
  • Following the previous point, once I had a true understanding of the user's needs, I think I could have done a better job tailoring the design towards their specific goals instead of simply implementing another generic search engine.


I'm so thankful for this company, the people I met, and the things I learned there! Getting this industry experience really helped me grow as an industry designer and overall worker!

Thanks for scrolling!