CASE STUDY
8 Minute Read
Empty State Framework
Creating a framework for more consistent and constructive empty state experiences
CASE STUDY
8 Minute Read
Empty State Framework
Creating a framework for more consistent and constructive empty state experiences
CASE STUDY
8 Minute Read
Empty State Framework
Creating a framework for more consistent and constructive empty state experiences
Summary
About
Objective
Improve user experience and SEO performance by improving how empty states are handled on the platform.
Outcome
A framework for handling empty states was established, consisting of guidelines, UI patterns, and microcopy templates. New empty state experiences were subsequently implemented across >40 scenarios.
Role
I lead the project from conception to implementation, working with a product owner, product manager, and UX designer. The work presented represents my individual contributions.
Skills Applied
Data analysis, design system audit, wireframing, UX writing, project management
Summary
About
Objective
Improve user experience and SEO performance by improving how empty states are handled on the platform.
Outcome
A framework for handling empty states was established, consisting of guidelines, UI patterns, and microcopy templates. New empty state experiences were subsequently implemented across >40 scenarios.
Role
I lead the project from conception to implementation, working with a product owner, product manager, and UX designer. The work presented represents my individual contributions.
Skills Applied
Data analysis, design system audit, wireframing, UX writing, project management
Users Can't Find Us on Search
As part of a wider push to improve SEO performance, I was tasked with looking into how we might reduce the prevalence of so-called soft 404 errors that prevented many of our pages from being indexed by Google.
By reducing the number of pages classified with such errors, we hoped to increase the pages through which new users could find us via search, and ultimately improve organic traffic to our site.
Soft 404 errors occur when Google encounters a page that loads successfully, but is missing main content.
Such pages are not indexed and are consequently not discoverable through search.
Users Can't Find Us on Search
As part of a wider push to improve SEO performance, I was tasked with looking into how we might reduce the prevalence of so-called soft 404 errors that prevented many of our pages from being indexed by Google.
By reducing the number of pages classified with such errors, we hoped to increase the pages through which new users could find us via search, and ultimately improve organic traffic to our site.
Soft 404 errors occur when Google encounters a page that loads successfully, but is missing main content.
Such pages are not indexed and are consequently not discoverable through search.
Users Can't Find Us on Search
As part of a wider push to improve SEO performance, I was tasked with looking into how we might reduce the prevalence of so-called soft 404 errors that prevented many of our pages from being indexed by Google.
By reducing the number of pages classified with such errors, we hoped to increase the pages through which new users could find us via search, and ultimately improve organic traffic to our site.
Soft 404 errors occur when Google encounters a page that loads successfully, but is missing main content.
Such pages are not indexed and are consequently not discoverable through search.
Pages with Almost No Content
Analyzing Error Reports
I started by analyzing a sample of error reports generated by Google Search Console to get an initial understanding of the problem.
I found that a large number of URLs were affected (>25,000), and that a single page type—what we termed Entity Pages—accounted for a large proportion of such errors (~41%).
Entity Pages functioned like profile pages on social media sites, but for companies instead of people.
Each page consolidated various types of information related to a specific company that might be useful to investors.
Pages with Almost No Content
Analyzing Error Reports
I started by analyzing a sample of error reports generated by Google Search Console to get an initial understanding of the problem.
I found that a large number of URLs were affected (>25,000), and that a single page type—what we termed Entity Pages—accounted for a large proportion of such errors (~41%).
Entity Pages functioned like profile pages on social media sites, but for companies instead of people.
Each page consolidated various types of information related to a specific company that might be useful to investors.
Pages with Almost No Content
Analyzing Error Reports
I started by analyzing a sample of error reports generated by Google Search Console to get an initial understanding of the problem.
I found that a large number of URLs were affected (>25,000), and that a single page type—what we termed Entity Pages—accounted for a large proportion of such errors (~41%).
Entity Pages functioned like profile pages on social media sites, but for companies instead of people.
Each page consolidated various types of information related to a specific company that might be useful to investors.
Manual Inspection
Next, I inspected a sample of pages classified with soft 404 errors. While the availability of content varied across affected pages, in the most extreme cases, users would be confronted with a bare page that seemed like it perhaps failed to load.
Manual Inspection
Next, I inspected a sample of pages classified with soft 404 errors. While the availability of content varied across affected pages, in the most extreme cases, users would be confronted with a bare page that seemed like it perhaps failed to load.
Manual Inspection
Next, I inspected a sample of pages classified with soft 404 errors. While the availability of content varied across affected pages, in the most extreme cases, users would be confronted with a bare page that seemed like it perhaps failed to load.
A page with missing content
Encounters with such a page might lead to poor impressions of the coverage, usefulness, and reliability of our site on a whole, especially for new users.
A page with missing content
Encounters with such a page might lead to poor impressions of the coverage, usefulness, and reliability of our site on a whole, especially for new users.
A page with missing content
Encounters with such a page might lead to poor impressions of the coverage, usefulness, and reliability of our site on a whole, especially for new users.
How a page was designed to appear, with all content available
Within each Entity Page, different types of content (e.g. research articles, financial metrics, company announcements, news articles, user comments) were organized into separate sections that users could navigate to using the sidebar and tabs.
Most content was displayed within a center panel on the page, while some information was displayed as “widgets” docked to the right rail.
How a page was designed to appear, with all content available
Within each Entity Page, different types of content (e.g. research articles, financial metrics, company announcements, news articles, user comments) were organized into separate sections that users could navigate to using the sidebar and tabs.
Most content was displayed within a center panel on the page, while some information was displayed as “widgets” docked to the right rail.
How a page was designed to appear, with all content available
Within each Entity Page, different types of content (e.g. research articles, financial metrics, company announcements, news articles, user comments) were organized into separate sections that users could navigate to using the sidebar and tabs.
Most content was displayed within a center panel on the page, while some information was displayed as “widgets” docked to the right rail.
Consulting with Subject Matter Experts
I then spoke with relevant colleagues in the firm to get a better idea of how these pages were created and where the content was from.
I learned that in most cases, Entity Pages were automatically generated to ensure comprehensive representation of companies around the world (with new ones added all the time).
Importantly, almost all the content on these pages were populated dynamically from sources over which we had little direct control, namely external APIs and user-generated data.
Lastly, the empty state experiences themselves were often not explicitly designed. Instead, they tended to be implemented in an ad-hoc manner during the development of designs that assumed full content availability.
I worked with a data analyst to understand the current extent to which dynamically populated content in each section of the page could be unavailable, leading to an empty state.
We found that across all live Entity Pages, content unavailability varied widely between sections, ranging from low (<2%) to very high (>90%).
Almost half (~48%) of the pages did not contain any research articles—our main offering.
Consulting with Subject Matter Experts
I then spoke with relevant colleagues in the firm to get a better idea of how these pages were created and where the content was from.
I learned that in most cases, Entity Pages were automatically generated to ensure comprehensive representation of companies around the world (with new ones added all the time).
Importantly, almost all the content on these pages were populated dynamically from sources over which we had little direct control, namely external APIs and user-generated data.
Lastly, the empty state experiences themselves were often not explicitly designed. Instead, they tended to be implemented in an ad-hoc manner during the development of designs that assumed full content availability.
I worked with a data analyst to understand the current extent to which dynamically populated content in each section of the page could be unavailable, leading to an empty state.
We found that across all live Entity Pages, content unavailability varied widely between sections, ranging from low (<2%) to very high (>90%).
Almost half (~48%) of the pages did not contain any research articles—our main offering.
Consulting with Subject Matter Experts
I then spoke with relevant colleagues in the firm to get a better idea of how these pages were created and where the content was from.
I learned that in most cases, Entity Pages were automatically generated to ensure comprehensive representation of companies around the world (with new ones added all the time).
Importantly, almost all the content on these pages were populated dynamically from sources over which we had little direct control, namely external APIs and user-generated data.
Lastly, the empty state experiences themselves were often not explicitly designed. Instead, they tended to be implemented in an ad-hoc manner during the development of designs that assumed full content availability.
I worked with a data analyst to understand the current extent to which dynamically populated content in each section of the page could be unavailable, leading to an empty state.
We found that across all live Entity Pages, content unavailability varied widely between sections, ranging from low (<2%) to very high (>90%).
Almost half (~48%) of the pages did not contain any research articles—our main offering.
We Need a System
Framing the Problem
From my investigation, I concluded that there were a few separate issues:
Unpredictable content availability due to a reliance on external and user-generated data sources
Structural constraints of the user interface which did not adapt elegantly to content unavailability
Poor empty state experiences which confronted users with bare screens and “dead ends”
No established processes for handling empty states which lead to inconsistent and piecemeal implementation
Following discussions with stakeholders, we decided to focus on improving existing empty state experiences and processes (points 3 and 4), due to a reluctance to making larger changes at this time.
We Need a System
Framing the Problem
From my investigation, I concluded that there were a few separate issues:
Unpredictable content availability due to a reliance on external and user-generated data sources
Structural constraints of the user interface which did not adapt elegantly to content unavailability
Poor empty state experiences which confronted users with bare screens and “dead ends”
No established processes for handling empty states which lead to inconsistent and piecemeal implementation
Following discussions with stakeholders, we decided to focus on improving existing empty state experiences and processes (points 3 and 4), due to a reluctance to making larger changes at this time.
We Need a System
Framing the Problem
From my investigation, I concluded that there were a few separate issues:
Unpredictable content availability due to a reliance on external and user-generated data sources
Structural constraints of the user interface which did not adapt elegantly to content unavailability
Poor empty state experiences which confronted users with bare screens and “dead ends”
No established processes for handling empty states which lead to inconsistent and piecemeal implementation
Following discussions with stakeholders, we decided to focus on improving existing empty state experiences and processes (points 3 and 4), due to a reluctance to making larger changes at this time.
Proposal
Taking inspiration from design systems approaches, I proposed creating a lightweight framework of reusable UI patterns and guidelines that would cover the most common empty state scenarios.
This way, we could not only improve empty state experiences on the Entity Page (and in doing so, potentially reduce soft 404 errors), but also make inroads towards ensuring more consistent and constructive empty state experiences across the entire site.
Establishing a framework would also contribute to more systematic implementations of future empty state experiences, while reducing repetitive design and development effort.
Proposal
Taking inspiration from design systems approaches, I proposed creating a lightweight framework of reusable UI patterns and guidelines that would cover the most common empty state scenarios.
This way, we could not only improve empty state experiences on the Entity Page (and in doing so, potentially reduce soft 404 errors), but also make inroads towards ensuring more consistent and constructive empty state experiences across the entire site.
Establishing a framework would also contribute to more systematic implementations of future empty state experiences, while reducing repetitive design and development effort.
Proposal
Taking inspiration from design systems approaches, I proposed creating a lightweight framework of reusable UI patterns and guidelines that would cover the most common empty state scenarios.
This way, we could not only improve empty state experiences on the Entity Page (and in doing so, potentially reduce soft 404 errors), but also make inroads towards ensuring more consistent and constructive empty state experiences across the entire site.
Establishing a framework would also contribute to more systematic implementations of future empty state experiences, while reducing repetitive design and development effort.
I planned the project to proceed through 4 phases:
Audit: Collect and analyze current empty state instances and behaviors
Ideation: Propose, iterate on, and review possible solutions
Planning: Prioritize delivery according to development cycles and resourcing
Design: Create final assets and deliver them in batches
I planned the project to proceed through 4 phases:
Audit: Collect and analyze current empty state instances and behaviors
Ideation: Propose, iterate on, and review possible solutions
Planning: Prioritize delivery according to development cycles and resourcing
Design: Create final assets and deliver them in batches
I planned the project to proceed through 4 phases:
Audit: Collect and analyze current empty state instances and behaviors
Ideation: Propose, iterate on, and review possible solutions
Planning: Prioritize delivery according to development cycles and resourcing
Design: Create final assets and deliver them in batches
Work plan diagram
Work plan diagram
Work plan diagram
Taking Inventory
Audit of existing empty state experiences
To maximize the breadth of use cases that the proposed framework could accommodate, I conducted an audit of all content sections within 4 page types, for 4 of our major account types (a total of 16 scenarios). I set out to observe and record:
What content sections were susceptible to content unavailability
The current empty state behavior in these sections
The range of reasons for content unavailability
The 4 pages (including the Entity Page) were chosen because they were the top entry points for organic traffic.
I repeated the audit for each of our 4 major user profiles as the site served different experiences depending on the user's account credentials (no account, free account, private investor account, professional investor account).
Taking Inventory
Audit of existing empty state experiences
To maximize the breadth of use cases that the proposed framework could accommodate, I conducted an audit of all content sections within 4 page types, for 4 of our major account types (a total of 16 scenarios). I set out to observe and record:
What content sections were susceptible to content unavailability
The current empty state behavior in these sections
The range of reasons for content unavailability
The 4 pages (including the Entity Page) were chosen because they were the top entry points for organic traffic.
I repeated the audit for each of our 4 major user profiles as the site served different experiences depending on the user's account credentials (no account, free account, private investor account, professional investor account).
Taking Inventory
Audit of existing empty state experiences
To maximize the breadth of use cases that the proposed framework could accommodate, I conducted an audit of all content sections within 4 page types, for 4 of our major account types (a total of 16 scenarios). I set out to observe and record:
What content sections were susceptible to content unavailability
The current empty state behavior in these sections
The range of reasons for content unavailability
The 4 pages (including the Entity Page) were chosen because they were the top entry points for organic traffic.
I repeated the audit for each of our 4 major user profiles as the site served different experiences depending on the user's account credentials (no account, free account, private investor account, professional investor account).
Excerpt of audit spreadsheet
I collected the data by through manual observation of pages on the live site using a test account, recording my observations in a spreadsheet.
Excerpt of audit spreadsheet
I collected the data by through manual observation of pages on the live site using a test account, recording my observations in a spreadsheet.
Excerpt of audit spreadsheet
I collected the data by through manual observation of pages on the live site using a test account, recording my observations in a spreadsheet.
Classifying reasons for content unavailability
Applying a simple clustering method, I found 5 higher-level scenarios that the proposed framework should address:
Requirements not met: The user does not meet the requirements to see the content
No matches found: The user’s query does not return any matching results
Content doesn’t exist: The content that the user is looking for does not currently exist
Content is unavailable: We don’t have the content that the user is looking for, but it may be available elsewhere
Content not offered: The content is not being offered at the moment, but may be offered later
The audit covered a total of 83 distinct scenarios (content section x account type combinations), of which 72 (~87%) were susceptible to missing content and hence empty states, albeit to varying degrees.
Of these 72 scenarios, there were 49 unique reasons for content unavailability.
Classifying reasons for content unavailability
Applying a simple clustering method, I found 5 higher-level scenarios that the proposed framework should address:
Requirements not met: The user does not meet the requirements to see the content
No matches found: The user’s query does not return any matching results
Content doesn’t exist: The content that the user is looking for does not currently exist
Content is unavailable: We don’t have the content that the user is looking for, but it may be available elsewhere
Content not offered: The content is not being offered at the moment, but may be offered later
The audit covered a total of 83 distinct scenarios (content section x account type combinations), of which 72 (~87%) were susceptible to missing content and hence empty states, albeit to varying degrees.
Of these 72 scenarios, there were 49 unique reasons for content unavailability.
Classifying reasons for content unavailability
Applying a simple clustering method, I found 5 higher-level scenarios that the proposed framework should address:
Requirements not met: The user does not meet the requirements to see the content
No matches found: The user’s query does not return any matching results
Content doesn’t exist: The content that the user is looking for does not currently exist
Content is unavailable: We don’t have the content that the user is looking for, but it may be available elsewhere
Content not offered: The content is not being offered at the moment, but may be offered later
The audit covered a total of 83 distinct scenarios (content section x account type combinations), of which 72 (~87%) were susceptible to missing content and hence empty states, albeit to varying degrees.
Of these 72 scenarios, there were 49 unique reasons for content unavailability.
Creating the Framework
While I was undoubtedly inspired by best practices, I was cognizant that an expansive, enterprise-level approach to design systems would not be appropriate for our small firm.
As such, I sought to propose a lightweight and low-maintenance framework consisting of:
Guidelines for how to handle different empty state scenarios
Modular UI patterns that could be adapted to each scenario
Microcopy templates that could guide more consistent language use
I referenced the books Building Design Systems (Vesselov & Davis, 2019) and Laying the Foundations (Couldwell, 2019) throughout this project.
Creating the Framework
While I was undoubtedly inspired by best practices, I was cognizant that an expansive, enterprise-level approach to design systems would not be appropriate for our small firm.
As such, I sought to propose a lightweight and low-maintenance framework consisting of:
Guidelines for how to handle different empty state scenarios
Modular UI patterns that could be adapted to each scenario
Microcopy templates that could guide more consistent language use
I referenced the books Building Design Systems (Vesselov & Davis, 2019) and Laying the Foundations (Couldwell, 2019) throughout this project.
Creating the Framework
While I was undoubtedly inspired by best practices, I was cognizant that an expansive, enterprise-level approach to design systems would not be appropriate for our small firm.
As such, I sought to propose a lightweight and low-maintenance framework consisting of:
Guidelines for how to handle different empty state scenarios
Modular UI patterns that could be adapted to each scenario
Microcopy templates that could guide more consistent language use
I referenced the books Building Design Systems (Vesselov & Davis, 2019) and Laying the Foundations (Couldwell, 2019) throughout this project.
Guidelines
Existing empty states were typically handled in one of two ways: displaying a stark message describing the state (e.g. "No reports found"), or hiding the offending section altogether.
Neither solution was particularly constructive for users. Additionally, the approaches applied across instances did not appear to adhere to any consistent logic due to their ad-hoc implementation.
To arrive at the proposed guidelines, I mapped the reasons for content unavailability to a proposed logical flow that focused on users' ability to take constructive follow-up actions.
The logic I proposed aimed to offer users the most constructive resolution possible to any given empty state scenario.
In order of priority, I suggested that we:
Facilitate an action to resolve the empty state
Suggest a relevant alternative action
Explain the reason for missing content
Reduce emphasis on empty areas
Guidelines
Existing empty states were typically handled in one of two ways: displaying a stark message describing the state (e.g. "No reports found"), or hiding the offending section altogether.
Neither solution was particularly constructive for users. Additionally, the approaches applied across instances did not appear to adhere to any consistent logic due to their ad-hoc implementation.
To arrive at the proposed guidelines, I mapped the reasons for content unavailability to a proposed logical flow that focused on users' ability to take constructive follow-up actions.
The logic I proposed aimed to offer users the most constructive resolution possible to any given empty state scenario.
In order of priority, I suggested that we:
Facilitate an action to resolve the empty state
Suggest a relevant alternative action
Explain the reason for missing content
Reduce emphasis on empty areas
Guidelines
Existing empty states were typically handled in one of two ways: displaying a stark message describing the state (e.g. "No reports found"), or hiding the offending section altogether.
Neither solution was particularly constructive for users. Additionally, the approaches applied across instances did not appear to adhere to any consistent logic due to their ad-hoc implementation.
To arrive at the proposed guidelines, I mapped the reasons for content unavailability to a proposed logical flow that focused on users' ability to take constructive follow-up actions.
The logic I proposed aimed to offer users the most constructive resolution possible to any given empty state scenario.
In order of priority, I suggested that we:
Facilitate an action to resolve the empty state
Suggest a relevant alternative action
Explain the reason for missing content
Reduce emphasis on empty areas
Logic depicted in a flowchart
Logic depicted in a flowchart
Logic depicted in a flowchart
UI Patterns
Taking inspiration from established design systems, I proposed a simple, familiar, and flexible UI pattern that could guide the design on empty states going forward.
UI Patterns
Taking inspiration from established design systems, I proposed a simple, familiar, and flexible UI pattern that could guide the design on empty states going forward.
UI Patterns
Taking inspiration from established design systems, I proposed a simple, familiar, and flexible UI pattern that could guide the design on empty states going forward.
Component anatomy
I distinguished between "messaging" elements (image, title copy, body copy) and "action" elements (e.g. CTA) within the proposed component.
Component anatomy
Component anatomy
Illustration of possible element combinations
Depending on the scenario and particular constraints, elements could be mixed and matched to establish a consistent approach across devices.
Illustration of possible element combinations
Illustration of possible element combinations
Some early explorations
In exploring design solutions, I worked exclusively with low-fidelity prototypes that could be quickly created and discussed.
Finalized concepts were later rendered to specifications by the UX designer on the team.
Some early explorations
In exploring design solutions, I worked exclusively with low-fidelity prototypes that could be quickly created and discussed.
Finalized concepts were later rendered to specifications by the UX designer on the team.
Some early explorations
In exploring design solutions, I worked exclusively with low-fidelity prototypes that could be quickly created and discussed.
Finalized concepts were later rendered to specifications by the UX designer on the team.
Microcopy Templates
I also suggested sample microcopy templates for the messaging elements to ensure the application of simple and consistent language.
Microcopy Templates
I also suggested sample microcopy templates for the messaging elements to ensure the application of simple and consistent language.
Microcopy Templates
I also suggested sample microcopy templates for the messaging elements to ensure the application of simple and consistent language.
Excerpt of suggested microcopy
I mapped proposed microcopy templates to the scenarios identified by the audit.
Excerpt of suggested microcopy
I mapped proposed microcopy templates to the scenarios identified by the audit.
Excerpt of suggested microcopy
I mapped proposed microcopy templates to the scenarios identified by the audit.
Implementing the Framework
The completed framework was documented in the product team's Notion workspace, which I presented to the product team in a meeting. Following this, I supported the implementation through:
Task management: Prioritizing and tracking the assets to be created in accordance with development timelines
Collaborating on design: Sourcing graphics and providing feedback on high-fidelity UI iterations
UX writing: Writing the final copy for each use case to be delivered
Implementing the Framework
The completed framework was documented in the product team's Notion workspace, which I presented to the product team in a meeting. Following this, I supported the implementation through:
Task management: Prioritizing and tracking the assets to be created in accordance with development timelines
Collaborating on design: Sourcing graphics and providing feedback on high-fidelity UI iterations
UX writing: Writing the final copy for each use case to be delivered
Implementing the Framework
The completed framework was documented in the product team's Notion workspace, which I presented to the product team in a meeting. Following this, I supported the implementation through:
Task management: Prioritizing and tracking the assets to be created in accordance with development timelines
Collaborating on design: Sourcing graphics and providing feedback on high-fidelity UI iterations
UX writing: Writing the final copy for each use case to be delivered
Outcomes
New empty state experiences were deployed across >40 scenarios, with more in the pipeline. In subsequent (unrelated) projects, designers referred to the framework when considering empty states in their interfaces.
Two examples from the live site are reproduced below:
Outcomes
New empty state experiences were deployed across >40 scenarios, with more in the pipeline. In subsequent (unrelated) projects, designers referred to the framework when considering empty states in their interfaces.
Two examples from the live site are reproduced below:
Outcomes
New empty state experiences were deployed across >40 scenarios, with more in the pipeline. In subsequent (unrelated) projects, designers referred to the framework when considering empty states in their interfaces.
Two examples from the live site are reproduced below:
Prompting users to watchlist a company when there are no publications to show
Prompting users to watchlist a company when there are no publications to show
Prompting users to watchlist a company when there are no publications to show
Prompting users to change their search when no matches are found
Prompting users to change their search when no matches are found
Prompting users to change their search when no matches are found
My Takeaways
This project was an opportunity for me to contribute in a larger than usual capacity as a UX researcher. It reflected my attempt to influence not just what experiences are designed, but how they're designed—a perspective that becomes increasingly consequential at scale.
The resulting framework was nothing revolutionary or exciting, but represented a step towards a more mature approach to user experience design for our small team. All the skills I had developed up to this point were tested, especially change management and project management. From my perspective, I’m thankful that the systematic and inclusive approach I honed seemed to transfer quite well.
My Takeaways
This project was an opportunity for me to contribute in a larger than usual capacity as a UX researcher. It reflected my attempt to influence not just what experiences are designed, but how they're designed—a perspective that becomes increasingly consequential at scale.
The resulting framework was nothing revolutionary or exciting, but represented a step towards a more mature approach to user experience design for our small team. All the skills I had developed up to this point were tested, especially change management and project management. From my perspective, I’m thankful that the systematic and inclusive approach I honed seemed to transfer quite well.
My Takeaways
This project was an opportunity for me to contribute in a larger than usual capacity as a UX researcher. It reflected my attempt to influence not just what experiences are designed, but how they're designed—a perspective that becomes increasingly consequential at scale.
The resulting framework was nothing revolutionary or exciting, but represented a step towards a more mature approach to user experience design for our small team. All the skills I had developed up to this point were tested, especially change management and project management. From my perspective, I’m thankful that the systematic and inclusive approach I honed seemed to transfer quite well.