top of page
Screenshot 2023-11-27 at 2.03_edited.jpg

Meta  |  Workforce  |  Jobs Tool

Navigation
Terminology

Project overview

THE problem

Jobs Tool is internal-facing software designed to help retain software engineers by making internal job movement within Meta easier. A new user group was introduced to Jobs Tool, creating a need for role-specific content. My job was creating new user onboarding content for Track, a feature within Jobs Tool that allows users to track communications related to their job search. This included in-product guidance that is specific to each user group. An important part of this project was using correct terminology to direct users to the correct help content.

 

  • How do we lead users with different but overlapping options to the correct guidance content based on their role?

  • Can we find terminology that is concise and jargon-free?​

  • Getting project partners to agree on terminology.

  • Choose terminology that would minimize the need to update supporting documentation–choose something that will stick.

THE Challenges

Process 

Project onboarding

I joined the team after the redesign of Track was updated for the new user type, so I was not around for the redesign and I had questions. To better understand how to solve the problem I did some self-onboarding.

Screenshot 2023-09-08 at 1.35.25 PM.png

I familiarized myself with the project by:
 

  • Auditing products to understand terminology and identify existing content patterns.
     

  • Reviewing data and research decks to gain user empathy and understand behaviors.
    .

  • Meeting with program partners gain a deep understanding of different user types.
     

  • Consulting with the designer who worked on the UI to understand the reasoning behind interactions within the flow.
     

  • Worked with content designers from other products to understand the usage of terminology, with an eye toward the future.

Thoughts after onboarding:
 

  • Related products grew without content guardrails and the use of terminology is inconsistent.
     

  • Terminology that refers to the two user types is grounded in HR jargon and confusing.
     

  • Need to understand content strategy moving forward so I can use the most up-to-date language, or the best language going forward.
     

  • UI was designed without content input and created UX issues. What's the best way to work around this?
     

  • One user type has more options. Does showing both pieces of information cause confusion?  Has there been user testing? What was the result?

Screenshot 2023-08-31 at 1.04.58 PM.png

Synthesis & solution

Clarifying questions​

​

  • User types were referred to inconsistently throughout the product mostly using HR jargon. How can I avoid adding to this stew without an overall strategy in place?
     

  • Creating consistency in terminology or gathering consensus was out of the scope of this project. What language can I use that's consistent and will clearly communicate to the users which information pertains to them?
     

  • All users can view the information in both tabs. With only content as a solution, how can I make clear which information is relevant to each user type?

​

Iterating on terminology

Group 17.png

Current terminology

Pros:

  • Status quo

  • Aleady used in product and support content.
     

Cons: 

  • HR Jargon, not understandable by anyone outside of the HR sphere.

  • Users don't talk about themselves this way.

Current terminology

Pros:

  • Status quo

  • Easy approval from partners.

  • Already used in product and support content.
     

Cons:

  • Unclear​ to users unfamiliar with Meta processes. 

  • Jargon

  • Not true, and it doesn't account for edge cases.

  • Users don't talk about themselves this way.

Screenshot 2023-10-19 at 12.23.20 PM.png

Process oriented

Pros:

  • Based on research, this is how users actually talk about the process.

  • Clear explanation of the choices available to achieve user goals.

  • "Applications" describes the process and also refers to a feature within the product.

Cons:​

  • "Conversations" is not specific enough. Conversations with who? 

  • Not used in product and support content, would require re-work to create consistency.

Employee types

Pros:

  • Relatable to users within Meta.

  • Research shows that users describe themselves using these terms.
     

Cons:

  • Divisive since one group has more choices, and can be perceived as more valued.

  • Doesn't address edge cases.

  • Not used in product and support content, would require re-work to create consistency.

Final Content

Feature names

Since agreeing on consistent terminology for user type names was far out of the scope of this project, and given the limitation of engineering or UI design work to create an optimum solution, the best move forward was mapping the header terminology to existing feature names.

Group 19.png

Pros:
 

  • Maps to features within the product.
     

  • Users are familiar with the feature functions.
     

  • Terminology already vetted and agreed upon by product and HR partners.
     

  • Hardcoded, and not to likely change.
     

  • Less complex rework of supporting documentation.

​

Cons:
 

  • Does not address which features are available and unavailable to particular users.
     

  • Does not negate overlapping information within tabs for one user type.
     

  • Requires modification, but not a full rework of supporting documentation.

In context

waystopreparetrackscreen.png
Group 19.png

What I woulD Do Differently

I wasn't around to see the results of this project, so instead I'll offer alternative solutions that I think would've made the project better from a design/systems perspective.

Involve content design from the beginning

This project was designed without content design involvement. When content was added to the UI, there were a lot of big UX problems that I brought forward, but nothing could be done since the project was complete from an engineering and UI perspective. This led to content being the only solution for problems that arose, which led to non-ideal outcomes. Had content been involved from the get-go, the solutions would've had less user friction, better usability, addressed all edge cases, and been a more elegant visual and informational design.

Solutions I would've brought forward early in the design process:
 

Engineering
I'd suggest users see information and options that apply to them based on their profiles. This would negate confusion about "Which option applies to me?", and serve content to the right user in the right place at the right time. Reducing the choices and the amount of overlapping and inconsistent terminology would reduce cognitive load.
 

Information architecture
Regardless of terminology, I think the entire sidebar of help content should not exist on this screen.​

  • Increases cognitive load with confusing choices and decreased focus on primary tasks.

  • ​The help content on this screen is redundant since this information exists elsewhere.

  • Tabs side by side that include only slightly different information is confusing.​​​​

  • Instead of creating redundant and inconsistent content, and would suggest linking to existing content. 

    • Would promote consistent terminology, and best practices.

    • Would simplify the screen for better usability.

    • Reduce the amount of places to track and update when information changes.​
       

Terminology consensus 

Gaining program consensus about terminology would be a better use of CD resources. Even though the task is large and out of scope, working towards getting systems straight is worth the effort and should be prioritized rather than adding to the problem. Testing content would be a large part of this effort.

​

​

bottom of page