Using OOUX in focus group settings

When designing complex software, it's easy to forget that part of what we’re dealing with is content. The content a form is required to capture; the content available to a user to accelerate their work. Content, and its structure, as an essential component of the enterprise design process - and one that’s far too easy for designers to overlook in the pressure of getting design out the door for developers to work on.

Object Oriented UX provides a way for designers and teams to align on structure and content before they start designing screens. By understanding the OBJECTS people need to interact with, the ATTRIBUTES that need to exist within them, and the CALLS TO ACTION they offer, we can have better conversations with our developers and set ourselves up for experiences we can iterate and evolve over time.

One of the key outputs of OOUX is the object map, which outlines the objects in the system, along with their relationships and attributes. While this can be valuable for product and engineering teams, during a recent project we wondered if it could also be used for user research.

The answer, it turns out, is yes—kinda.

Setting the stage a bit, one of our designers, Kayla Huddell, has been working with her team to create a treatment plan for a specific type of specialist. The treatment plan is a core part of how these specialists work and captures goals for treatment, along with specific objectives and interventions they will take to get there. We knew through our user research that the plan needed to evolve along with the provider/patient relationship, and it had to be signed by multiple people, including the patient and the provider(s) involved with treatment. We also knew that there needed to be a way to capture progress against the goals of the plan, and that there was some way in which this plan needed to be involved with the provider’s progress notes - but we weren’t fully sure how that needed to work.

So you can see that going into this project, we already had a lot of research around what a treatment plan should be, how it might be accessed, and we had a solid sense of what should be in it. What we weren't fully clear on was:

• how would practitioners need to interact with the treatment plan as they work with their patients? What information would need to be captured in the progress note for a session, and what could stay in the plan?
• How do practices report on treatment plans? We had heard through interviews that some practices wanted to report on how effective common interventions were - does this mean that users might need some structured “starter content” for aspects of the plan?
• how might other provides need to interact, or be attributed, within this treatment plan? We knew that multiple providers, or even social services, might be participating in someone's treatment. While we knew that signatures from all these people were needed, did we also need to find a way to assign things to them from within the plan?

Working through the OOUX process together, Kayla and I arrived at a set of core objects we believed existed within and alongside the treatment plan. For each object, we looked at the research to determine:

• how the objects related to one another
• what calls to action they might offer
• what information might be most important to collect and possibly report on.

The result was an object map that looked like this:

Now came the question of validating this with end users. We had already planned on joining the  user group for our target specialty the following week to get feedback on our early design for treatment plans. Could we bring the object map, and get the feedback we needed to make sure we were creating something that would work before we started creating designs?

We decided to start by reaching out to a couple of our internal subject matter experts (SMEs) in this space. Zooming through the object map with them in Figma, we were able to get some reasonable feedback one on one - but it was easy to get tripped up trying to figure out where to navigate next on the big map as we were trying to ask our questions. We could tell that trying to do this in a big group of providers and EHR admins over a Teams call would be a recipe for disaster. But going through the exercise with these SMEs, we were able to get really clear on some of the questions we needed to validate:

• Were these the right objects? And did all of these things need to be objects, or could they be free text in the Treatment plan?
• How, specifically, did Objectives and Interventions play together? Did providers need suggested content here, or did they always want to write it their own way?
• What about our list of things someone could do to a treatment plan? We knew that these plans had a review cycle and had to be signed by the patient and providers; Did that mean the current plan was closed and a new one created? Or were we just capturing a snapshot in time?
• How do provides need to track progress against the plan, and how did they expect that to show up in their progress notes?

These questions in mind, we decided to break out our object map into a series of PowerPoint slides, which included:

1. An overview of the OOUX process and what the different colored boxes on the object map mean
2. Our experience vision for the treatment plan
3. The first 3 objects we identified — treatment plan, goals, and diagnosis — and how we had defined them
4. A few of the critical CTAs we had identified, and some key questions we had about how the were expected to work
5. A handful of the important attributes we identified for treatment plans, with our questions on those
6. The specific sub-objects within the treatment plan — objectives and interventions — and our questions around how they were meant to work with each other, and within the context of the treatment plan itself.

With these slides, we were able to engage the user group in a robust conversation over a 40 minute call. Keeping things at the object and attribute level helped us get to the core of what the treatment plan should be and do, without the baggage we often find when we try to  validate more “finished” prototypes types. Even better, it gave participants the freedom to challenge and correct our assumptions, which helped us see aspects of the problem we hadn't even considered before. Best of all, the participants loved it; feedback in the meeting chat suggested that they found it productive and engaging. And the user group lead, one of our internal SMEs, was overjoyed.

So the tl;dr on this? OOUX can absolutely be validated with users, when you structure the conversation thoughtfully. Some tips on making it work:

1. Get really clear on the questions you have to answer based on the map. This will help you structure the conversation.
2. Pull out the specific attributes you have questions about, as well as the objects. It's helpful to keep like attributes together on the same slide—meta with meta, CTAs with CTAs, etc.
3. Define your objects and how you think they relate to each other — and use part of the session to validate & evolve your definition.
4. Provide an overview of what OOUX is, and how you will be working with it in the session. This doesn't have to be comprehensive; ours was a single slide that took less than two minutes to explain. But it's essential for grounding the conversation.
5. Treat the session like any other type of research session. We focused in on each slide, let participants absorb what, they were seeing, and drew out their feedback with targeted questions. Within a few minutes, we were having a lively conversation that helped refine our approach to the project — and the group was delighted that their voices were being heard so early in the process.

All in all, we felt this process helped to deepen our understanding on what the treatment plan could be, while giving us rapid validation and refinement of our approach — just in time to talk through the backend architecture with our engineers, with on updated object map as a guide: 10/10 would recommend!

To learn more about object-oriented UX, visit ooux.com.

Note: this post also appeared on Medium: https://danigrrl.medium.com/using-object-oriented-ux-in-user-research-it-can-be-done-f4c484972032.