Let’s be honest. Most clients don’t really know what they are getting into when the hire a UX designer. Many assume that our job is to take the product requirements dictated to us and actualize them through the process of wireframing. And while that is one example of what I might do for a client, it’s not necessarily the best way to utilize your UX team. For one thing, just because I design products doesn’t necessarily mean that I naturally know all the “right” answers for your product. And although clients are often subject matter experts, and a valuable source of insight, that doesn’t necessarily mean that they should be expected to have all the answers either.

UX is more than just executing an idea, it’s defining the problem to be solved and identifying the person for whom you are solving it. This means that you don’t always need to know exactly what you are setting out to design when you hire a UX designer, because we can use the research and design tools at our disposal to help figure that out with you.

But it’s rare that a client will commit to a truly UX-led design process. Why? Because that lack of certainty can be scary. It’s not always clear when you set out on a project exactly what you will learn or how it will shape the end product. (And by the way, this is not only true for clients, but for designers too. This uncertainty is probably the number one source of anxiety that my UX students face when they are just starting out.) You may find that your assumptions get challenged and your vision of the product changes. You may question whether your initial idea is even viable, or whether the audience you thought you would be designing for even needs the thing that you thought you would be designing. You may even have to kill your pet feature because it doesn’t actually solve the problem that needs solving, and that can be a hard pill to swallow.

That’s why I was not just fortunate, but downright lucky to have a client – Canopy – who was willing to go on this journey of uncertainty with me and the design team at Type/Code. I kept track of our activities week-by-week in a diary so I could shed some light on what this looks like, and wrote it up as a case study outlining our process which can be read on Medium

The long and the short of it is this – if you think you need a 2-year roadmap or a product requirements document all figured out on your own before you hire your design team, think again. And if you think design is just a deliverable and not a tool, then you may be missing out on some valuable insights that will inform a better product. Really great things can happen when we admit that we don’t have all the “right” answers from the get-go, and can take the time to find the information we need to deliver the best designs possible.