On the woes of usability (from a developer's point-of-view)

I've been struggling with the UI design and usability for our reporting system for weeks now. We've built most of the UIs for the general administration tools for defining cohorts, indicators, datasets, and reports. However, these UI are the kind of pages that are completely unintuitive to a user: a listing page to display all reports and a details page to allow the user to view/edit the details of a report. We give away too much information, too many options and it's just an overwhelming experience for the user. And it's tiring for a developer. I want to build intuitive interfaces. I do. I want to make things easy on our users. I just don't know how. No matter how much I read about ux (user experience), I just can't seem to get it right.

So this morning, instead of banging my head against the wall for another day, I decided to have a discussion with one of OpenMRS's most gifted developers. No, not Ben Wolfe ... although, there's no doubt that he is a programming genius. No the conversation with with Mike Seaton. I asked him to give me a ring to discuss these issues. He's been working on reporting for our legacy Haiti system for years and knows a thing or two about indicators and indicator reports. I was expecting to have a quick conversation about the following mockup:


But we spend about an hour on the phone discussing the details of indicators and how we need to wire parameters (like start date) from the low level reporting components (an indicator) up through the indicator dataset definition and into the report. The screenshot above isn't terribly complicated, but it requires a little too much knowledge of what the lies underneath an indicator.

But as part of a larger process (creating an indicator report), this UI is just one little piece of confusion pie. At first glance (in my mind), the entire UI for creating the indicator report looks like a messy hierarchical chaining type thingamajig because I have been thinking about how one might design one of these reports from a bottom-up perspective. Here's the process, in a nutshell:

1. User creates the cohort definition (Gender Cohort Definition with "gender" parameter).
2. User creates the indicator (# Male Patients with "gender" set to "M").
3. User creates the dataset definition and adds the indicator to it (My Indicator Dataset)
4. User creates the report and adds the dataset definition (My Indicator Report).

Four different pages ... four different steps ... just to create a report with a single indicator. Why would you do this to the user? Why would you do this to yourself?

I have no idea.

Don't paint me in the moron category just yet. I knew there was a better UI. I had the image in my head, but I just got flustered with all of the "stuff" that needed to happen in order for that design to work. There's a lot of "stuff" that needs to be configured, configuration options that "should" be available to the user. To be more explicit, for each layer (cohort->indicator->dataset->report) there's some "wiring" that needs to happen in order for a report parameter (say "location") to be passed down through the hierarchy of objects to allow a value like "Rwinkwavu" to be used by the indicator or cohort definition when it's time to evaluate the report.

The thing that Mike and I figured out was that we really don't need to let the user configure everything when designing the report from scratch. At least not at the beginning. Let's give them just enough configurability (add an indicator) to get off the ground. We can make some assumptions for them (you want the "location" parameter to be . Then, once things are flowing, we can let them dig down and get dirty with the report configuration. So here's the mockup I came up with from those conversations:




Now, I know this isn't revolutionary ... but it's hard to make the kind of assumptions we need to make to hide the complexity from the user. And there's still the issue of designing a somewhat intuitive interface for a user that wants to dig down into the details of each indicator in order to configure, say the "location" parameter to be hard-coded. But we'll get to that feature once there's a need for it. For now, the "edit indicator" feature will have to be left unimplemented. Sorry Mike - I know that wasn't the conclusion we came to, but it feels like the right thing to do, rather than adding one more confusing element to this page. This design feels right.

Let me know what you guys think.