How to write a UX ITT/RFP/RFQ?

As an agency, we see a lot of requests for proposals (ITTs, RFQ, …). The quality of these RFPs differs greatly and seems to be directly linked to the level of UX expertise of the person who wrote it. Having said that, it is not impossible to write a good UX RFP if you are not a UX expert. Just make sure you follow these do’s and don’ts:

Do: 

• be very clear on what you want the outcome of the project be. A clear goal allows bidders to define a UX methodology that achieves your goal in the best possible way and shortest time possible (and thus lowest cost). 
• be clear on what you would like your target users to be able to achieve. If possible, define this as something that can be measured, such as, “We would like our users to complete all steps in under 2 minutes”. 
• involve a UX expert in the proposal review process, especially for assessing the merits of the proposed methodology. If you are not an expert, then you do not really know what you are buying so ask for help from somebody who does. If you have UX experts in your organisation, great. If you don’t, consider hiring a contractor for a few days. Cannot do either of these? Please read the next bullet point.
• insist that bidders include the rationale behind a proposed methodology and how it will result in the desired outcome. This is especially important if you do not have a UX expert in your evaluation panel. Without a written rationale it is very hard for a non-expert to determine why one methodology is better than another. Just because we are all users does not make us experts in user research and design. 
• give bidders enough space (e.g. a word count of 2000) for writing their answers to all questions. Limiting the number of words makes the review process quicker and easier but also makes it very hard for a bidder to get all the essential information across. The cost of the extra time needed to assess more elaborate proposals is negligible compared to the cost of the whole project. However, choosing the wrong supplier because of lack of information will be very costly. I am not just thinking of the cost of the project but more of the potential loss of revenues, higher user support cost, etc.

Don’t: 

• define the UX methodology (e.g. conduct 6 focus groups) you would like the winning bidder to execute. Most organisations outsource UX research and design because they do not have the skills in-house. Chances are that, if you are not a seasoned UX expert, you will define a methodology that will not give you optimal results. Leave it to the experts! Even if you are a UX expert then I would still recommend not to include the methodology. The methodology the bidder proposes is what sets one agency apart from another and is a great way to test whether they actually know what they are talking about.
• include trivial requirements such as: It needs to be ‘easy-to-use’. In my 25 years of experience I have yet to come across a project that asked for an experience that was ‘difficult-to-use’.
• place too much importance on the bidder’s experience in your domain. Good UX research and design is based on facts and not assumptions. The buyer is the domain expert and the bidder is the UX expert. Knowing a little bit about the domain will make communication easier but knowing a lot increases the risk of making assumptions which are, with hindsight, wrong and could have been avoided with a bit more user research.
• specify a project duration of less than 4 weeks. Four weeks is already very tight even for the most basic project. Often this is made worse by the time taken by the onboarding process or delays in the review process. Usually, the start date suffers delays but the project end-date stays the same. This greatly increases the time pressure on the winning bidder.