Operating on different levels

Weeknotes #12: Aug 10–14, 2020

This week was a tough one. I was trying to operate at several different levels at the same time, and was really struggling with it.

This post was influenced in part by this post by Indi Young — We Can’t Fit More Research in Our Cycle.

A few days before I saw her post, I was struggling to try to explain how we do different research in the problem space (what could we do) as in the solution space (how should we do it/did we do it right). Of course, Indi was more eloquent than I could ever be.

“It also takes a completely different mindset to define scopes of research studies based on the problem space rather than the solution currently under construction.”

In my current role, I’m bouncing around and trying to do it all. And as a result, I’m not doing any of it to the standards I expect of myself.

1a. Supporting development teams

At the most tactical level, MyTC Oversight has two development teams that are working on products. This past week we got to play around with the QA build of the app. There were some UI bugs, but also it was the first time I’ve really dug in to work through the app. I have some questions about some of the current flows in the app, and believe we have some opportunities to improve the usability of the app.

As with any development effort, we have limited resources and time, so we have to be sure we’re prioritizing what’s most impactful, it can be easy to get caught up in “small cosmetic tweaks” and lose sight of bigger changes that can make a real difference. But how do we make those decisions? I broached the need to “provide evidence” to my designer. Where did his suggestions come from? How could we demonstrate that this would have a real impact on the UX?

From what I’ve seen, this team has been pretty engineering-driven so far. “Design” is about how the thing we’ve already decided to do should look and feel. It’s not about deciding how something should work, much less whether or not the user even finds value in what we are going to do. Not to say those discussions aren’t happening, but from what I can see, UX hasn’t been at the table.

The impact here is pretty limited. You can make an app really attractive, but if it’s not valuable, or usable, it’s not going to be super successful. And with our limited resources, we’re not going to make the case for prioritization cosmetic changes unless we have a way to demonstrate some ROI.

1b. Supporting shared components

For many good reasons, Transport Canada is looking at developing and leveraging shared components (products) across different development initiatives. So for example, our two development teams may contribute some of their work back to other teams across the organization.

Before I started, eight “common products” were identified to be re-used across different projects. Currently a lot of projects are championed by a specific program or mode (Aviation Security, Marine Safety, etc). The implications of switching to this shared approach is that we’ll want to be sure that we are building components that can support the needs of these different segments.

There are some clear opportunities for research here, and then even more importantly, ensuring that the relevant development parties are bought into including the needs of different segments when scoping and delivering their work.

So perhaps even more important that the research insights themselves, this may be about how to make the case that factoring in the differing needs upfront is a worthwhile investment. To be honest, I’m concerned that we are underestimating the cost of building these components to be robust and flexible. I think the returns will come in the long-term, with some short-term pain. Are we resilient enough (and/or committed enough) to get through the hard stuff?

2. Focused project work

It’s also recently come up that I may have the opportunity to really dive into a strategically significant project. This is kinda my bread-and-butter; I led several investigation projects at ReadyTalk. I love the ability to be laser-focused on one thing and de-risk things, to assist others in making informed decisions.

But, if I’m leading this project, how am I supporting my ‘real’ team?

3. Strategic planning and coordination

My first few weeks at Transport Canada, I was asking to come up with a research plan, which then mutated into a deck I was supposed to present to some stakeholders. Just this week I got back feedback that my deck wasn’t at the right level.

I had created the deck as a bit of a personal playbook: Focusing on the inspector experience, I’ll work in short research cycles, we can revisit the backlog of research questions regularly, we’ll focus either on research to support a given user journey/job to be done, or a given component (see 1b above). I was purposely focused on the activities of research rather than the specific topics to research, in part to allow us some flexibility to be responsive to new information or opportunities.

Instead, I was asked to provide a project plan outlining specific research topics, and not to be limited to focusing on inspectors. I cautioned the person I received feedback from (there was a bit of telephone, as I heard of the feedback indirectly) that doing that would prevent us from being very responsive to new findings and opportunities. I also raised the concern that I was only one person, so if we were committing to a research roadmap, we were looking pretty far out before we could consider anything new. The response to that was that perhaps I could leverage research done by others — or even task some of it out.

While this sounds amazing— I’d love to oversee a user research practice at Transport, especially focused more in the problem space — I’m just not sure how I can manage this coordination as well as doing all the work mentioned above myself.

The hardest part is that this is really the level I aspire to be working at. I’ve helped establish teams and processes at other (albeit smaller) organizations. I want to be operating at this level, but I’m acutely aware that it’s the MyTC Oversight / Digital Oversight team that has brought me on to support them. I don’t want their work to suffer if I’m focused on different activities.

Alas, that was week 12 at Transport. Lucky week 13 is my birthday week, and I’m taking some time off and diving into some overdue onboarding training I have to complete. So some of these items will simmer, and hopefully I’ll have more clarity after my break!