Request a Live Demo

Please take a minute to tell us about yourself

* All fields required

View our Privacy Policy  or  Terms and Conditions.


Thanks! We'll be in touch soon!

In the meantime, please feel free to give us a call at 800.981.5084, explore the site or check out a video.

An error occured

Please feel free to give us a call at 800.981.5084


athenahealth logo

Designing for Simplicity: Object-Oriented User Experience

Jessica Romeo

Jessica Romeo



As UX designers, our mission is to design intuitive interfaces and experiences—with no unnecessary complexity—so that users can accomplish tasks with ease. Though that mission is clear, the steps to get there can be fuzzy. Especially in a complex space, like healthcare, where there are government regulations, clinical guidelines, and a diverse user population. Now, add a complex data architecture and schema (which is well-captured by this athenaNet system map on the 4th floor in Watertown) and it becomes even more tricky.


History lesson

When the UX team designed Streamlined, we aimed for simplicity by focusing on the “happy path.” We used call-to-actions to help guide our users through primary workflows. We conscientiously omitted data, features, or workflows that were not mission critical for our physician users. We had taken IDEO’s research to heart, which revealed a considerable information overload problem; priorities were obscured and our users were bogged down and confused.
As Streamlined rolled out, we saw success! The primary workflows were undeniably more efficient for physicians. However, we also observed that users were frustrated when they veered off the “happy path” because they needed to click around to multiple chart tabs, open multiple flyouts, use the magnifying glass, and many paths lead to a dead end.
We quickly realized that designing a clear, prioritized path was only step one towards a creating a clear and simple user experience. The second step was to make sure all data was meaningfully connected, so that users have paths for navigation. We needed a web, not a tree-like information architecture.
To help us start down the path of thinking about how to best build a beautiful web of connected data, we found Sophia Voychehovski. Sophia is the founder of reWired, and author of two compelling articles in a List Apart about object mapping and building Call-to-Action (CTA) inventories. We invited Sophia to come and lead a cross-functional group of UX / Dev / PI through a 2-day interactive workshop and deep-dive exercise where we applied her Object-Oriented UX (OOUX) methodology to the Clinicals product.

OOUX Group


What we learned

  • Designing objects first aligns our product to a user's mental model. Humans think about the world (and their work) in terms of real-world objects. When asked to describe an experience, a person, or a place -- people overwhelmingly start with nouns (objects). Similarly, when we design software, we should start by defining the objects users care about before designing actions.
  • Consistently represented objects are easier for users to understand. Even small differences in the way an object is represented can cause confusion and slow users down. Each instance of an object should have consistent data, metadata, and actions, prioritized by importance to our users.
  • Actions are tools for users to create, manipulate and find objects. Interaction design should provide a way for users to manipulate an object. In the example of Clinicals -- a medication is an object in the real-world and in product. Users need to prescribe, edit, or cancel a medication in Clinicals so they can provide care to their patients.
  • Objects (almost always!) have relationships to other objects. All objects in Clinicals have connections to other objects in Clinicals (and Collector, and Communicator). A user expects to be able to see these connections and to use metadata for both navigation and filtering objects.
  • Designing with objects-first improves collaboration between UX and Dev teammates. This was the most exciting thing we identified! Developers are already coding using objects. Users are already thinking about objects. To simplify our designs and design process the objects in the database should be the same as objects in our user’s heads should be the same as objects in our designs. This gets everyone speaking the same language and should streamline the design, test, iterate cycle of product development.
  • Applying this process to Clinicals was harder than we thought! We spent the day as a cross-functional team applying the OOUX methodology to Clinicals product and came up with many questions and lots of engaging conversations about what objects our users care about and how these objects might fit together cohesively.