How to Build an Informed End Product

One of my favorite things about working at Azavea is the clients. Nonprofit and public sector groups trust us with their resources to build tools to help them fulfill their missions. This is a privilege I take seriously, in part thanks to the fact that I spent the majority of my career in that sector. I gained a lot of experience negotiating for services with private vendors, particularly through fending off upselling for things my employer at the time couldn’t afford or simply didn’t need/want.

As somewhat of a newcomer to the software dev space, at times it can feel unnerving to be on this side of the table. This is particularly true if I have to communicate to a client that their vision isn’t achievable on their budget, knowing how tight budgets can be. However, having that clarity as soon as possible is critical because it lets us work with the client to consider alternative options within their budget.

Finding value in the user experience discovery process

I’ve found the discovery process is a particularly valuable tool to achieve this level of clarity because it helps get folks aligned on vision (even amongst stakeholders on the client side), distill what’s needed, and identify relevant risks/assumptions so the engineers can build the right tool. Being aligned on the goal with the client sooner rather than later (and even as a step before the full proposal is developed!) means that we’re best positioned to build software that the client and their audience needs, within the available means.

A user experience discovery process is most definitely something my former self would have been quick to dismiss: “But I know what my team/colleagues/stakeholder needs; why would I pay strangers to learn about that?!” or, “that’s taking money away from our development budget, which we can’t afford to do!”

The basics of the discovery process, according to our UX team

Since I’ve had to confront some residual discomfort and challenge myself to understand the value of things I had dismissed previously, I wanted to help folks understand the importance of what’s possible. I had a chat with two of my colleagues on the UX team to learn more about how this process helps us to create the best solutions possible for our clients.

Annie: Catherine and Gates – give it to me straight: does every client need to go through a discovery process?

Catherine: In a word, yes. It can be helpful to keep in mind that discovery is inevitable. All clients will go through a process of discovery, the question is simply, “when?” Clients can choose to understand what their users think before they build, or they can find out what their users think eventually when they release their software. There is no question that it’s better to know what users think before designing, because then the discovery is actionable — there is still room to change the design to make it as impactful as possible. Once the product is built, however, it becomes much harder and more costly to make any changes. 

Gates: Absolutely. Hard problems take time from the budget, but discovery makes them easier to resolve. Our UX teammates are curators of knowledge. They organize and prioritize the important information in order to create with confidence. Discovery gives participants the opportunity to collaborate, express and contribute in open discussion. In the end it saves time and sets realistic project expectations. At times, clients will have their own user experience discovery work completed which we can build off, validate, and apply towards our design work.

Catherine: Put another way: if you want a bespoke suit made, a tailor needs to take measurements and ask for specifications since what they’ll design is based on who will wear the suit and why they need to wear it. Discovery is the process to ensure you don’t end up wearing an ill-fitting scuba suit to your wedding.

Annie: Understanding that user experience discovery is foundational to developing a custom software project, is there a budget-friendly way to pursue it?

Gates: There are varying levels of discovery, design, and development on every project; it depends on the problem they are trying to solve.

Catherine:  We can make discovery happen under any budget. One way we work with people with smaller budgets is to ensure that when we talk to users we evaluate which features are most important to them and what tradeoffs they might be willing to make. That helps us build really efficiently, reducing the budget overall while still meeting users’ expectations. A Kano analysis is the classic way to do this, though there are several methods we can use. Even understanding the feature size (small, medium, or large) from a development standpoint can help us get insight from users into whether they prefer fewer but bigger features or if they’d rather more and forgo a larger lift item. This matters because when the budget is small we need to be certain that we’re building the most important part of the software and making educated tradeoffs to maximize impact. On our Sitka Landslide project, we were able to focus on a simple, straight-forward dashboard that was what users wanted but not what the client expected to hear. Even so, they ended up really happy with the result because the final solution better met their goals since it was informed by end users. 

Annie: Thank you, Catherine and Gates! I really appreciate your team’s commitment to a tailored discovery process, and the extent to which that is the genesis behind impactful products / tools.

If you’re curious about what a user experience discovery process could unlock for you, please get in touch!