In June 2012, while working at CNN.com, I was tasked with designing the user experience of election night. The next five months of my life would be dedicated to that single night—but success to me had nothing to do with who won. I was concerned with findability, data visualization, a shape-shifting canvas, and how the hell mouse-over flyouts were going to work on an iPhone. For the first time in history, CNN.com was releasing a responsive experience. And, for the first time in history, I was going to design a responsive experience.
The stakes were high. Election night is like Super Bowl Sunday for CNN.com. If well executed, it’s one of the highest revenue nights in a four-year cycle. To add to the pressure, we were on a tight timeline with a deadline that was not going to budge. November 6th or bust.
Then I learned that the first development sprint kicked off in four days. Four days?! My project manager calmly told me, “Don’t worry. The devs only need one template for the first sprint. While they are building the first template, you can move on to the next.”
Huh? How was I supposed to design a cog in a machine without first roughing out the design of the machine?
Thinking myopically worked okay when we were designing in pages on fixed screen sizes; we could get away with quilting together pieces designed in silos. I was pretty clueless about responsive design, but I did know that we’d need a clean and simple system, not pages strung together. And as all engineers and designers know, the more moving parts in a system, the more opportunities for disaster.
So during those first four days, I did not wireframe one disconnected template. Instead, I blocked out a holistic system made of reusable, interchangeable parts. Here’s what it looked like:
I presented this diagram to a conference room of stakeholders who expected to review a single “finished” template. I demonstrated that I had reduced the number of components and templates compared to our 2008 design, and that the new system was simple enough to fit on one 8.5 × 11 sheet of paper! Thankfully, a critical mass of people in the room saw the value of what I presented: less stuff to build.
The diagram I churned out in 2012 was far from perfect, mostly in that I was trying to do too much too soon. I jumped the gun on implementation, blocking out flyouts and bar graphs. I was still thinking desktop-first, worrying about positioning, as opposed to prioritization. I packed in a premature homepage, a cover sheet for the experience (which I would now design last). I took a stab at persistent top-level navigation, instead of focusing on the content modules first.
Although imperfect, the spirit of the diagram, and the thinking behind it, hit a chord with me. It wasn’t a sitemap; it showed no hierarchy. It wasn’t a storyboard; it didn’t block out a task flow. Instead, this diagram mapped out a system of things. And it changed the way I do UX.
Stripping away interaction, persistent navigation, homepage, and layout, here’s the diagram that I would have created then if I knew what I know now, showing a system of three objects: States, Races, and State-Race Results.
It worked: our responsive election night turned out to be the Super Bowl Sunday CNN executives hoped for. But we did it by the skin of our teeth, working late nights and weekends to make sure the design performed on a myriad of devices. I’m not sure we could have pulled it off with a design any more complex.
Today, I’ve evolved this trial-by-fire experience into a proven, structured object-based process. In this article, I will introduce object-oriented UX, share my process of object mapping, and help you start doing it yourself.
Mobile first, content first, and objects first#section2
Always separate thinking about real-world things from the documents which describe those things. Resource before representation.
It took me about about a year to retrain myself to truly think mobile first, but today, I do so even when designing desktop-only software applications. To me, mobile first simply means forced prioritization. It means think about layout later. Start with a single column “design” (also known as a list), and force yourself to prioritize content and functionality with sequential ranking.
This approach dovetails nicely with the concept of content first: “content-out design” as opposed to “canvas-in” design. You have to know what you’re saying before you can prioritize it.
Sometimes, this means having real-deal copy first—particularly when you’re working on a site with a critical mass of evergreen or instructional copy that can be organized, prioritized, analyzed, and updated before design work begins.
But if you are working on a site that is 99 percent instantiated objects (news articles, products, campaigns, donations), there’s no way to build a complete copy deck up front—or ever. Instead of prioritizing actual copy, I have to think in objects.
That’s OOUX: putting object design before procedural action design, and thinking about a system through the lens of the real-world objects in a user’s mental model (products, tutorials, locations), not digital-world actions (search, filter, compare, check out). We determine the actions after first defining the objects, as opposed to the traditional actions-first process that jumps straight into flows, interactions, and features.
OOUX is powerful#section3
Newsflash! This is how your backend engineers work. In the ’80s, the software engineering community began to transition from procedural languages to object-oriented languages, which have benefits like code reuse, data encapsulation, and easier software maintenance. Most programmers bring your designs to life using object-oriented languages like Java, Ruby, Python, C++ or C#.
Engineers start their process by mapping out the objects that make up the problem domain—something UXers should be doing from day one. When they look at your wireframes or prototypes, they first reverse-engineer your design to parse out the objects. They think, “How will object X talk to object Y? Will object A be made up of lots of object Bs? Which attributes will each object have? Will this class of objects inherit from that class of objects?”
On the web, we develop object-orientedly, but still design procedurally, focusing on drill-down hierarchy or linear task flows. But there’s another option. In his 1995 book, Designing Object Oriented User Interfaces, designer and engineer Dave Collins argues that basing both front-end and backend design on object-oriented principles “brings coherence to the software development process. Object-orientation reveals deep structural correspondences between the artifacts of analysis, design, and implementation.”
Defining objects that mimic the mental model of your users provides a scaffolding for team communication. It gives you a shared language. On top of team cohesion, designing object-orientedly can also help you:
- match your user’s mental model, improving their experience
- ensure simplicity, reducing any accidental complexity due to extraneous design elements
- grow and maintain your product: objects can be iterated on without affecting the rest of the system and new objects can be gracefully folded in (as opposed to tacking on features)
- build better APIs with portable, independent objects
- get SEO brownie points from structured content and valuable cross-linking
Then, there’s my favorite justification: OOUX helps you bake in more-crucial-than-ever contextual navigation. In other words, it helps users get to content through content.
Persistent navigation might be hidden, hamburgered out of sight when a user is on a small screen. But even on 17-inch monitor, the most beautiful pinned-to-the-top navigation might still get ignored. When a user visits a site for the first time, they often gravitate to the big shiny objects, using the navigation or search bar only as a backup plan. As Val Jencks neatly summed up, “We go to content on the page first. The top navigation is the fire escape.”
If a user is reading a recipe, where might they want to go next? We should anticipate how they might want to explore based on the recipe they are reading, and not leave it up to them to peck through a hierarchical menu or come up with a search term. And we certainly should not leave them with a few “related recipes” and consider our work done. They might want to see all the recipes that the chef has posted. Or maybe they want to see more recipes that use swiss chard, pivoting by ingredient?
If we are thinking object-orientedly, we will experiment with ways that each object might relate to other objects, looking beyond the obvious. Maybe chefs have favorite ingredients? In the object-oriented design below, a user can continually explore instances of these three objects (recipe, chef, ingredient) without ever hitting a dead end. The content is the navigation, and it’s all in context.
If this concept feels familiar, you’ve probably read about or practiced content modeling. In the past five years, many information architects (see Mike Atherton’s work) and content strategists (see Rachel Lovinger’s work) have started focusing on systems of reusable content types, and becoming more involved in the design of CMSes: the content creator, not just the end-user, is a primary user.
In her book Content Everywhere, Sara Wachter-Boettcher encourages us to model our content before diving into wireframes and interaction design:
Content modeling gives you systematic knowledge; it allows you to see what types of content you have, which elements they include, and how they operate in a standardized way.
Unfortunately, the art of content modeling is still unfamiliar to many UX designers, who hear “content” and assume it doesn’t apply to them. This is especially true for UXers who deal with software as a service or product design: strategies involving content sometimes fall on deaf ears.
Object mapping#section4
Object mapping, my process behind OOUX, is content modeling for designers who do not deal with content in the traditional sense, but still need to design systems—and not just systems of implementation. While a tight collection of reusable templates and modules is invaluable, those design patterns don’t hold meaning for a user unless they’re backed by a system of real-world objects that matches that user’s mental model. Focus first on designing the system of real-world objects, then on designing a system of implementation to bring it all to life. This is the linchpin of all my design work, because it transforms goals into an executable system that meets those goals.
Get out your sticky notes, grab your team, and clear some wall space—I’d like to walk you through my process.
Step 1: Extract objects from goals#section5
One of my favorite perks of object mapping is that it provides a perfect bridge from goals to design. Instead of haphazardly whiteboarding A Beautiful Mind-style, object mapping provides a neat framework to move from strategy to design. (Please continue to go all John Nash at the whiteboard, but create an object map first. It will give your wild creativity a solid foothold.)
As an example, let’s say we are building an application to help home improvement brands connect to DIYers. After user interviews, a competitive analysis, and discussions with stakeholders, we have our brief:
Give DIYers an outlet to post their home improvement challenges, soliciting potential solutions from product companies (brands). DIYers get expert solutions to their challenges and brands get exposure.
- DIYers can search and browse existing challenges, commenting on the proposed solutions.
- Brands can search and browse for open challenges that might be a good fit for one of their products.
- Brands can create solutions that feature one or more of their products.
- DIYers can close a challenge after a solution has been chosen, and later follow-up on how well the solution worked.
- Brands can create a library of solutions that can be reused on various challenges.
To extract the objects, we basically highlight the nouns.
Recognizing nouns is first-grade simple, but extracting objects does require some subtle art:
- We pay special attention to nouns that keep popping up, like challenge and solution. Those will be important objects.
- We ignore the abstract noun exposure, as this describes a fluffy concept we hope will emerge from our system, not a tangible object that will be part of our system.
- We ignore library because this is simply a collection of other objects (solutions). Watch out for words like calendar, catalog, or map. These are usually just fancy list-views of the core object: an event, product, or location, respectively. For example, most systems that deal with locations will have a single (perhaps filterable) map view. The map is a design mechanism, not an object itself.
- We infer an object from two actions: “commenting on” and “following up.” Obviously, we will need some sort of comment object.
- We note that a challenge object needs multiple states: posted, in progress, closed, and closed with feedback.
From this 10- to 15-minute exercise, we have the main building blocks of our system. Let’s write each object on a blue sticky.
Next, we need to define what the objects are made of.
Step 2: Define core content of objects#section6
Content modeling requires you to simultaneously understand your goals at the highest level and get intimate with your content’s most minute attributes.
Quite. We just determined the macro building blocks of our system, and now we must determine the most granular elements of each. This activity is often reserved for eleventh-hour detailed design, but defining elements while in the medium of sticky notes is liberating—when you start sketching a little later on, you can focus on more creative aspects. Also, having early conversations about what makes up each object can help you avoid moments late in the game where an important element is left off (or extraneous) and the change needs to be made across several design documents.
Most importantly, you can have conversations with your team such as, “Should DIYers be able to add their budget onto a challenge?” before non-designers are looking at wireframes or layout. This helps keep conversations focused, rather than getting stuck on something like the icon for budget.
At this point in the process, I separate two types of elements: core content and metadata. Core content, like text and images, goes on yellow stickies. Metadata—any data that a user might sort or filter on—I put on red stickies.
If your team isn’t sure about a potential piece of content, write it down anyway and just add a question mark. Move on and return to it later.
Step 3: Nest objects for cross-linking#section7
And now the system comes alive. Do a series of thought experiments for each object. Starting with one object, consider ways that each of the other objects can “nest” inside that given object. As you nest objects, you are defining the relationships between them, and, implicitly, the contextual navigation as well. Using blue stickies, experiment with how each object might nest its other sibling objects.
For example, here’s how that conversation might go for our challenge object:
- DIYer: “Easy, the DIYer is the author of the challenge.”
- Solution: “This is the main nested object of a challenge. We need to show all solutions posted to this challenge.”
- Brand: “Eh, not really? Brand will be a part of the solution modules (as an author of the solution), but probably not directly nested into a challenge.”
- Product: “Again, part of a solution, not directly nested. Huh. Unless DIYers can post the products they already have at home?”
- Comment: “Hmmm. Probably relegated to solution…should we keep all commenting on the solution? Or should brands and DIYers perhaps be able to post questions directly to the challenge? We need to explore this more.”
Note that not everything is figured out. Some items, like the commenting discussion, might be best resolved during sketching—but you will be intentionally exploring an identified design problem, as opposed to that problem catching you by surprise.
Step 4: Forced ranking#section8
Ugh. This is the most diabolically difficult step. In the prior steps, it’s very important that you wrote each element and nested object on separate stickies. Why? Because now we need to reorder the elements, from most to least important.
This ordered list does not necessarily provide a direct representation of what will be at the top and the bottom of the screen. In design, priority might manifest in size or color. Low-priority content might be placed at the top of the screen, but in a collapsed panel (yay, progressive disclosure!). So reassure your team that we are simply prioritizing and not designing.
While prioritizing, imagine which elements will be most important to your users. Which bits are must-have information and which are nice-to-have? When considering metadata, think about the most important sorting and filtering mechanisms. If the default sorting will be by “popularity,” then “number of DIYers who like this” will be high priority.
A new foundation and framework#section9
Now you have an object-based system derived straight from goals. But keep in mind that while this activity provides a foundation for designing an implementation system, interactions, and persistent navigation, it doesn’t carve any decisions in stone. It’s a first draft! As you iterate, objects and elements will be introduced, eliminated, and reprioritized. Your object map provides a framework for continued conversation and collaboration: with your client, your design team, and your developers.
OOUX is not a new end-to-end process; it’s a new ingredient to add to your current process. It adds clarity, simplicity, and cohesion—to how you design, and to the products you release into the world.
Please don’t say “object-oriented”, please! What you’re advocating is probably orientation towards modules, components or containers. As soon as you say OO, some people might start classifying, “namespacing,” inheriting, encapsulating and abstracting towards complexity instead of reducing to simpler forms. As it happened with CSS, it might happen with UX, too.
Adam, thanks for your comment! It will be interesting to see what others with a dev background say about my “stealing” the terminology. I gave the talk-version of this article at dev conference in Atlanta (Connect.js) to a room full of engineers, the overall sentiment was, “Finally! Speakin’ our language!” as opposed to “NO! You’re bastardizing our vocabulary!” After reading the article, what WOULD you call it? I am not really comfortable calling it modular design, because that alludes to design implementation – actual modules with 10px padding and such. Semantics sometimes makes my face hurt, but I think it’s a valuable conversation.
First, I love the article it is extremely challenging to look at removing navigation through content. I have developed my own thinking which I call Object Attribute Action – where the path to an object is typically through its Attribute (ie. iTunes getting to the object, a song, via an attribute like genre). The thing that stands out to me in the overall article and its comparisons is the lack of actions. What happens when I am composing something? Bring alternate things, images, text, data into an application? Where does that fall into this thinking?
Fantastic article. In building the content modules on stickies in this way, you’ve also created a high-level database schema and a roughed-out API design, which as a developer, makes my life easier and helps show the relationship between the UX design and the functional design. This would probably help engage an entire agile team in the discussion rather than half the team losing focus before its over. I love the concepts presented in this article and I hope this idea takes hold. Thanks for sharing it!
And I think calling it “object oriented” is perfectly semantic fwiw 🙂
Sophia, I don’t want to split hairs over semantics, though obviously the language we use directs our thinking. Is the goal here to make UX more approachable to developers? (There has, for quite a long time, been a movement in development/programming world that questions the idea and benefits of object-oriented thinking.) When I think of objects, I think of nouns, but experience to me is more about actions I take (verbs) and how I feel (adjectives.) What about sounds? What about designing experiences for TVs, desktops, phones and watches we carry, or audio-based devices in our rooms and kitchens that don’t have a screen, or devices we haven’t even seen or heard of? Should form define our thinking and experience or rather function? I’m not sure that following software development terminology would be an improvement. I guess it depends. But when design process gets stuck in methodology imported from other discipline, for the benefit of development team, would designers still have a unique voice and perspective they bring or a chance to do something new that breaks the boundaries?
Great article, thanks. Think you raise a great analogy with the development process – as other commenters and your article say, this is exactly what developers need to do, extract the nouns, verbs, behaviours and relationships from the business requirements. Oftentimes as web developers, this is done from the wireframes and so having this thinking in place up front when they are produced is a bit help – ideally in conjunction with the developers.
On the semantics, perhaps strictly the closer resemblance is with “entity relationship modelling” – which is exactly that process of analysing the requirements and determining the database tables/model classes and their relationships – and avoids some of the other OO aspects that don’t to apply so closely. But I wouldn’t worry too much about that – no analogy is perfect. For me anything that gets the designer, the developer and the business talking similar language and working from the same concepts is a good thing.
Very interesting article Sophia! I’ve found myself working in the same way, but I’d never thought about how to put it together as you did here.
Thanks!
Hello Sophia! I recently tried to grasp “object oriented” Content Management / UX too. Like you, I also experience that when designing something, something often frowned upon as an approach is “content first” to create a great experience.
I find that “object oriented” is a great analogy in terms of content and metadata organization. I know how to organize content, maybe also how to prioritize. However, keeping users interested by keeping them “in the loop” of exploring new content through content is really brilliant!
Thank you a lot for this great insight. With this knowledge, I can’t wait to create a new enticing experience for users.
Great article Sophia! Before I wireframe anything, I often ask myself “what are all the things that need to be a part of this product to accomplish the goals we’ve set?” And I whittle down from there to questions like “what are all the pieces that need to be on this page/screen?” I really like your systematic approach with the stickies. I think it helps make it more visual for other groups and likely spawns more creative thinking in terms of how objects COULD be related (i.e., “what if it worked like this?!?”). And I like the separation from design, because that tends to be UX and Creative’s domain. But stickies and discussion belong to everyone. Also, I find developers are super helpful when it comes to thinking up different ways objects can be related or described. Thanks for sharing your process!
Great article! simple and effective. It sounds like a very good start for my new project. The name OOUX is catchy and also descriptive enough!
Ack! So many great thoughts! How to address them all?
First off, as anticipated, one of the most “controversial” aspects of this article, here and on Twitter, has been what I am calling this. From where I stand, as a UX/product designer that understands the basic principles of database programming, calling it OOUX makes the most sense. And this is just in lieu of calling it Real World Mental Model Thing-Based Design. OOUX is simply catchier.
Adam, you make so many very good points. Your best question is: “What is the goal of this article?” Ah! Goals. I like defining them for my products, but somehow didn’t communicate the goal of this manifesto. The main goal is not to make UX more approachable to developers. It’s not to steal bits of their vernacular to “slip it in.”
The goal of this article is to present a methodology that I truly believe helps teams builds better products and websites in a more sane way. It has helped me so much in my work. I am a more effective (and happier!) UXer designing in this way. So I want to share it. No other ulterior motives.
But the ripple effect of this process CAN BE a smoother communication b/w disciplines on a cross-functional team. When you take any activity (domain-modeling, entity-relationship-modeling, object mapping, content-modeling) and say, “Hey! Let’s do this thing together! Let’s get Discipline A involved in this thing that traditionally siloed in Discipline B!”, two things can happen. One scenario is that Discipline B feels their toes are being stepped on and shout, “get off my grass!” The other scenario is that Discipline B says, “Come on over! When we overlap, less gets lost in translation! Yay!” Let’s hope for that latter.
As far as actions and adjectives are concerned – OF COURSE we have to address these! But I think the nouns should be in the driver seat. Adjectives and verbs need a noun. But a noun can stand alone.
The process I describe above is an abbreviated version of my full process. One step that I didn’t get the chance to share: taking an inventory of CTAs based on each object. What flows will “spawn” from each of these objects? For “ingredient” can user: save, favorite, follow, or buy?
Getting into sounds, feel, emotional design is a whole other layer that OOUX does not address – and doesn’t attempt to! We already have the tools for that. 🙂
A thought provoking approach. I need to think on it more and try some of the suggestions but I love the good theory and How-To here.
The noun extraction look spot on for a project I’m doing – will try it next week.
One of the biggest failures in any project is walls and barriers. The biggest reason designers and developers cannot come together is because we don’t have tools that create a functional interface. I appreciate the evils of letting a developer standardize the design right out of our work but that is because there are ego centric standards on both sides that resist evolving to protect rather than interface with each other.
The long and short of it is we have tools like Bootstrap that standardizes working mobile first. While it can be done without this, it also has achieved a level of function that improved the interaction of developers and designers. The next generation of web includes something allowing us to create custom web components.
Like it or not, Sophia is about to see her concept of OOUX come to life. Yet, don’t be afraid of this. Rather get out in front of it because this change is going to be bigger than when we stopped using table tags for layout. It won’t guarantee developers and designers will mix properly but it will create a giant step forward.
P.S. KnockoutJS, AngularJS and other solutions are already moving in this direction.
It should probably be called Component Based UI or something similar, but that aside the idea seems more then reasonable, it seems sort of obvious to me actually and that’s not meant as an insult. This is just the process of discovery and the “folding” that happens as one area of an industry rediscovers fundamentals.
As a full stack web dev of 20 years who is not fully a visual designer, I’m surprised by how much your end result looks like a database entity diagram. There was a period of time where people started saying “Don’t design the DB first, start with the UI”, but now that we are mobile first, reduced UI space, etc. there is a pull back to building a UI that closely maps to the data model because the data model embodies the fundamental reality of the thing you are building. The data model is the atomic structure of the thing.
This is such a great approach to designing UX. Coincidentally, I recently worked on the design of a provincial election site using a similar method. Rather than approaching the design as a series of templates, we began with content modelling and found it to be a powerful way to analyze and evaluate every decision, component and feature that went into the site.
Goals always remained at the forefront, which resulted in an easily scalable and manageable design system. As a designer, I was surprised by natural flow and low resistance of this approach, and how easy it fostered collaboration amongst the project team.
“There was a period of time where people started saying “Don’t design the DB first, start with the UI”, but now that we are mobile first, reduced UI space, etc. there is a pull back to building a UI that closely maps to the data model because the data model embodies the fundamental reality of the thing you are building. The data model is the atomic structure of the thing.” -Stephen J
YES YES YES.
I still agree to disagree that “UI” should be included any any labeling of this sort of work (*hops up and down, waves arms and shouts red-faced: “NOTHING TO DO WITH UI!!!”*) but otherwise I am right there with you, Stephen!
Especially that this seems “obvious.” I’ll take that as a compliment, not an insult! Yet when I teach this workshop to a room full of designers–gears grind, eyebrows furrow, and then, 3 hours into the workshop, light bulbs start to go off. That’s the reason I wrote this article, because when I teach the workshop, it’s obvious to me that many designers are not yet thinking “object-orientedly.” That said, I’ve had the pleasure of having so many people tell me that now that they have started thinking this way, they cannot unthink it! Most likely, because in retrospect, it’s so obvious.
Quite a thought provoking article. I like the way how OOUX brings clarity to bring UI and content teams closer. For different roles in a team, common understanding of the common goal has often been a challenge and this article addresses it beautifully.
@Sophia Voychehovski I can understand the desire to not call this UI. I was a bit too focused on end state. Your distinction is warranted and important here. You are mapping out, and improving the UX, by aligning the “bones” of the visual and structural model to the reality of the data model of the things you are displaying. Ultimately, this is the UX that makes the UI implementation not just visually appealing but a good experience and not a shined up mess.
We are seeing this in the video gaming space that I operate in also. We have been experiencing some of this by having to rework interfaces for mobile screens and then going “You know, this control scheme has merit on larger screens”. Mobile first, and prioritization for responsiveness is causing a very real focus on “what matters” instead of having 27 square inches of visual real estate to dump things into.
Great article, thank you. I’m primarily a developer and when I’m tasked with doing UX for a project this is basically how I approach it because I start asking the sort “Will object A be made up of lots of object Bs?” questions immediately.
I wish we had a tool set that supported this sort of design/thinking. Seems silly that so many of those objects will be defined over and over again for each step/context in the process: first for the conceptual part of the UX design, then again in wireframes, again in a UI program, again for for the database and yet again in both HTML and CSS. Ignoring content strategy, copy writing, defining error messaging, defining metrics tracking….
Were there a tool to facilitate the UX method described here that allowed the creation of robust objects, attributes and relationships it should be easy to then import that structure into other applications to make specific use of them. Say, importing into something like illustrator as a set of objects for doing wireframes or Sketch to do UI work.
Or into a code boilerplate generator that allowed a certain amount of developer interaction beforehand. If you could define the field types for each attribute, for instance, it should be pretty easy to get most of the required SQL boilerplate generated (or point it directly at something like a Rail generator). If you could define the HTML tags for each object/attr, a basic HTML structure with BEM class names based on context/labeling could be very useful. Sure, both would still require manipulation after the fact but it would save a lot of time and make this entire process a hell of a lot DRYer.
I’m counting on Mr. Vinh to sort this all out. 🙂
As a full-stack developer using object-oriented programming, I think using that terminology in a UX case is completely appropriate. OO principles will not be the same when comparing backend development vs UX/design, of course. The roles play a part in the terminology definitions, and that is ok. In the instance of OOUX, I feel what a UXer would call an object can be thought of as a content type in a CMS to a developer, the core content of objects being the fields, and the nested content being the taxonomy.
As someone who is also working on a large build using Drupal, I think this process is spot on. Thanks for sharing!
Thanks for the overdue article. You’ve done a great job of spelling out an embarrassingly under appreciated aspect of the real foundational work of UX. I kind of think of this as a litmus test between UX architects and “designers,” whatever that means these days. I certainly probe for understanding of this when interviewing.
“There was a period of time where people started saying “Don’t design the DB first, start with the UI” – I would suggest that what you’re describing here is an advanced and efficient way of doing exactly that. Because the abstraction you create by thinking from a user-centered perspective can be radically different from any number of abstractions that might arise from a purely data-centric exercise.
(Stephen, it sounds like you have data modeling background, would you disagree with that characterization? I think it’s the reason that most db architects sigh with frustration when asked to “just put it all in and we’ll figure out the relationships later.” I.e, the use cases are a critical piece of the business modeling that should drive the data architecture. I think a lot of *natural* data architects intuitively gravitate toward schemas that support the business model, and probably can’t conceive of anyone not doing so. But it’s shocking how many I’ve worked with who believe they see an inherent, use case-agnostic model, which often seems to reveal as much about them as it does about the data. If you (the royal “you” – not you, Stephen) model data and don’t spend a lot of time being frustrated by business stakeholders who can’t articulate their business processes, you may be doing it wrong 🙂
So I don’t see this as the process finally coming back around to some “truth” of the data schema being the prime driver. Rather, just that this is how we should take UCD deliverables to a level of maturity that cuts out a lot of unnecessary iterations, wherein the whole team has to grope around blindly pushing on templates that were designed with users in mind but no recognition of the importance of the structure of content within the UCD process, eventually coming somewhere close to this approach gets you.
On the naming controversy: I am by nature in favor of precise vernacular, so might share some of Adam’s concerns about OOUX as a term, and find it pretty easy to imagine it creating issues downstream if a large population of developers map OO to design processes that result in complexity. And it makes me cringe when terms get co-opted and morphed.
But at the same time, it’s a reality that our language evolves (or devolves :-), in precisely this ugly way, so if using OO for this supports moving “designers” forward into UX architects, more power to you. (I might like something like “Concept Structured” for denotative precision, but recognize that it would draw a lot more blank stares than “object-oriented,” which people have heard of and at least think they kind of understand.)
In the end, it’s always about that, isn’t it? Who are the intended recipients of the term, and for each of those populations, what does their cultural ethnographic context morph your chosen words into in their minds? How closely does it hew to your intent, and what unique things in their world change it’s meaning to them? Oh, for a research grant on this one 🙂
A great article & a great discussion – thanks to Sofia and everyone else.
I see the overarching idea behind this as being very similar to Concept Mapping, which is a topic I’m digging into right now. I guess you could also call it Business/Systems Modeling, as well as a myriad of other names (e.g. some people already mentioned Entity-Relationship diagramming).
In case anyone is interested to explore this in more detail (and doesn’t have immediate access to Sofia’s presumably excellent workshops), as well as dig into the philosophical background of why concepts are so powerful, I highly recommend an online course on Udemy aptly named “Concept Mapping”, by Per Emanuelsson.
The course is not tied specifically to UX or Software Engineering, and will help anyone who needs to efficiently deal with complexity of any sort and help make his/her ideas understandable and unambiguous for any number of people. Oh yeah, and you even get to brush up on your basic UML notation skills in process 🙂
In the engineering world, there is a shift underway. Object-oriented is giving up ground to functional programming. Not that OO is/was bad, just that something potentially more scalable and efficient has come on the scene.
The design thinking parallel for functional is activity-centered design. Map out the activities you intend to address and you’ll find yourself thinking more about what users do and think (functions) and less about what your system is (objects). Along that spectrum of activity “stuff”, you’ll find the points where your solution is relevant and where it needs to support other systems. Objects will surface out of that, but they aren’t the center of the universe.
In my experience designing around functions (or activities) results in a better product experience.
Sidenote: Job stories* are a natural way to communicate the requirements of an activity-centered ecosystem.
* https://blog.intercom.io/using-job-stories-design-features-ui-ux/
A very thorough and insightful write up about OOUX. Love the term and the ideas behind it.
I prefer the term ‘schematic UX’, as the process is more akin to building an OO schema (i.e. object-oriented database architecture) than a truly Object-Oriented Design. For example:
– Your ‘objects’ commonly have multiple responsibilities (this violates a key principle of Object-Oriented Design known as the Single Responsibility Principle), and must do so in order for them to be coherent. This is not something you can solve; it’s a fact of the schema approach you are taking;
– You are describing the ‘objects’ in terms of their attributes, rather than the messages being sent between them. Good OOD will focus on message structure over object structure (i.e. object structure will emerge from message structure), and
– It is generally a mistake to think of ‘Objects’ in an OOP program as being ‘real-world things’. They are meant to be abstract bundles of state and behaviour in a way that simplifies the message structure of a system.
However, none of the above strictly apply in the case of designing a ‘schema’, which is essentially an object-oriented map for a database. I suggest this approach be called ‘schematic UX’ rather than the more confusing ‘object-oriented UX’.
Also, I think this is a great approach to doing UX! I will be encouraging developers I meet to read this article.
Thanks for sharing! I love your approach, though one thing struck me: Atherton’s quote “Always separate thinking about real-world things from the documents which describe those things.” seems like a direct contradiction to derive the objects from the nouns from the brief. I totally get what you are doing there, but it absolutely depends on having a /good/ brief, what, as we all know I guess, is kind of a rare thing.
Really awesome article.
This is a super easy, interactive exercise to level the playing field when Strategists, Designers, and Developers are collaborating in the early stages of the project.
Regardless of what it’s called (IMO, OOUX is easiest for Deisgners and Strategists to understand), this an awesome exercise to ID content, its attributes, and relationships between content.
Again, tremendous article. Exactly what I was looking for!
Also, this is a great exercise to run with clients, especially if they don’t know what the content is yet. Excellent brainstorming exercise to uncover all the possible attributes and relationship. This would be equally valuable if you receive a good brief, or if the client has no idea how the feature will look.
_
Thanks for all the comments! I will definitely be looking into functional programming…wouldn’t that be ironic? UX moves to OO, programming moves to focusing on actions…like ships passing in the night!
I definitely hear all the comments on the title. And @SamMorgan – I do like “schematic UX.” Nice. I am going to mull on this and write a follow up soon on why I decided to call it OOUX.
Sure, a shared vocabulary is important, but, what is more important is that we are all thinking and talking about process and how to make it better. OOUX has been a revolution for me, and if helps you even a bit, awesome. Call it what you want! (And make sure to let me know how you mod it and make it better.)
…PS – here’s follow up post, looking back at the past week of buzz around this article: https://medium.com/@sophiavux/object-oriented-ux-a-post-publication-retrospective-a1fc99bc1f86#.sylphf4wu
BADASS. I shared this with my entire team and tweeted it out with screenshots.
It’s a goldmine. A must-read.
As a designer who also devs, it’s great to socialize the term and workflow of #OOUX because it leads into #OOCSS and api construction so fluidly.
Great thinking, Sophia. This is an excellent use of the human brain.
Amazing! The OO aproach is really like a Pandora’s box. I loved the conceptual layer that you identified and I agree with you in each letter.
Thanks for this article.
Sophia, thanks for an info-packed article. As a developer, I learned an awful lot from not only your post, but the links contained within (content!)
I can’t help but draw parallels with the OOUI & Naked Objects patterns, which I think are primarily coming at the same topic from the developer angle.
Very interesting ! Thanks for sharing
Thanks so much for this article. I’ve just done a basic object map for a side-project following your instructions and it’s clarified a muddy spot and raised an important question I wouldn’t have even thought about until after I’d started coding. Very useful! I’d love to see a follow-up on how you create the inventory of CTAs.
Presenting this methodology, which helps a design team build better websites and products is a great assessment. The application seems much more needed on mobile platforms, due to the shift in consumer behavior. Furthermore, stressing on the fact that the content and UI teams need to work more closely with each other seems the best way to maximize clarity and keep the final OS clean. This is keeping in mind that there is a definition of field types for each attribute that needs to be addressed.
This is a great article.
I admire it because it introduces a theory about design (think in objects) but focusses on teaching a process (object mapping). The magic of this approach is that a person could use the object mapping recipe, and get real value out of it, before actually having the conceptual epiphany about the theory of object oriented design. In fact, following the process is probably the best way to get to the epiphany, just as happened to you on the CNN project.
One suggestion I have is that, in my experience, if you refer to the work in step 2, Define Core Content of Objects, as Creating the Data Model, you immediately engage your developer stakeholders while at the same time giving your non-developer stakeholders an intuition about this “data model thing” the developers keep talking about.
Nice article!
I suspect that a lot of people who wrestle with designing large complex sites are kind of doing this anyway, but it’s nice to frame it in this way.
I don’t see any harm in calling it ‘OO’. That’s kind of exactly what it is anyway.
Very nice article. I have developed a similar approach, but yours is far better.
One question: How do you represent object transactions?
For example, suppose I design a service that transfers money from an account to another. My cash does not directly go to others, but it goes to a (virtual) teller first and the teller validates things and performs transferring.
Any suggestion? or is it beyond this topic?
‘OO’ seems fine to me by the way. OO does not necessarily means an approach of implementing. It can be used to analyze.
Sophia,
Awesome Article. Really in Depth to the nitty-gritty.
Have no issues calling that OO UX Design and I actually like it. It gives it the right analogy to navigate your mind and to think of objects as opposing to screens.
Thanks again. I am a fan! Peace.
Great article with lot’s of solid points and sound ideas.
“Object oriented” might not be the right way to express what you mean. OO inherits a lot of baggage from the programming paradigm, you don’t really need. Further more, the programming world is not moving to OOP from FP. The two programming paradigms are complimenting each-other and are used in different ways, not much competition between them.
I would love to read more about your experience with this approach when you get to designing a bigger system from scratch. I think the way you should name your approach should be the title you are going to give to an object created entirely of other objects 🙂
Many good points in this. I was discussing with a colleague that the ‘object’ could be either content as you described or actions/functions depending on the application space. One may take on slightly more importance than the other and then would become the main focus for the mapping process you outlined.
Thanks for all the additional comments and new ideas!
For now, I’ll continue to call it OOUX. It seems to fit the best for me, and at least 51% of the community seems to agree. Or not be offended by it. Sigh. 🙂
Please stay tuned for some follow-up articles coming in next year. Currently, I’m working on an article about bridging OOUX into interaction design. Then I will move into how OOUX can help with project planning and estimation.
Right now, I am actually trying to write a spec that is framed around the objects in the system…and so far it’s working out pretty nicely. If the dev team accepts it (and likes it) I’ll do a little article on that, too! OO-Requirements?!
I am also working on a video series about prototyping in Axure with the OOUX mindset…
LOTS OF STUFFS ON THE HORIZON! So…(you know what’s coming)…if you heart OOUX, make sure to add me on the twitters to get those updates. @sophiavux
Happy Holidays!!!!!
In the past I have arrived at a similar place by starting the design process with entity relationship diagrams (ERDs), but your framework folds this concept in and provides a solid approach for prioritizing. This seems to be the biggest value of your approach: Across the multiple dimensions of objects, relationships, mental models, etc., how do we prioritize things as they relate to the goals of the user? This is an excellent starting point for an inspired and informed design.
Looking forward to your follow ups to this article.
This was very helpful for me! I look forward to applying OOUX at work.
This was very helpful for me! I look forward to applying OOUX at work.
Thanks so much for the write-up. This is now my go to methodology for thinking about product architecture. BTW this reminds me of what Paul Adams touched on briefly while describing architecture in https://blog.intercom.io/the-dribbblisation-of-design/. I wonder if you see the same parallels.
Sophia,
Great article! Thank you for the clean and simple overview. I’ll be sharing this in the future, to at the very least save myself from having to explain it less eloquently. 🙂 The semantic discussions always make my brain hurt as well. I’ve been referring to my very similar approach as Entity Based Modeling. …or other variations on “entity” depending on what seems to grok with different teams. OO is a great analogy and does bring out the right thinking, but I can see how getting into the details of the semantics may lead to bike shedding.
I’m curious if you’ve considered ways to abstract the Actions in a similar manner? After the Entity relationships have been established, I find very exciting discoveries when adding the interactive dimension to the mix. If done appropriately of course. Otherwise you simply put the good old fashioned actions on top of a new cleaner ERD. With the different abilities that the multitudes of devices provide, there are just as many discoveries in automation and behavior to be made by taking the same approach to the interaction layer. Personally, I’ve been using the terms ‘Tasks’ or ‘Events’ to try to consciously separate the human element from the actions. By breaking those apart I’ve had a lot of luck discovering new ways to automate or restructure the Actions that a human will take in the new system.
JAx
Great article. So interesting to think in terms of focussing on things/content first, then how they’re going to interact with that content.
Thinking in terms of Things is pretty intuitive. But for some reason Things tend to get relegated to assumptions when we’re designing user interactions.
By the way, the term ‘object oriented’ makes complete sense to me both as a designer and someone with a programming background.
I’m a software engineer tinkering with UX, and while I follow the rationale of reducing the impedance mismatch between an OO data model in the back-end and front-end, what if I said that the software industry is no longer so totally sold on OO?
Functional languages are gaining traction, and many data processing systems view the universe as sequences of actions and events which flow through transformation tasks, even at the hardware level streams, tasks and pipelines are the common model.
It would be strange if the UX world would embrace OO design and abandon task and action oriented thinking, while the software industry did the exact opposite, leaving us with an impedance mismatch all over again.
I’m a software engineer tinkering with UX, and while I follow the rationale of reducing the impedance mismatch between an OO data model in the back-end and front-end, what if I said that the software industry is no longer so totally sold on OO?
Functional languages are gaining traction, and many data processing systems view the universe as sequences of actions and events which flow through transformation tasks, even at the hardware level streams, tasks and pipelines are the common model.
It would be strange if the UX world would embrace OO design and abandon task and action oriented thinking, while the software industry did the exact opposite, leaving us with an impedance mismatch all over again.
Don’t think that there’s a cross-link to this more recent ALA OOUX article…
https://alistapart.com/article/ooux-a-foundation-for-interaction-design