The ideal candidate experience and our recommendation for the RFP

Improve hiring for San Francisco
7 min readDec 26, 2017


Over the past 3 months, we’ve been committed to spending most of our time with our key users (candidates, hiring managers and HR professionals). Moving forward, we will of course continue to prioritize those engagements, but we have taken a small break from them to translate our findings into ideal user scenarios and thinking through how they might inform the structure of the RFP.

In a perfect world, what would it look like for someone to apply to a job at the City and County of San Francisco?

Let’s take Sarah as an example. She is a data analyst looking for a more impact-oriented job.

The first place she goes to look is LinkedIn. She searches for data analyst roles in the Bay area, adds the keyword “impact” and sees an opportunity to work with the City and County of San Francisco (CCSF) listed alongside data analyst roles at other organizations across the Bay Area.

She decides to look at the CCSF job more closely, and realizes there are several departments hiring data analysts.

She learns more about each department’s mission, size and projects. Then she reads on to learn more about CCSF’s perks, which include a wide selection of health/dental/vision benefits, professional development and a retirement plan.

Rough sketch of what a data analyst job page might look like

All this information is displayed while demonstrating what other roles at CCSF exist with similar minimum qualifications in case she is interested in exploring her options further. In Sarah’s case, some examples might include: statistician, quantitative analyst, business analyst or program manager.

Sarah decides to apply to a data analyst role. She clicks “apply”.

She can choose to fill out her application, or she can apply with one click with LinkedIn.

During her application, she is prompted to select which departments she is interested in applying to. She can select “all departments” or only a few if she is interested in particular sectors/departments. In her case, she’s interested in all departments, so she selects “all departments”.

Sarah is asked to confirm that she meets minimum qualifications, and is asked to self-certify she meets the numerous minimum qualifications. Examples of these could be:

  • You have a Bachelor’s degree. Y/N
  • You have three years of professional work experience as a data analyst. Y/N

Sarah meets the minimum qualifications. She immediately receives confirmation that she has passed this important step of the process, and is immediately assigned a point of contact via email and/or chat.

Rough sketch of her confirmation, and a friendly face congratulating her on completing her application. We imagine the use of Intercom here.

Sarah is invited to take an online exam as part of the civil service requirements. She signs up online, and completes the exam at a time that is convenient for her.

Sarah passes the exam, and is contacted by departments who are interested in interviewing her.

She confirms an interview time online.

Embedded scheduling straight from the applicant tracking system or email by using Calendly.

Sarah comes in for an interview and receives periodic email updates, especially what we call “no-update updates” just to let her know she hasn’t been forgotten and that her application is still being reviewed.

If at any point a department decides to move forward with another candidate, she is informed of this and is offered to explore other roles at the city.

At any moment, she can either reach out to her main point of contact if she has any questions or concerns. She can also log-in to the applicant tracking system to track all the jobs she’s applied to, see the status of the application, and what the next step is.

Sarah is offered an electronic conditional offer letter from a department and is asked to complete a few steps before she can start working. This might include:

  • Background check
  • Medical checks
  • Fingerprinting
  • Verification of education and employment

All of which she can complete and schedule, in one place, from her pre-employment portal.

Once she is ready to move forward, she will electronically sign her offer letter!

But how would this actually work?

We’re using Sarah’s narrative to anchor us in external user needs. Our thought process is: let’s first offer the best possible experience to candidates, then work backwards from there. But we also know that this absolutely needs to work for hiring managers and HR professionals (however unrealistic this may seem at first).

We’ve started mirroring Sarah’s story from the perspective of hiring managers and HR professionals since we know that those narratives are where all the the mechanics of this lies. Most of the work we have so far looks like a series of logic flowcharts demonstrating how if one thing happens, this is what would happen next. We’re still working through this with some key internal government HR experts to make sure we’re on the right path and proposing realistic changes. We’re also focusing most of our attention in process and systems changes, knowing that civil service rule changes take longer to implement (though these conversations are happening as well).

Our recommendation for the RFP

If we think back to our first blog post, we described this project as having three phases:

  1. Experience mapping: collecting all the research we need to have really good problem definition (September/early October)
  2. Process refinement: ideation and prototyping (~October/November)
  3. Tech and procurement scoping: implementation based on what tools are available to us today and what the various key constituents need (~December/January)

We are currently in the middle of the third phase — which, now that we’re 3 months into the project, we can more appropriately re-frame as: our RFP recommendation. The context here is that the contract for the current applicant tracking system is expiring soon, and the City is preparing for what’s next.

Based on all the research, meetings, conversations and small prototypes, our recommendation is to adopt a phased approach to procurement. This approach is also often referred to as modular procurement. And it can be defined as:

“an acquisition strategy that breaks up large, complex procurements into multiple, tightly-scoped projects to implement technology systems in successive, interoperable increments” — 18F

Key benefits

  • It is an approach that can help reduce vendor lock in, mitigate risk, and encourage the delivery of working software to users more rapidly

Key must-have

  • Requires strong internal coordination

Things we’re keeping in the back of our minds during this process

We realize that this type of strategy cannot be implemented in a vacuum and there are some key questions we need to keep top of mind. They include:

  • How does this impact the procurement process, and the procurement team?
  • How do you effectively manage/coordinate multiple contracts simultaneously?
  • How best to hold vendors accountable and ensure they don’t just point fingers at one another?
  • How do you make sure the code is consistent and compatible while using multiple vendors?
  • What skills will be needed in-house over time to own this technology solution since the needs might be evolving?
  • How do you create the culture where people aren’t afraid to try something new?

We’re proposing the City use the service module framework we introduced in an earlier blog post (and that has become a foundation for our work) to think through various elements and pieces of software that could be acquired in a staggered manner to slowly implement changes and to appropriately learn and adjust as needed. Here are some rough sketches of the service modules, and the various software components that would allow us to get closer to Sarah’s narrative:

Brainstorm of services and products with San Francisco’s Chief Digital Officer Carrie Bishop
Brainstorm of service modules and software

You could imagine a world where the first RFP released is one that pertains to “Getting the word out” and it involves a combination of:

  • listing all the jobs the City is hiring for, and allowing candidates to search, browse and subsequently apply
  • distribution capabilities beyond the City’s job website so the City can more easily get its postings in front of targeted audiences
  • analytics to track applicants by distribution source
  • customer support to answer any questions posed by candidates as they start the application process

Once we had that running and were learning about what was/wasn’t working, we could then move forward with the next module and incorporate the lessons learned into that RFP.

Of course this is a simple synopsis of what this path forward could look like — there are still a lot of details that need to be worked out — but we’re excited about the initial feedback we have received about this approach and to have the opportunity to continue working on it!

What’s next?

More on additional prototypes we’re running and how those lessons are continuing to inform our recommendation for the RFP. As always, if you have questions or concerns, feel free to reach out at:

-David and Monique

Monique Baena-Tan is Researcher and Service Designer for the Hiring Modernization Project. Most recently Monique led design research on Code for America’s talent initiative which included a job board to help technologists find opportunities in public interest tech, and documented best practices across the country in government hiring.

David Huebner is Project Manager and Strategy Advisor for the Hiring Modernization Project. He most recently worked at Code for America where he led a talent initiative focused on helping governments improve their people practices to ensure they can hire and retain technologists to deliver services most effectively. Previously, David worked at Google as a Manager on a strategy, analytics and effectiveness team focusing on hiring and people services.



Improve hiring for San Francisco

Stay up to date and learn how we are collaboratively improving the government hiring process