Scoping work and understanding internal users’ needs

Monthnotes? April 2021 :-)

It turns out that the work I’ve been most interested in since starting at the Canada Revenue Agency has been focused internally.

They’re the projects that haven’t been really clearly defined. A request comes in, and then as we start to investigate, more layers reveal themselves. The scoping and framing becomes the bigger unknown.

When we are confident in our craft and processes, it can be easy to rush in. We conduct user testing. We prototype screens. We report on results. We know how to do these things efficiently.

But sometimes the bigger question is why. Are we confident that we’re focusing on the right thing? How do we believe our work will impact our users?

On some projects, we’re still working on a by-request basis. But if you know me, you know that the last thing I want to be is an ‘order-taker’.

Rather, my goal is to support programs in gathering data about current user behaviour and challenges. That can help them recognize the need for improvement. [Should we do something]

Then once that need is identified, we can kick off more specific research focusing on what specifically should be improved. [What should we do]

Then design happens, and we test again, so we can be confident that our design solution is an improvement. [Did we do it right]

If we wait too long until a request comes in, we may find that someone is already attached to a specific solution, and it can be hard to make the case to take a step back to perform generative/exploratory research.

So I like coming in early. But sometimes that means making the case for why we need to do research. (If you don’t know yet that you need to do something, why do research?)

I’m doing my best to overcome objections before they even arise:

• We can handle a lot of this, so the barrier of “we don’t have time” is overcome.
• This isn’t a commitment to change, it’s simply data-gathering. We are starting to collect information, which will make it easier when it does come time to spin up a project.

Having these sorts of conversations reminds me of my time at Worldways, when I was often working with clients who were far more concerned with achieving public health outcomes than the nuance of what we were doing with their web presence. The focus was on how we could help them be successful, without adding too much (work or risk) to their plate.

When we’re passionate about our field, it can be easy to get excited about the nuance: to educate on the how. But that’s just how we make the (veggie) sausage. We need to be sure we’re keeping focused on what is important to our internal clients.

Of course, it’s not always that easy. On another project I’m on, I’m struggling because my user-oriented focus doesn’t really resonate with what they’re looking for. They are focused on de-risking a possible tech solution: they’re way down in the “are we doing it right” stage, and looking at it through a tech feasibility lens.

The challenge here is how much to try to sell something the client doesn’t want. If the biggest risk to a project is technical feasibility, then that should be the focus. We shouldn’t just jump to the approaches we know and believe they’ll bring us success. To use a weak analogy (because I’m also making dinner while typing this), we can’t assume that just because we throw certain ingredients into a pot, they’re always going to result in a good meal.

So yeah, so far the projects that have been the most compelling so far are the ones where the role of UX hasn’t been clear-cut. Instead, its more about intake: understanding what the team is dealing with, and identifying ways we may be able to help.

It’s a far cry from mocking up wireframes in a design tool, and I kinda love it :-)