Easy Ethics Compliance

Below is a case study presentation documenting a project whose goal was to develop an enterprise-level case management system for internal ethics-related inquiries. I left it in its original format (with annotations) to reveal not only my thinking and process as a UX researcher but also to showcase my ability to present complex information.

The captions provide additional commentary, insights, and context.

NOTE: Identifying information has been omitted due to NDAs.

I created this slide to summarize the project in as few words as possible. This allowed interested stakeholders to get a quick, high-level overview before diving into the details. The “value added” section is abstract because there was no quantitative way to measure this project’s success due to the organization’s low UX maturity.

In any high-context environment, background information is important. For this project, the most relevant context was that the primary users were new to the organization and had not developed their own system for managing ethics-related inquiries.

This slide may seem redundant or unnecessary (I show full personas later), but as an advocate for users, I like to consistently remind stakeholders whom we are affecting. NOTE: I was not a fan of using adjectives in front of the names, but this decision was made by a more senior UXer.

In retrospect, I went into too much detail here about the nature of the case management system.

This was a rare case where we interviewed everyone who would likely use the future case management system. In other words, we did not have to rely on a sample of users. However, it bothered me that we were not permitted to survey and/or interview folks who had made ethics-related inquiries in the past because without them there would be no need for a case management system.

This organization tends to silo its projects, but I have never been involved in a project that did not have findings and implications beyond one particular product or service.

I cannot take credit for designing this, but I did edit and revise the content — while making more substantive suggestions. I just hope someone (outside the UX team) uses it.

Because we were working with an outside vendor, we had little control of the interface. All we could do was suggest changes to the colors or text. NOTE: The blank blue boxes are blocking sensitive information and are not part of the design.

This project was a lesson in how important it is to develop software in collaboration with those who will actually use it day-to-day. There isn’t a one-size-fits-all solution to anything in this world. To be specific, if you develop prototypes without user input, you’ll likely make A LOT of changes during testing.

Again, I want to emphasize that testing is a lot more useful and efficient if the product being tested was developed based on user input.

No need to dive into the content on this slide. This is just to give you a sense of what the test participant might see. I say “might” because I tend to give them tasks one by one so that they don’t get confused or off-track.

I realize now that the color-coding, while clever, is not accessible due to low contrast.

Even though it wasn’t part of my formal role, I dabbled into software training to some extent. It was natural to me as a former educator, and it also helped reinforce the hard truth that not everyone learns through experimentation. Some folks need their hands held.

Even though we did not do a formal retrospective as a project team, I spoke with my fellow UXer in great detail, and we agreed on the following points.

I think it’s important to point out the less measurable successes of a project that are still replicable (such as team chemistry).

NOTE: I left out a slide with some aggressive recommendations. This is to avoid any potential blowback — even though I’d be very surprised if the involved parties took the time to go through my portfolio.