Spreading the Peanut Butter Too Thin?
Weeknotes: June 22–26, 2020
This was a big week.. and I’m not sure that’s really a good thing. Going to follow a common “weeknotes” or “retro” format identifying Roses, Buds, and Thorns.
Rose = something that is working well or something positive
Bud = an area of opportunity or idea yet to be explored
Thorn = something that isn’t working or something negative
🌹Rose: Actually Doing Research!
I dove in and was able to conduct 6 interviews with inspectors this week! I really love learning about what people are trying to get done and how they approach it, so we can aim to improve on it.
I started creating a map using Whimsical after just a few interviews, and then used that as a basis for other conversations.
Without going into any specifics in this post, I was able to identify different systems or approaches people take depending on the context of their work. This will help us avoid trying to design a ‘one-size-fits-all’ solution that doesn’t really work for anyone.
🌱Bud: User Research Repository
Not wanting to lose the actual verbatims of the people I spoke with, I also started a research repository in Notion. I’d worked on a structure for a repository when I was back at LexisNexis, but never really committed to it. I believe there’s even more merit to having such a repository here, due to the different clients, products and use cases we will be supporting. Being able to go back and retrieve information across different studies will help us be able to apply learnings to future projects. For example, I have a colleague planning to do research on hardware devices. Some of the interviews I conducted included some mention of hardware. Being able to tag that information so that my colleague can go back and review it for his project will be really helpful!
I know that this isn’t a super exciting idea to a lot of people, but I think it’s a huge step in democratizing research and ensuring what we learn in one interview or study isn’t lost when that investigation wraps up.
📌Thorn: Too much to do!
This week my manager advocated for me to take part in two different working groups for projects that are kicking off. I also had meetings with POs/BAs for two other projects that are already underway.
While I’m SUPER excited that I’m being brought to the table for some of these projects early on, I’m a bit worried about spreading the peanut butter too thin. I just came off a fellowship where my small cross-functional team was dedicated to a single project, and we were able to make a LOT of progress because we were so focused.
One of the reasons we were able to make a lot of progress was because we knew we had limited time and resources. We tracked our progress regularly, and reported on it to keep ourselves honest. (Following one of the Government of Canada Digital Standards to ‘work in the open’).
It’s inevitable when you introduce more people, more schedules and more priorities, things will drag out. I’ve been having one meeting a week with several different teams, and then there is a lot of lag between meetings. I can’t help but think that instead of trying to balance multiple projects at once and have them drag on, there are benefits to focusing on one thing at a time before moving onto another.
That’s how I know I work best, and I went into this weekend feeling very overwhelmed, knowing I have a lot on my plate and not sure how best to manage my time. Within a given project there’s always prioritization that has to take place, and it’s harder when you’re balancing work across multiple projects.
Which… *cough*.. may be why this concept of dedicated product teams has caught on..?
In addition to just helping with momentum, cross-functional teams can help with ensuring that UX is involved with shaping what gets built.
Currently, there seems to be a bit of a Goldilocks effect here when we ask when we should bring in UX. When is it TOO SOON and when is it TOO LATE?
This is another reason why dedicated teams working closely makes sense. If UX is working with the business and IT folks to develop the backlog, there are no surprises. We can work together to ensure we’re meeting business, technology AND human expectations.
Often, we focus on what the business asks for, and how quickly we can release something. But how can we set requirements and estimate timelines if we haven’t considered (through actual user engagement) how best to address the users’ problem?
Again, product teams that include User Experience from the outset before establishing requirements and development estimates seem to do better, but I’m not sure that doesn’t require a different mindset than the current project-based work we typically see in government. I hope to find out I’m wrong!
