How do you utilize object-oriented thinking in your UX process?


#1

For a number of years I’ve been trying to think about the UX process in the way that object-oriented programmers do. Mostly, this means thinking about things in terms of data (objects) and their relationships instead of interactions. I’ve come across an OOUX methodology where one can convert user stories into object definition. There are a number of reasons why I want to do this, partly because object-oriented programmers will be implementing everything anyway, and it makes sense to develop a shared language and mental model at the beginning of the project. I’m also particularly interested in the idea of taking those object definitions and letting programmers begin with API development and unit testing even before the designers start producing wire frames. This would allow for closer collaborating between the visual designers and the programmers implementing the designs.

What have you done to import object-oriented concepts into your UX process?


#2

Great question @edhertzog (and welcome).

Everyl Yankee wrote an article on this topic for a few years back. Object-focused vs Task-focused Design

I’ll get in touch with her and see if she’ll join in the conversation here.


#3

I just checked out that article. That task focused vs. object focused example clearly illustrates the difference. When implementing designs, programmers do not start with “wash”, they start with “dog” and then add “walk” or “color” in relation to the dog. Then that dog’s relationships are not to “walking” but to “owner”, etc. The point is, there are several walls between disciplines in a UCD UX process, and part of it might be due to specialization, but part of it is due to the fact that the researchers and designers are thinking in terms of tasks and the programmers, who come at the end of the process, are thinking in terms of nouns/objects. There is somewhat of a conflict in perspectives.

Anyway, I’m really trying to explore this topic and build upon it so I appreciate any input anyone might have. I’ll be presenting at UXPA in Seattle at the beginning June and I’ll be working some aspects of OOUX into my presentation. And, after that, I hope to continue to explore the topic of OOUX in other ways. I’m really hoping to expand on methodologies that can be employed throughout the UCD process. So you may be hearing more from me in this forum.

I recently finished the Dave Collins book referenced in the article you referenced. Also, these are really great:

Object-Oriented UX · An A List Apart Article
OOUX: A Foundation for Interaction Design · An A List Apart Article

But beyond the Dave Collins book, those two articles in A List Apart, and the article you posted, there just isn’t a lot out there on this topic. I’m hoping to do what I can to change that.


#4

Possibly the task focus came from the first UI designers (excepting the object focused ones) who had backgrounds in task analysis from tech writing or education.

I was lucky to work with linguists and speech pathologists designing assistive device interfaces; they based the designs on nouns. This approach is more versatile as well as beautifully simple.

It’s just a step up from task focus to orbit the tasks around the next level, objects.

Check out Sue D’s/my book for a step by step work through of the process (very little available - as far as I know? - in information architecture; they tend to describe the need but not any process). Dave Robert’s book on OVID is still the best one I know of.

It’s very exciting to hear you are presenting and can’t wait to hear more!


#5

It actually makes way more sense to look at things in terms of objects, because that’s what the implementors have to do anyway. If you have research and design thinking in terms of workflows and interactions, and programmers thinking in terms of objects and how they relate, you almost have two different sets of terminologies being used.

I’m actually working on something now to demonstrate how the object definition methodology can be used to go straight to writing an API before wireframes are even started. It would dramatically decrease the distance from start to finish on a project, and would probably generate higher levels of collaboration between design and implementation. I’ll keep you posted.