Cookie Consent

By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.

Cookie settings
Podcast Episode

051 - (ORCA Series #7) - Object-Oriented User Stories from Santa's Workshop

In this seventh installment of the ORCA Series, Sophia brings some holiday cheer while covering CTA Requirements. Revisiting the Santa Delivery App from ORCA Series #6, Relationship Requirements, she explores the four ways you can upgrade your basic user stories, plus how to use AI to help you fill in the gaps you might have missed.

Image Credit:

To get access to this guide, enter your email below. If you are not already part of our OOUX world, you'll be added to the weekly OOUX Newsletter. You can, of course, unsubscribe at any time! We will never sell, spam, our otherwise disrespect your information. And we strive to provide only top-notch valuable content in our newsletter.

Listen here

Find your player

Episode Transcript

051 - ORCA Series #7

Sophia: [00:00:00]

Intro

Sophia: welcome to the object or a UX podcast, a podcast about tackling complexity, head on gracefully organizing massive amounts of information and designing scalable future proof and of course, naturally intuitive object oriented user experiences. And OOUX is a powerful blend of information architect, business analyst.

Facilitator and UX strategist. If this sounds like you or what you aspire to, you are so in the right place. I'm Sophia Prater, UX designer, chief evangelist of Object Orient UX and your host. Let's jump into it.

Beginning

Sophia: What's up OOUXers? Sophia here. And today we are continuing the Work a series with step number seven, CTA requirements.

We're going to get into object oriented user stories today. And I've got my pumpkin spice latte here. And we are we're continuing on with the holiday vibes. We're going to pick up that [00:01:00] exploration that we did on our Santa delivery app with relationship requirements. So check out that last episode, that was number six in the ORCA series.

And in this series we are going through all the steps of the ORCA process. You can check out all the episodes that we've recorded so far at OOUX. com slash hi, that's H I, slash ORCA series. OOUX. com slash hi slash ORCA series. And you can get all of the episodes there. So we're continuing on. We're on step seven.

Now we are deep within the requirements around getting into the requirements around calls to action. So we're going to explore a few CTAs on objects like toy design and gift for our Santa delivery app. And I'm going to get into basically like the four ways that we upgrade. Your run of the mill user story and upgrade them into these object oriented user stories.

There's four main ways that we do that. I'm going to talk through the difference between a [00:02:00] user story as you might know it and this, I believe, very much upgraded version of a user story that we that we build in the ORCA. process. All right. I'm also going to get into, because we're going to be talking about toy design and gift, I've got to talk about defining closely related objects.

Okay. So we're going to talk about how to define those. We're actually going to go through a little bit of object definition. So we're really clear on what is the difference between a toy design and a gift. They. Sound very similar, don't they? And we're going to get into some actual object oriented user stories.

I'm, I wrote some, we're going to talk them through and then I'm going to wrap up and we're going to talk about AI some more. I'm going to show you actually how to use ChatGPT to explore your object oriented user stories and potentially help you think of things that you hadn't thought of before.

Because That's, it's actually a really good use for AI, is to help us expand our thinking, actually, instead of contract our thinking, [00:03:00] right? I think I'm not gonna, Sophia, don't go on a tangent right now, but what we want is we want artificial intelligence to be the opposite of an echo chamber. How could it actually help us think a little bit more broadly?

And I think this is a really good application of that. Okay I want you to remember that this series is really designed as a supplement to the OOUX Masterclass. Not a standalone course, alright? Although I'm sure you're going to get a ton out of this series overall, even if you haven't enrolled in the OOUX Masterclass, but we are jumping into some advanced thinking here.

If you aren't enrolled in the OOUX Masterclass, but you like the thinking that goes on here, please go check out this epic online course. You can go to OOUX. com slash masterclass to learn more and maybe even ask for it for Christmas or buy it for yourself for a whole new way of thinking about UX.

And actually even more fun at work. And I know you've heard, and you've heard me talk about it, and you've heard others talk about how OOUX can help make your [00:04:00] designs more intuitive and help you collaborate better with stakeholders and developers and blah, blah, blah, blah, blah, blah, blah. But I am encouraging you to get yourself an end of the year gift.

So in that vein, I really want to emphasize how OOUX can actually bring so much more joy to your work. And since we are at this for a large portion of the day. So much more joy to life in general. So here's just a few testimonials that speak directly to that. So Carolyn Silver James says, It has become key to my happiness as a designer, and I wouldn't ever want to be without it.

Jen Dionisio says, I'm certain that OOUX and the ORCA process is what I've been looking for to put more consistency, rigor, fun, and collaboration into our design process. Kim Bennett says, It has been a fun and fruitful journey learning the ins and outs of OOUX. I'm already starting to see how this approach to breaking down complexity, asking deep questions, and really [00:05:00] digging into the objects within a system is making me a better content designer.

Mary Malin Karn says, The ORCA process provides a visual framework that is scalable to fit into any business schedule and timeline. In other words, it makes the information architecture process more meaningful and fun. And Tara Kimura says, Untangling complexity, thinking systematically, designing intentionally.

This course delivers on all three of these promises, and at the same time is fun and joyful. Each week, my skills and confidence bloomed. Okay, so head over to OOUX. com slash masterclass to enroll in a course that will up level your UX skills, reduce headaches. I actually, the other day, I called this Tylenol for product designers.

But also it may be the key to help you have more fun and invigorate your passion for this work. Okay, object oriented user stories. Let's get into it. So a user story traditionally follows the format. As a user, I want to take this action so that I can [00:06:00] accomplish some goal. You've probably heard that sort of fill in the blank. Mad lib style format. So here's the four big upgrades that object-oriented thinking and the ORCA process can bring to the writing and the design of a user story. So in OOUX, first off, we make sure to define what role the user is, not just as a user. We make sure to say as a, in this case, as a elf.

administrator or as a clause, right? As one of the as Mr. or Mrs. Clause, right? Or even as a child, right? Maybe there's an interface there, right? Maybe like writing the letter is considered an interface if we're talking about our Santa app. Okay. So we go directly into the role. We are not shying away from permissions from that monster.

We we tackle that monster head on in OOUX. So we're going to definitely, we're going to, we're going to make sure to be clear about the role and thinking about permissions. Second, we make sure to know what [00:07:00] object. is being acted on. Okay? So we make sure to connect the verbs to our nouns. We did that back in CTA Discovery, and we are of course carrying that through.

Okay? So it's not just as a user, I want to take this action. It's As a certain role, I want to take this action on this specific object. We make sure to make that clear in the user story. Third, we make sure to go deep when we explore the so that, basically the why. So we actually, we ask why two to three more times.

To really get into the motivations, so it's not just as a senior level elf I want to change the status of a gift so that I can make sure the status is up to date, right? We go into why is that important? And why is that important? Okay, so this really helps us test our assumptions, realize that we do we have any blind spots?

What are the actual motivations of our different kinds of users to do these certain actions? [00:08:00] And fourth, we add one more piece that really makes a fully, nicely, rounded, compelling user story. And that is the win. So we don't just talk about. The who, and the what, and the why. We talk about the when as well.

We get into the context. What is going on when a given role takes this action on the object? Are there things that have to happen first? What happens immediately afterward? What else is going on in the domain? Even we might think about When they're doing it, what sort of environment are they in?

And we'll explore this. Are they going down a chimney? Are they at the North Pole sitting at their desk? Are they on a sleigh? We can think about when this is likely to be happening, and that can actually really help us design the interface. Our user story, Mad Libs, is much more like As a role, I want to take this action on this object so that blah, blah, blah, blah, [00:09:00] blah, when blah, blah, blah, blah, blah, okay?

So when we basically, when we blow out our CTA matrix, we add why and when columns, okay? And that gives us all the ingredients of these really fully formed, fully fleshed thought through object oriented user stories. Okay, so going back to our example, let's talk a little bit, because we're going to be focusing on the toy design and the gift object, and I'm going to be talking about some CTAs that different roles might have on those two objects.

But first, let's talk about what is the difference between these. ThEre's some good ways to actually differentiate closely, define things. So I can actually just give a definition. But some things that I like to do, some sort of shortcuts, is to especially when the definition, like toy design is, you could say, toy design is a blueprint for a gift.

Alright, that's a great definition. Really succinct and nice. I could also give some really key attributes. And to differentiate, these are the attributes that might go on the toy design versus the [00:10:00] gift. So we've already probably done some object mapping by the time we get to this point in the process. But even when we're early on, earlier on in the process and we're trying to differentiate these, sometimes we might bring some attribute discovery forward so that we can say Okay.

A toy design is going to have a attributes like popularity and average make time, while the actual gift has the actual make time. It has a status on whether it's delivered night or not. It even has the gift is what has a delivery date. A toy design does not have a delivery date. Okay. A toy design can have an inventory.

Which is actually the number of available gifts in storage. It might also have a number of gifts given. So we have 562 of this toy design. We have 562 gifts in storage, and we've given 5,801 of these gifts. And then also instances is really important. So an [00:11:00] example of a tour design might be. The wooden and glass version of Mancala, the game, or Mancala.

Mancala? I used to love that game. Or the Pogo Stick 5000. Alright, so that might be the toy design. While Vivian's Pogo Stick 5000 is the actual gift, or Henry's wooden and glass set of Mancala that was delivered Christmas 2023. So gift is going to have that delivery date. Gift is the thing that can break.

A toy design doesn't really break, right? A gift has one parent toy design. So what I'm doing when I have these really closely related objects, which are likely objects in a tree system. If you're thinking tree systems and junction objects, you are on the right track here. And when you get these really closely related things.

A couple things that can really help, describing the relationship between those things, like I just did. A gift has one parent toy design, [00:12:00] a toy design has many gifts that are in storage you can also describe key attributes to show the difference between those, like average make time on the toy design versus actual make time on the gift, okay?

And then you would have that roll up, right? So the actual make time of the gift is going to roll up into the average make time of the toy design, so that we can say, This, Henry's Mancala, took 2 minutes and 42 seconds to make. On average, this toy design, that Mancala toy design, takes 2 minutes and 30 seconds to make.

Okay? And then we can track different elves maybe in their make time, okay? We can do things like that. So a gift, and maybe we can say a gift is made by one elf. Or is it, a gift is made by many elves, but a toy design has one creator elf to it. Okay, like one kind of like owner creator. So we can start connecting it to the other objects to show the difference between those.

Okay, and also the instances. Did I [00:13:00] mention instances? Yes, the difference between Vivian's Pogo Stick 5000 and just the Pogo Stick 5000. Okay, let's go through a few fun object oriented user stories. Okay, the first one I want to talk about is, as an elf, I want to update the stage of a gift. Okay, so the stage being work in progress, the paint is drying, it's finished, it's wrapped, it's packed, it's delivered, okay?

So as an elf, I want to update, I want to be able to update that stage. Why? Okay, so that I can ensure that we have an accurate inventory. of our toy designs based on the requests. That's a good reason and I'm going to ask again. Why do we want an accurate inventory? Okay, so that no call goes unanswered, that no wish goes unanswered.

Why do we not want, why do we want to make sure that wishes go unanswered? Why? So that we can maintain Santa's reputation and quality control. So asking it just a few more times, we get back to oh, this is our [00:14:00] reputation on the line, right? Okay, and when? When do we do this? When is an elf likely to be doing this?

This is probably while they're in the workshop, they're on the job, they're making the toys, they're packing the toys, they're like in the, on the factory floor doing this, right? So it needs to be really easy to move a gift through those stages and to mark those stages as, the paint is drying because they're probably doing it, multiple times a day.

Okay, so there we have our very first Objectory and user story for our Santa delivery app. Okay, let's do another one. So as Santa, I want to update a gift stage to delivered. Okay, so maybe Santa's not updating those other stages as much. Santa's not on the factory floor. But it is going to be up to Santa to mark a gift as actually delivered.

Okay, why? Why do we want to do that? Why does Santa want to do that? So maybe because, and this is something where I'm like, actually, I don't know why. Why do we need to mark things as delivered? Alright, so I might [00:15:00] interview Santa at this point and say why is it important to actually mark these? Do we even need that?

And Santa might say, oh, because I want to be able to see the progress for the night. I want to see how many to be able to see 57 percent delivered, I need to be marking these as delivered. Okay, so then my navigation system can also monitor speed and, magical fuel usage to make sure I get all the gifts in before sunrise.

Okay. Alright, so when is this happening? Santa lets us know. This is usually happening on the way up the chimney. Usually, I gotta do it immediately or I'll forget to do it. So I do it right as I'm going up the chimney. Sometimes it's en route to the next stop, but it really should happen immediately after.

And then we, through discussion, we might say maybe it would be good for our system to detect the gift is delivered. Maybe it's like it's left to the sleigh, that we can do like some sort of proximity. Tagging or something like that, because we have magic on our side too, right? And maybe Santa just has to confirm a successful delivery.

It just says hey, it looks like you've just delivered these three gifts. Is that right? And we could say, would that work? Santa, would that make your life easier? [00:16:00] So we might actually even change this as Santa, I want to confirm that the gift has been delivered. All right. So we might even change the design through doing this work.

Okay. Are we having fun? I'm having fun. I hope you're having fun too. Okay. I got a few more for you and then we'll get into the see what chat GPT comes up with. Okay. As an admin, maybe this is as an elf admin, I want to decommission a toy design. And this potentially could be Santa Claus or or Mrs.

Claus, but this is our high level admin roles. They want to be able to decommission a toy design. Okay. Why? Why would we do that? Okay, so that we no longer use this toy design as gifts, right? That would be the obvious thing. Okay, that, and that is sometimes when I'm teaching the course, I will often poke, and if you're a certified strategist, you know this, I may have poked at you and said but why would somebody want to do that?

And when, why would they want to do that? So I will often get whys like this. Okay, I want to [00:17:00] decommission a toy design so that we no longer use that toy design as a gift. Alright, you're stating the obvious, and how useful is that actually? Okay, why would we not want to use a toy design as a gift?

Okay, maybe there's a couple reasons. There was an issue with the toy design. It was high breakage. Maybe it just just really it always would break when it was in Santa's sack. Or high breakage the kids would usually break it, right? Or maybe there was like, low Christmas morning joy factor.

It just wasn't sparking enough joy. Maybe a new toy design has replaced it. Maybe we're on the pogo stick 6, 000 now. Okay. So we don't need to deliver the pogo stick 5, 000. We just have a better design. All right. So through this thinking, we might think, okay, so then should we suggest like every time a toy design is decommissioned, maybe there are some followup actions there that need to happen.

Okay. Maybe we say, can you put in a reason code? Why are we decommissioning this? And then give the option to replace. With [00:18:00] another toy design trickling down to any planned gifts that are already nested within that toy design, okay? When is this happening? So we might, through interviewing and through understanding our users more, we might realize this is usually happening in January after we get all the report back, all the reports back on how the toy designs performed, also in planning, maybe also in like the planning phase during October when toy designs are reviewed and new toy designs are presented to Santa.

Okay, so it's like January and October, but it's usually like the downtime or like the initial ramp up time to the season when that's happening. Okay, let's do one more. As a senior elf or Santa, I want to propose a new toy design. Okay. Why? Maybe so that we can satisfy a new theme of child wishes.

Okay. Why would we do that? Maybe so that we can spread as much joy and uphold Santa's reputation as a good listener, right? To show that we are actually reading those letters, right? We're going to [00:19:00] have to propose new toy designs. And when does this happen? Maybe this happens while we're viewing our wishes to Santa and having set aside many wishes because we don't have a toy design to satisfy these wishes.

So maybe we have some sort of like tipping point of if there's about a thousand wishes, then we get into the point where we propose a new toy design. Okay. So now it's wish an object is letter and object is toy request an object, we might think about that as well, because that could trigger the the opening to propose a new toy design.

And this is the one that I played with ChatGPT. And y'all, I got the best answers. This. Which I was cracking up. First I asked I started off asking Y'all, I had no expectations for this. I was like, this is so weird, and I gave no context at all. I just, this was my prompt. Why would Santa want to propose a new toy design to the elves?

Alright, so then I asked it both [00:20:00] ways and I got different answers. I asked, why would Santa want to propose a new toy design to the elves? And then I asked, why would the elves want to propose a new toy design to Santa? And I got so much cool stuff. So I'm just gonna, I'm just gonna read, I'm going to summarize read to you, but this is just so good.

Santa might want to propose a new toy design to the elves for several reasons, innovation and variety. Introducing new toy designs keeps the offerings fresh and exciting for children. It adds variety to the gifts Santa can deliver and ensures the toy selection remains innovative and appealing. Two, they, maybe they give 10 different ways.

They, chat, GPT, it gives 10 different ways. Two, changing trends, just like an industry, toy preferences and trends can change over time. Santa may want to propose new toy designs to keep up with current trends and meet the evolving interests of children. It goes on to talk about competing with technology, educational value, sustainability, [00:21:00] efficiency in production, feedback from children, which is really the only one that I thought of, but sustainability. Oh my gosh. Great. Efficiency in production. Elf engagement. Involving the elves in the design process can boost morale and creativity among the workforce. Santa may propose new designs to engage the elves in exciting and challenging projects, fostering a sense of pride and accomplishment.

Market demand. Maintain. This is my favorite one. Number 10. Maintaining the magic. Santa understands the importance of The magical experience associated with receiving gifts, proposing new and enchanting toy designs helps maintain the magic and wonder of Christmas for children everywhere. And then when I asked the other way why elves might want to propose a new toy design to Santa I got creativity and innovation.

Elves, like any skilled artisans, may have a desire to express their creativity and showcase their innovative ideas. Proposing new toy designs allows them to contribute fresh and [00:22:00] original content. Concepts to Santa's workshop. Then we go to meeting children's preferences, enhancing the magical experience, improving efficiency, sustainability is mentioned again, response to feedback skill development.

Elves may see proposing new toy designs as an opportunity to enhance their skills and capabilities. Taking on new challenges and learning to create different types of toys can be personally fulfilling to them. The elves competing with modern toys came up, elf morale came up, collaboration with Santa, proposing new toy designs as a way for the elves to actively collaborate with Santa in shaping the Christmas experience.

It reinforces a sense of teamwork and shared responsibility in delivering joy to children worldwide. This was shocking to me because it came up with so many other new ideas and some things that I could throw out, but other things it was like, oh my gosh, this just resonates so much that this is a reason or it could give opportunities for for [00:23:00] confirming some of these.

really interesting ideas through research. How can we confirm some of these? But in understanding the why behind just such a simple thing as proposing a new toy design, this can really help with actually how we would design the product, right? How would we, and also prioritizing different CTAs. So once we get to the prioritization round, which we, that's the next round that we're going to be getting to.

We got to get through attribute requirements. That's going to be next up in the series. But when we get to the prioritization round, when we start deciding what we want to cut, if we've gone through this exercise and gotten help from something like a tool like this to really get this pretty beautifully well rounded.

Examples. This can help us really prioritize different CTAs. So play around with chat GPT. Okay. So I want to give a big shout out to Kyla Beals from cohort nine, who she was the first one I think that used chat GPT to inspire her CTA requirements for her design challenge. Blew me away how she did [00:24:00] that and, picked and chose what she actually decided to put into her CTA matrix, but it was really interesting to see how she used it.

Kyla, big shout out to you. Really inspiring. Okay. So if you want to get more into this and start practicing the CTA matrix and all the other amazing pieces of the ORCA process, sign up for that masterclass. OOUX. com slash masterclass. Maybe get yourself a wonderful holiday gift that will keep on giving for years and decades, and maybe for your entire career to come.

This will also get you set up to join us in a future cohort. So again, all the, I say again, because I've said this in previous episodes, but not this episode. All the material in the OOUX Master Class is the same material that we use in the certification. All right, so when you want to join a certification, you simply upgrade to that experience.

You don't pay any more. You basically are just paying in two installments, buying the material, and then you buy the experience of the of the certification cohort. Our next certification cohort 10, does not have [00:25:00] a set date yet, but we're looking at late spring or summer of 2024. It's definitely going to be a few months.

If you want to go ahead and start reaping all the rewards of the ORCA process and really get that professional grade training, come on in. Come on in. We're, it's waiting there for you. And the community is waiting for you too, to answer all of your questions and help you along the way. Have a wonderful happy holidays.

Cheers, and happy OOUXing, and I probably won't hear from you until next year.

Outro

Sophia: Thank you so much for listening. I truly hope you enjoyed this episode. Please visit objectorianux. com slash podcast for show notes. Our soundtrack is Fighter by Ruby Vell, courtesy of Sugaroo Records. Happy OOUXing!

Subscribe to OOUX Podcast

A dive into the weeds on UX systems, information architecture, human psychology, data wrangling, structured content, UX process, and above all simplifying the complex.

Join OOUX Happy Hour Meetup

OOUX virtual meetups feature amazing guest speakers, Q&A, discussion, networking breakout sessions, and important OOUX updates. Bring your coffee, wine, or whiskey.

Related Resources

050 - (ORCA Series #6) - My Cat Saving Fire Department with Holiday Vibes
050 - (ORCA Series #6) - My Cat Saving Fire Department with Holiday Vibes
Sophia V. Prater

Sophia delivers episode #6 in the ORCA Series: Relationship Requirements. Sophia expands on "My Cat Saving Fire Department," the power tool for analyzing object relationships. Using the example of Santa delivering presents, she illustrates how to apply this tool to understand relationships between objects, plus a rule of thumb for recognizing tree systems!

listen
Open in new tab
listen
049 - (ORCA Series #5) - Object Guide Strategies for Ridiculous Clarity
049 - (ORCA Series #5) - Object Guide Strategies for Ridiculous Clarity
Sophia V. Prater

In this fifth installment of the ORCA Series, Sophia discusses Object Requirements, how to skip ORCA steps & loop back to them as needed, as well as ways to customize the ORCA sprint, plus the potential use of artificial intelligence in generating object guides.

listen
Open in new tab
listen
See all resources

Spotlighted Resources

The OOUX Launch Guide
The OOUX Launch Guide
Sophia V. Prater

In this FREE guide, get the inside scoop on the creation story behind OOUX, learn the most critical activities in the object-oriented framework, and guide you to the best resources for learning the foundations of OOUX. You'll get the rocket fuel you need to go from 0 to 60 in just a few hours.

get it
Open in new tab
get it
UI Breakfast Podcast. Episode 229: Object-Oriented UX with Sophia Prater
UI Breakfast Podcast. Episode 229: Object-Oriented UX with Sophia Prater
Sophia V. Prater

Sophia was interviewed on the UI Breakfast Podcast. How can object-oriented UX help designers solve complex product problems? You’ll learn why object-oriented thinking is well-suited for design processes, how a shared vocabulary enables collaboration, practical mapping tips, and more.

listen
Open in new tab
listen
Search all resources