How to start any UX Project (It’s NOT sketching User Flows)
I’ve got a design challenge for you for the holiday season. Let’s call it Giftify. Here’s the brief:
Design an app that helps users become better gift-givers. We want to help our users never worry about giving the same gift to the same person twice!
Many of us have a roster of gifts that we like to give over and over: those few dozen favorite books, that amazing garlic press, that wonderful body lotion, that fancy coffee… but, it’s easy to lose track of who you’ve already sent what to. This application helps users manage a list of those gifts and remember what they gave to which loved one and for what occasion.
This seems relatively simple, right? A B2C app for tracking gifts.
So, imagining this is all the direction you have, how might you start solving this problem? What would putting pen to paper look like?
The problem with starting with flows
Today, Object-Oriented UX is my #1 tool for figuring this out. (Surprised?) But before OOUX, how would I have gone about this design challenge? What would 2011-era Sophia do?
In the interest of time-travel, I tried to empty my mind of everything I’ve been practicing and teaching for the last decade.
Here’s what happened:
I started with the most obvious task flow: adding a new gift. That flow branched into other creation flows. Verbs overlapped other verbs and before long, I had a respectable-looking first pass of low-fidelity screens.
But here’s the problem with starting with the task flows and even the lowest-fidelity UI:
I started designing how someone would add a gift, before really defining a GIFT. I started designing how someone would get things done in a space that I had not yet designed.
I skipped over all the tough questions like:
What’s the difference between a product and a gift? What’s an “idea for a gift” like “a digital picture frame for my mother-in-law”? And how will recurring occasions work?! How does adding a birthday to a contact relate to a list of occasions? Are birthday-occasions auto-created for each contact’s birthday?
I swept the tough complexity under the rug. What’s going on here? Here are the kinds of underlying thoughts (conscious or not) that go into this complexity avoidance:
“We will deal with this once we are in higher fidelity screens.”
(Hello, rework.)
“The business/SMEs will let me know if this makes sense. It’s their job to think about that stuff.”
(Maybe they will raise questions…3–4 weeks later after looking at your screens multiple times. Again, hello, rework.)
“The developers can figure out that recurring occasion thing…I’ll just make a checkbox for ‘recurring’ and we can worry about the details later.”
(Sure, and since they are pressed for time, they will do what is easiest from a dev-perspective, not necessarily what is best for the UX. Hello, UX debt.)
“I don’t have time to ask all of these questions — because they want screens, like, now.”
(We’ve got to start pushing back designing screens for systems we don’t fully understand.)
The biggest problem with the “normal” UX process
I believe that this is the biggest problem with the standard UX process: we put the cart before the horse, starting with the how (the screen-based flows) before we establish the what (the actual things). We focus only on the verbs and have no part of our process to identify what nouns the verbs are affecting.
When we add some noun-based thinking into our process, magic happens. Balance is restored.
Let me be clear: I am not saying that the nouns/objects are more important than the verbs/flows. On the contrary. In most of the systems we design, it’s all about getting shit done. Users come to complete tasks that help them meet their goals. I am simply saying that the nouns/objects should be defined first and the verbs should then be derived from the nouns. (We need to know if it’s a BALL or a BABY before we decide to kick it or feed it.)
A strong conceptual model supports and serves all the verb-y stuff. Our task flows and UI become more clear and intuitive. Promise.
Enter Object-Oriented UX
When we untangle a system’s concepts and their relationships, we uncover all sorts of gnarly complexity early on. Uncomfortable? Maybe. But with the right tools, it’s not only hella-rewarding (and makes you feel like a UX-boss) — it prevents so many headaches later in the process.
So, let’s dig in a little, OOUX-style. Per usual, I’ll be capitalizing objects so they jump out at you. Let’s take a look at the concept of OCCASION.
Simply defining OCCASION gets hairy. What’s the difference between “Christmas 2022” and “Christmas”? Is one an OCCASION and the other is an OCCASION TYPE (which might just be metadata on the OCCASION)? What about Birthday, Mom’s Birthday, and Mom’s Birthday 2023? If I want to see a history of the gifts I gave Mom across all occasions…I need to figure out how all of these things relate to each other.
In the past, I’ve used variations of this design challenge in my OOUX Certification Course. During an Office Hours session in Cohort 4, I created the System Model below as we simply tried to figure out how OCCASIONs would work.
Before we design how a user might add a GIFT or set up an OCCASION, we define what GIFTs and OCCASIONs actually are and how they connect in the system.
We map out all the attributes and connections between objects with an Object Map:
If you are interested in seeing how this whole design challenge shakes down, make sure to check out the ORCA Handbook where we take this gooey problem through all 15 steps of the ORCA Process. And if you are interested in learning more about Object Maps and OOUX in general, check out the OOUX Launch Guide.
In a nutshell, to communicate properly, we need clear nouns and verbs, working together. And at the end of the day, UX is communication.
