top of page
Screen Shot 2023-08-13 at 10.44.28 PM.png

To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study.The information in this case study is my own and does not necessarily reflect the views of WorldPay from FIS

Overhaul of Site
Search

For a 28,000-member
portal without touching the back-end code – Front-end UX changes only.

Stakeholders    

VP of IT, COO

Roles 

UX Lead, UI Design Lead, UX Researcher

Team                           

Myself, BA, QA 

Target Audience

YPO members (CEOs – worldwide business leaders) and their spouse/partners, Internal YPO employees, Chapter Administrators

Timeline

Six Months

Introduction + Background

There had been a significant number of complaints about Search "not working" on YPO's primary member portal, the Exchange, and it had become so routine that time was allotted, it seemed, for every iteration to install rushed patches to fix the loudest squeak. It's important to note that every digital interaction a member has with YPO either goes through the Exchange or connects to it, so performance or lack thereof was a significant issue. Therefore, the situation was such that I was asked to look into it to discover why and then fix it. It should also be noted that I was mandated that there could be no engine rewrite. Back-end code was off-limits, and that was non-negotiable. 

So, I started to dig into the issue, and the first discovery was that the team had made incorrect assumptions that failure was due to poor UX by my predecessor., This complaint, it seemed, had been a recurring theme for some time. However, after completing a cursory review and speaking with users, it was easy to see it needed work, but sloppy UX was just a piece of the problem. What I uncovered I lumped into these categories:

Problems Discovered

Dated Engine and Enormous Tech Debt

  • The engine driving the experience needed to be updated and configured for what was being requested by the user. 

  • Multiple iterations of "lets-see-what-sticks" solutions created compartmentalized Information Architecture (IA) and layers upon layers of spaghetti code.

Out-of-the-Box Templates

  • Content was mapped to one-size-fits-all templates rather than user-informed designs.  This resulted in poor pattern recognition,  forcing users to relearn the UI for each category search results.  

  • Due to the rigid template layouts, search results appeared improperly hierarchically.

Content Without a Clear Purpose

  • Creation of content for very niche scenarios, compounding IA problems.

  • Lack of thoughtful, purpose-driven content.

  • A misalignment of content to the most commonly used search terms.

Little to No Prior User Research or Proper Planning

  • UX research consisted of assumptions.

  • HIPPO influenced.

  • Prioritization of work was a patch-the-leak method instead of being more data-driven.

Silo-izaiton of Search

  • Search mapping reflected YPO employees' internal workflows and organization charts. It dictated biases from member committee chairs rather than user behavior (each dept was headed/advised by a member committee chair, and chairs changed hands each year by-election). 

  • The lack of a long-term vision drove poor IA, creating isolated and disassociated pockets of irrelevant information.

  • Territorialism compounded the issue by departments catering to the goals of singular member chairs of a department. 

Research and Validation

Determining User Behavior

To understand how the search was used and how it was expected to work by the users, I conducted user research with 27 in-person interviews and 62 emailed surveys.  This information was then compared with raw analytical data, developing a picture of users' search behavior. I discovered YPO's members and their Spouse/Partners came to "the Exchange" for five primary reasons, and this is what heavily drove their search patterns and expectations:

  1. Find and connect with other Members or Spouse/Partners.

  2. Find, track, and register for events.

  3. Research other chapters and their recent activities.

  4. Find network (interest-based "clubs") information.

  5. Documents and articles – resource library.

Seeing that user behavior in all aspects was very task-driven, it made sense for the search experience to be a facetted one, allowing the user to target a specific singular goal.  This meant affording the user the ability to pre-select one of these below categories to search on:

  1. All - Default setting that is equivalent to a general search and returns will be shown by relevance regardless of category.

  2. People – List of members, spouses, and family; their information and demographics of record.

  3. Events – Information regarding the over 800 unique YPO hosted events held each year.

  4. Communities – Research showed that users search patterns were similar with the Chapters as it was for the Network (no. 3  and 4 respectively as mentioned above). Therefore, a new category was created named Communities with sub-categories of:

    • Chapters – Information, promotion of chapter pride to encourage healthy competition.

    • Networks – Communicate network ongoings or research a network prior joining one.

  5. Resources – YPO writes and curates 1000 pieces of content, including an extensive video library which had not been previously  indexed until this initiative.

These are some first draft wireframes showing the ability to pre-select a category for a new search concept.

The Solution

A comprehensive solution for the first problem, tech debt, wouldn't happen because of limited resources, dollars, and headcount, and explains the mandate to not "touch the code." Yet, not being able to tackle the real culprit, the backend code, felt like we had hit a brick wall until some wise teammates asked this question:

