TL;DR to’do list
This will all make more sense after you’ve read through this entire page!
- Do we want/need to make changes to the URL structure? (Plus related changes to CMS.) If so, when should we do this?
- How feasible is it to have multiple options for content templates, any of which can be applied to a single type of page? Example: on a group page, we can use either content template 1, content template 2, or content template 3.
- Are there answers to the first two questions that let us solve all the challenges mentioned in the doc? For quick reference, those are:
- A group wants to split into multiple groups
- A group changes in some substantial way and wants to change their group page to reflect the new reality
- A person leaves their company
- A person starts with one persona and then adds another, and/or subtracts pervious personas
- We decide we want to create a new type of persona that users can take on
Meta questions:
- To what degree do we rely on our own team to manage the CMS?
- Jackson’s preliminary answer: We rely on them heavily and train them to be experts in managing the site. From the outside, BYA looks like a platform, but behind the scenes it operates like a publication. We can refer to the BYA team that handles this work as the “editorial” team. (This is a very familiar concept to me and I’ve operated these kinds of teams previously.)
- To what extent do we let non-staff (employers, employer team members) edit their own stuff?
- Jackson’s preliminary answer: Relatively little. Idea: people can make their own edits only via a special private ‘admin’ page where we give them access to a select number of linked blocks, mostly text fields. These ‘admin’ pages are created and managed by the BYA editorial team...perhaps even on a 1-off basis.
- How standardized do we want pages to be? How much variation, if any, is OK?
- Jackson’s preliminary answer in two parts:
- For the team profiles that we migrate from the current site, we basically don’t want any variation.
- But looking ahead, my understanding is that there’s a spectrum. On one end, every page follows a super strict template and operates exactly the same. On the other end, pages start from a template but then editors can, at their choosing, re-arrange elements, edit headings, etc. I personally lean towards the later.
Challenges we will face:
- A group wants to split into multiple groups
- Example: A small company with a team profile titled “Early Team @ Small Startup” raises a round of funding. They grow to 100 people and want to split into multiple sub-groups.
- How we’ll handle: ???
- A group changes in some substantial way and wants to change their group page to reflect the new reality.
- Example: We create a simple group page for an employer. Then they want more stuff—and are ready to pay—and we decide it’d be best to make big changes to the group’s page without changing the URL, which needs to remain the same because they’ve shared the page many other places.
- How we’ll handle: ???
- A person leaves their company
- Example: This is pretty self-explanatory. Big note here is that it happens all the time!
- How we’ll handle: ???
- A person starts with one persona and then adds another, and/or subtracts pervious personas
- Example: A company’s team member leaves their company and then joins a different company on BYA! This will happen eventually if it hasn’t already.
- How we’ll handle: ???
- We decide we want to create a new type of persona that users can take on.
- Example: We decide we want to create special pages just for CEOs. These pages have content fields that don’t make sense for other people.
- How we’ll handle: ???
Jackson’s notes on CMS structure
(Please note that I have minimal experience here so please forgive me if I say something dumb!)
I see four types of thing on the platform. Not sure if this is the best way to think about it, but this is how I see it in my mind.
- Groups and sub-groups (only one layer of sub group)
- Small content pieces that can be shared using a unique URL
- People and/or their different personas
- Collections, probably based on tags, of groups, sub-groups, content, and/or people
Before sharing details, a big question I have (but don’t know how to answer) is how this all impacts URL structure. But let’s forget that for a sec. Onwards...
Groups and sub-groups
Multiple page design templates depending on type of group / sub-group. The only one that exists right now is the Team Profile template—and I have no interest in prepping additional templates right now— so these are just examples of what we might want to do in the future:
- Whole-company careers page with info that’s very different from the team profiles that we create today.
- Short-form whole-company page that’s generated by us (BYA) without prompting by the company. We then use the page to entice the company to pay for services. The page also helps with SEO.
Use cases:
- Members of group itself use the page to promote the group. This is essentially what our current customers do, ie: a recruiter shares the page with job seekers in an effort to start conversations with those job seekers.
- When people come to BYA website and start exploring, we want these pages to be easily findable
- SEO
Note: IMO if we do this, we should only have one sub-group layer. AKA: no nesting of tons of layers of groups.
People
Yea, people. I’m mostly interested in how we handle multiple personas. For clarity, I have ZERO intention of racing into any more of these than already exist. Example here are just to illustrate personas we might want to support at some point.
- Contributor
- Team member of an employer
- Agent
- Recruiter / admin / representative of employer
- BYA team member
- Talent / job seeker
Notably, there are different use cases for each type of persona. For some, the person will use the persona for self promotion. In other cases the persona will sit passively and get an occasional hit from an extremely-high-value viewer—which makes it worth it.
Small content pieces
99% of the time, the use-case is sharing on social media. As far as I can think it through, that’s the only reason we need unique URLs here. Some super-specific examples:
- Our customers (employers) share their favorite video clips on social and tag the person in the clip. This can be done by recruiters, or, if the clip is god enough, a company’s marketing team may share it to overall company channels.
- We (BYA) share video clips on social in effort to increase traffic to and engage with high-value people. Again, lots of tagging people. Next level: ask the person’s university to share the clip as a way to promote the success of the university’s alumni. Probably other stuff like this.
- Same as above but sharing ‘updates’ instead of video clips. These updates themselves may take the form of different ‘content formulas’.
Collections
Different kinds of collections, probably based on tags.
Use case: marketing, engagement on social media, SEO, general discoverability.
More or less, I think of collections as tools to draw in specific audiences. Collections aren’t actually listicles, but in some ways they scratch the same itch for their target audience.
Best illustrated by examples. (In parentheses is my guess of how we’d implement)
- Collection of engineering teams (sub groups tagged as ‘engineering’)
- Collection of early-stage companies (groups tagged ‘early-stage’)
- Collection of CEOs (people tagged as ‘CEO’)
- Collection of agents who serve engineers (people tagged with both ‘agent’ and ‘engineering’)
- Collection of video clips that answer “What do you look for in candidates?” where all video clips are of hiring managers of engineering teams (...uhhhh, not sure how to do this but it’d be nice for this to be possible down the road!)
Jackson’s relatively-amateur proposal for URL structure
Please take this with a grain of salt! I’m only including this to help illustrate my thinking (above), not so say that we should do it this way.
Groups
Note: the main use case here is to be able to create an overall ‘careers page’ in addition to pages for sub-teams (if any). Also note that, if a customer only wants a page about a sub-group (ex: engineering team), in this model we would create BOTH a group page and a sub-group page for the company. However, the group page (for the overall company) would be mostly empty and un-used—and possibly hidden?—until we decided to flesh it out.
- Generic: beforeyouapply.com/group/[group-name]
- Example: beforeyouapply.com/group/instacart
Subgroups
Note: main use case here is to be able to create a sub page for a specific team. This’ll mostly be useful for large groups/companies.
- Generic: beforeyouapply.com/group/[group-name]/[sub-group-name]
- Example: beforeyouapply.com/group/instacart/engineering-team
People
I actually have no idea how to do this. AFAIK the question comes down to: can people have pages that encompass multiple personas, or can pages only handle one persona and, thus, if someone has more than one persona, they’ll have multiple pages.
- If people pages can encompass multiple personas, then I think this would work? Maybe?!
- Generic: beforeyouapply.com/user/[username]
- Example: beforeyouapply.com/user/jackson-solway
- But if people pages can only cover one persona, then I guess we end up with different URL conventions for each persona. For example...
- Contributor persona:
- Generic: beforeyouapply.com/contributor/[username]
- Example: beforeyouapply.com/contributor/jackson-solway
- Agent persona:
- Generic: beforeyouapply.com/agent/[username]
- Example: beforeyouapply.com/agent/jackson-solway
- Employee (team member) persona:
- Generic: ?
- Example: ?
Small content pieces
Note: these examples depend on group and user URL conventions addressed above.
- For a sub-group:
- Generic: beforeyouapply.com/group/[group-name]/[sub-group-name]/[content-title]
- Example: beforeyouapply.com/group/instacart/engineering-team/what-is-instacarts-tech-stack
- For a person:
- Generic: beforeyouapply.com/user/[username]/[content-title]
- Example: beforeyouapply.com/user/jackson-solway/what-i-did-last-summer
Collections
I have very little confidence about these URL conventions. Mostly just trying to illustrate my thoughts here :)
- For different kinds of groups
- Generic: beforeyouapply.com/collection/groups/[group-slug]
- Example: beforeyouapply.com/collection/groups/unicorns
- For different kinds of sub-groups
- Generic: beforeyouapply.com/collection/sub-groups/[group-slug]
- Example: beforeyouapply.com/collection/sub-groups/engineering-teams
- For different kinds of users
- Generic: beforeyouapply.com/collection/users/[group-slug]
- Example: beforeyouapply.com/collection/users/ceos
Summary:
I’m suggesting we make use of an in-house editorial team to manage the BYA website. This editorial team manages the site like a publication (behind the scenes) even though users perceive BYA as a network of groups and people. The editorial team take more liberties with page design and content on a 1-off basis but generally acts with restraint.