A lot of UX candidates are going to self-select out from this description, because you're bringing them in too late in the process. You're assuming that the requirements that someone (who?) has come up with are remotely correct, and an experienced UX person knows that's nearly never the case. (Perhaps you have a well-validated stack of customer and market research completed! But I'm going to assume that, like most product teams, you don't.)
Industry studies have found that features and product ideas developed in isolation are wrong, 1/3 to 1/2 or more of the time, where "wrong" is defined as "doesn't move the needle in the way it was expected to."
An experienced UX person is going to want to come in before requirements, to help collect the requirements through understanding users and use cases, and to do the "variety of design concepts" at that stage, often even with active participation from dev, PM, and other stakeholders. (You'll see this called "design studio" or other types of participatory, facilitated design.)
Metrics and measurements are also best developed at that stage, and actively tested to make sure the concepts will affect them in the way everyone expects.
You may be having trouble because "taking" requirements is often something only done by production designers: people who make the final graphics for implementation.
You might have the best success by visiting your local design meetups and looking for a freelancer or consultant with at least several years of experience doing design research, user research, and facilitation, the more experience the better. Hire them to vet and interview candidates; they'll want to understand how your team works and what your expectations for the role are.
Listen to them if they suggest your expectations are misaligned with regards to an effective design process.