Instead of forcing the back end to struggle to serve up what we know it can't  can we have it serve up what we know it can and only allow that to be entered?

It seems common sense, but this was a game-changing ah-ha moment.   The engine was not entirely broken per se as it still made meaningful connections. The problem was how it was displaying them so that a result set made sense to a human or , rather, a YPO member. 

Not Like its Brain Surgery

An easy analogy to make is to think of it like a patient with a traumatic brain injury (TBI).  With some TBI's connections are damaged making speech clunky or nonexistent because even though the idea still forms in the mind, the mouth does not get the right signal to turn the thoughts into words.   Because of the way search had been implemented and developed over the years we had a similar problem and the solution just like patients with TBI, proved to also be similar.  Doctors found with TBI patients that when presented with a common list of ideas or words to pick from, they could more easily recognize and in turn connect a thought, which kept a conversation going. So that became our solution– control an input so the backend can connect to predefined common searches, displaying the results quickly and  more organized for the uniqueness of a YPO user.

Mapping Content to Design was Key

The old system was built using out-of-the-box result set templates and returned to the user by keyword searches in the order they were found in the various YPO databases.

Old Search Result Set
Old Search Result Set – Showing a search for "Pinkerton" yielded everything but the desired result.

Mixing the results could be visually confusing. That was a fundamental flaw in the previous schema. The user could not tell at a glance if a result record was a directory or an event. Therefore, the pattern recognition for each category had to be carefully crafted to keep the result set scannable yet identifiable. This was accomplished by designing each record category to be individually recognizable but similar enough so that the user knows they are search results when seen together. I liken it to a baseball uniform. Each team has a unique uniform, so they will know who to throw the ball to. However, if seen outside a ball field, it's easily recognizable that they are wearing a baseball uniform, and yet just as easy to know which team they belong to. So if a member searched for an event and performed a general search returning records from all categories, the system must provide them a method to identify which of the results is the category they searched for to drill in confidently, all the while reassuring the them that they are indeed viewing a complete and coherent search result set. 

Hierarchial placement of content into a common patttern across catgegories
Via hierarchical placement of key content and use of color, a pattern was established that allowed for individual classification of a result set category while maintaining enough similarity to understand on a whole that the user was viewing a search result set. 

However, even though the design for each category must be unique, the content design, as stated above, must be uniform on the whole. For example, on a Directory search, the first and last name is the primary essential information for that search category. So, each result has the first and last name in the exact location, font, size, and color, allowing the user to find and process that information quickly. It's the same for the remaining topics as well. The primary pieces of information in each category are identical in font, size and color to help establish pattern recognition and given the "LINE 1" association as shown below. The second most important information for that category was assigned to LINE 2 and so on in the same manner (LINE 3, 4, etc.) for the remaining categorical content.  To help accomplish this, we enlisted the help of the Audit and Education department. We held a two-day taxonomy workshop, where the most common search categories were identified, organized, and mapped.

Mapping of content to design schema.

 

These same departments were also the primary keepers of site content or a majority of it. Therefore, this workshop also reviewed, wrote, and suggested content management or creation solutions. Some of them being implemented immediately, while others were placed on a roadmap to be addressed when appropriate. Now, at least, we had a content framework into which to a mnew search paradigm could evolve.

 

The remaining issues centered mostly around culture and policy. The courage it took to bring some of the concerns to light was acknowledged, and that change was needed. However, just like content from the workshop, some were implemented right away, while some were to be considered later. The rest can be viewed as a victory simply because they were acknowledged. 

Mapping of content to design/code schema.

Conclusion

The multifaceted challenges of this project brought a transformative journey to enhance the member's experience by addressing valid UX concerns, which were expected by the team, and delving into underlying technical and content issues that needed to be addressed. Our solution of a general search and individual searching the core pillars - Directory, Events, Chapters, Networks, and Resources - aligned with user needs, optimizing the search experience. We refined backend output capabilities by strategically directing user input, enabling quick and coherent results. The experience was further enhanced through revamped templates and uniform content design, improving pattern recognition for greater user efficiency. Collaboration with relevant departments to streamline content was critical for success and catalyzed a cultural shift towards user-centricity. This case study underscores an approach to complex holistic problem-solving that resulted in an improved Exchange that resonated with users and set a precedent for future collaborative endeavors.

Success Metrics

48%

Increase in Search Accuracy

77%

Increase in Search Usage

92%

Overall User Satisifaction

Let's Chat

469.369.5821
scotty@scottypulley.com
bottom of page