Designing with OOUX

Changing up my process

As a product designer in a young and ever-changing industry I am always looking for ways to continue to improve upon my design practices. In my earliest years as a production designer at a small web dev shop, I would work on one ticket after another, saying yes to whatever requests came my way. Then as my design knowledge and confidence grew, I advocated that my team incorporate design into their process. And thus we moved into “waterfall,” the trendy workflow of the time where a single project neatly flowed down the river from one team member to the next (pm > design > dev > qa) - I am so hip. Then UX and agile became more mainstream, and I too moved in this direction to a product team where we would figure out user stories and map them to key features and interactions designing one flow at a time until the product was complete.

An example flow: “How does the user use the thing?” Develop one flow/feature after another, slap on some overarching navigation, and BAM you have a product. (credit: Sophia V. Prater)

Although the interactions first approach seems logical it has it’s downfalls as well. By designing one flow at a time without having mapped out the entire product at the beginning of the project, this leaves room for the team to overlook certain features or content. Therefore, as new features get introduced to the product, the team must find ways to “squeeze” these things into the UI or navigation and interactions may vary from one flow to another. If you have ever used or worked on a product where you could actually tell which screens were designed by one designer versus another, this is likely the result of an interactions first approach.

And then came OOUX

OOUX, which stands for Object-Oriented User Experience, was popularized by Sophia V. Prater. I’ll refer to her articles and work heavily in this post.

Unlike the interaction-first design process above, which jumps straight into user flows, OOUX forces us to define the content and objects that should construct the application first. It is a method of product design which can be used to help quickly clarify the entirety of a new or existing product and is a great conversational tool to use with your team to validate that everyone’s on the same page.

As I stated above, many young products face the challenge of developing one feature after another, with little foresight into how to set-up the application experience for long term success. This often results in disjointed user experiences, user flows, and user interfaces. OOUX introduces the use of carefully siloed objects which can then be easily reused, grown, shrunk, added or removed as user needs are validated and features produced or sunsetted.

Some learnings from my team

The team here have been dabbling with using variations on OOUX and discovering how to adapt it to different project types — marketing site, enterprise software, and more. We’ve also realized some of the language used in OOUX, such as “metadata” or “nested objects,” were being used in ways which differed from their usage as engineering terms, so we’ve decided to avoid these terms entirely for the time being.

Since I incorporated object first thinking into my process, the team have been able to validate our ideas with each other much more easily and clearly. OOUX has also kept my focus on what information NEEDS to be here without getting distracted by nice-to-have or “cool” features and ideas. This also speeds up my design process by not worrying about visuals until the very end until after the content has been settled.

Conclusion

OOUX gives teams the ability to approach their product in an organized manner quickly. OOUX is just one method to supplement your process. Adapt it as needed and use whatever works for you!