How to shine as a UXer (when the problem is too complex for your BAs)

AKA: High level journey mapping for cross team collaboration

Sometimes, onboarding at an organisation as a UXer means twiddling your thumbs for a little while as you figure out exactly how you can assist.

This can be because:

• The business case for your project is still being built
• The organisation is still immature when it comes to user experience as a practice
• There’s just so much work that it’s up to you to understand the immense scope of work ahead

I walked into my current role where all these things were true. The project lead was still building the business case and not in a position to specify the function of their newly hired UXer(me). The organisation had a strong UX presence, but that existed in an entirely different silo of the organisation. There was just so much work ahead that no one seemed to know where to get started. Best of all, it was a tensly political environment that wouldn’t allow me to just barrel around asking tough questions.

Rather than continuing to thumb twiddle, I decided to see how best to serve my team in order to serve my users.

Customising an American SaaS LMS for Australian Higher Ed — A journey map case study

Higher education in Australia is a big, messy, technologically diverse beast. One that I happen to love. I was lucky enough to come on board with an institution as they opted to switch from their old, locally served LMS to a new shiny cloud based Saas product. The enormity of this undertaking can’t be understated and nearly two years in, it’s still hard to conceptualise.

How can I help?

“How can I help” is an invaluable phrase to use in every starting conversation; along with “Who else should I speak to” it should be at the very surface of your toolkit when addressing the UX needs of an immense and/or immensely complex project. When the goal posts keep shifting and boundaries of scope time and budget are an amorphous undefined blob, these questions are a great asset.

Now, if you’ve worked as a UXer in a technology team including BAs then you’ll know that a lot of your work can overlap and if the roles are poorly defined you can end up stepping on toes, doubling up on work and feeling your contribution is ignored, under appreciated or redundant. Here’s where “How can I help” comes in.

More specifically I asked:

• What is the problem or need you are aiming to solve?
• What does the product(Business analysis documentation) need to do for this project?
• How do your outcomes fit into the overall project?
• What are your pain points?
• How can we best reach users(stakeholders, developers and management) through this design process?
• Who are the primary decision-makers on this project?

You may recognise these questions as the ones you might ask a user of your product, and that’s exactly right. Think of building(and optimising) your work plan the same way you think about building a product; the team you work with are now your users.

Remember that you’re a business asset; you’re serving the business/product as much as you’re serving the end user.

Through discussions with the BAs and by attending a few of their requirements gathering sessions I discovered four main issues:

1. The stakeholders involved in these workshops had little to no understanding of the scope of the project beyond their small piece
2. Our stakeholders were non-technical, i.e. they couldn’t conceptualise the question the BAs were asking them to answer
3. Our BAs were attempting to work at a level of detail that no one was prepared for.
4. Stakeholders and BA’s simply did not speak the same language

A UX designer is a champion for our users, we surface their needs and painpoints at the moments they matter as big decisions are being made about the technology that they’re using. When the rest of the product team are talking about data sets and integration points, product architecture and cloud storage, we’re a bridge between technology and the mythical end user.

Likewise in requirements gathering workshops I was acting as a bridge between the higher education pedagogical focus of academics and learning designers, and the technology processes of the BAs.

Solution — Take them on a journey

To bridge this gap, I needed to find a way to contextualise the technology in terms of the user space, the who, the how and when of it. In order to concretely visualise the when of the many activities our users need the LMS for, I opted for a high level journey map. While user journey maps are commonly used to uncover gaps in the user experience, I chose to repurpose this technique for aiding the BAs’ requirements gathering.

To generate the journey map, I performed the typical activities you might expect:

• Conducted co-design workshops with stakeholders, staff and students (well supplied with post-it notes and snacks)
• Ran user surveys and interviews
• Did Heuristic analysis of the current systems (boring, but crucial)

I discovered two sides to the same journey. Staff that generate content, students that consume it and a dense field of processes and functions in between. There was no direct path to a shopping cart, this isn’t rainbow road with a predetermined path and helpful map, an LMS is an open-world adventure game with no map and more side quests and distractions than GTA5.

30,000ft to bullseye

This means, of course that this journey map is huge, no A3 page can contain it and condensing too many individual pieces into snappy headlines only lost clarity. As I write this, the journey map is spread out across an entire wall, covered with sticky notes and hand written asides. We all walk past it on the way to the coffee machine.

So how is it still usable?

• It’s linear—we’re able to find the details we’re looking for because as humans, we naturally lean into time based structures for comprehension
• It uses the language of our users—each institution has it’s own way of doing things, because academics like to be different. I named every theme and task as the institution does. Having a common taxonomy makes so many conversations far easier
• Both staff users and student users are present—most activities involve both user types e.g. a teacher uploads assignment instructions, a student receives the instructions completes the work and submits, a teacher grades, a student views their grades. The interactions weave through the LMS with both party’s actions influencing the other. The journey map allows everyone to see how these interaction flow one to the next.
• It’s modular—tasks and activities are grouped together for better comprehension and digestibility

Results — Is the map successful?

The short answer: Heck YES! The long answer: Remember the four key pain points this solution is addressing?

pp1: The stakeholders involved in these workshops had little to no understanding of the scope of the project beyond their piece.

• By laying out all of the activities on one expansive journey map, all stakeholders are able to grasp how their small pieces fit into the whole.
• By grouping common activities into themes, the BAs were able to structure their stories into Epics that related explicitly to the end user experience.

pp2: Our stakeholders were non-technical, i.e. they couldn’t conceptualise the question the BAs were asking them to answer

• The conversation became less an open ended, “what do you want this product to do”, and more a specific conversation around what staff actually do day to day.

Our BAs were attempting to work at a level of detail that no one was prepared for.

• Requirements gathering workshops became structured around more manageable, contextualised groupings of tasks.
• The journey map allowed us to rapidly narrow down scope, and to reduce the many unknowns that we started with.

Stakeholders and BA’s simply did not speak the same language

• Our team’s BAs began using the language of academics, smoothing out previous frictions caused by them being viewed as “technology people” treading on academic turf.
• The journey map outlined all the user tasks in a language academic staff were familiar with, giving them the confidence to answer the BA’s questions head on.

As a UXer it is sometimes easy to feel isolated from the rest of the team if you aren’t involved in amanagement and strategy, but you aren’t a developer either. But if there’s one thing to remember when working on a massive technology product it’s this:

We are all in this together.

There are so many excellent uses for a journey map. I hope this gives some more ideas and inspires you to work closely with your team and understand their pain points as explicitly as you understand the end user’s.