|Mahtab||Welcome to episode 006 of the Crux of It. I am Mahtab Rezai and the Principle and CEO of Crux Collaborative. We're a user experience consulting firm specializing in regulated industries. Today, I'm joined by my colleague Rebecca, who is a Senior User Experience Consultant, and we're going to be talking about fringe use cases, sometimes called edge cases. Hi Rebecca.|
|Mahtab||How are you?|
|Rebecca||I'm great. How are you?|
|Mahtab||I am so happy it is Friday.|
|Rebecca||Me as well.|
|Mahtab||All right. So let's do this. First of all, in case anyone doesn't know, what the heck is a fringe use case or edge case?|
|Rebecca||A fringe case, sure. I can define that. Typically when you look at a system and an experience, you have a primary path and then you have the alternate paths. Something that's unusual in the customer journey.|
|Mahtab||Awesome. So, that's a really good segue into talking about our design process and how we use use cases or user stories, customer journeys, etc. So the first thing we do, and I'll just give like a high level overview because that is not the point of ... our process is not the point of this podcast, but I think it's important to just set the stage. So, the first thing we do is identify user objectives: what do users want to do? The next thing we do is identify business objectives: what does the company want users to do? In an ideal scenario those two things match up quite well.|
|Rebecca||Occasionally they do.|
|Mahtab||Yes. Then we map those things to features and then define user stories or flows, we understand what the constraints are that we're working with – and then we get to sketching. We do that with a client collaboratively which we've talked about in other podcasts and in articles. Typically when we're starting, we're sketching the happy path.|
|Mahtab||The thing that happens most of the time. So, a super-easy example of that is if you're designing a tool and it has a registration process, you're typically asking people their first name, their middle name, their last name, you're asking them their gender. You're asking them if they're married, and what their spouse's name is and their spouse's gender. Pretty simple. You want to start by designing for that simple path. You want to make sure whatever you have makes sense and works well. But there's a lot of things that can happen in there, so some people have middle names, some people don't have middle names. Some people have first names that are exceedingly long. Whatever that is, then you go back and you start to think of fringe cases.
You start to think of things like, "Okay, what if someone doesn't have a middle name?" And, "Hey, maybe we shouldn't make that a required field." Or, "What if their spouse or partner is the same gender as them?" Those are all fringe cases. You're not starting out thinking like, "Okay, we need to design for no middle names," but once you have your idea or your construct in place then you start to consider them.
|Rebecca||Exactly. Starting with that primary path but still keeping in mind as people will talk about it, right? Okay, we're going to need this, this and this but then somebody is going to say, "But I don't have a middle name. My spouse is the same gender as me, so what about that case?" But keeping track of all of those so that you make sure that they get addressed at some point definitely is key. Then, as you go through and identify that happy path it allows you to set up that structure- validate- this is going to work and now we can figure out how to accommodate these other ...|
|Mahtab||As you capture those things as they arise, then you can start to go back and say, "Okay, how will this work if ..." But you first want to make sure it works in the first place.|
|Mahtab||Before you start.|
|Rebecca||Yes. And that will accommodate probably 90% of your user base hopefully. If it works well 90% of the people get through it as planned and then you can accommodate that other 10% either online, or, if it makes sense in some cases you'll actually take that offline.|
|Mahtab||Let's talk a little bit about when you might take that offline.|
|Rebecca||One example that I've seen in the past is when working with Medicare plans for example. Generally Medicare plans, people are eligible when they turn 65. That's a really easy happy path to design. You can set people up online, it's very easy for a system to identify their birthdate, their Part D effective day or Part B effective date and then say, "Yep. This person is eligible."
But, there are a segment of people who are eligible for Medicare when they turn 55 years old, if they're disabled. That is a much more difficult thing to qualify online. It's more difficult to determine if their disability qualifies, what that looks like so that makes sense for companies to address offline. It makes sense to invest in having a person interact with that customer because it's just not cut and dry enough, and it doesn't make sense to invest the technical effort to create a system that would effectively qualify these potential members online when it's actually much more cost effective for them to just have a staff person contact them directly.
|Mahtab||That's such a key point, is in the process of identifying fringe cases you find ones that you absolutely could and should address as part of designing the experience, and you identify ones also that are so atypical or will be so intensive that it does not make sense to try to accommodate them within the primary aspect of the experience.|
|Mahtab||When I always think about these fringe cases another example always comes to mind is: we work with lots of clients in designing benefits administration systems and things where people are signing up annually for their benefits with their employers. So there's this whole process every year where you have to understand: What benefits is my employer offering? What are my options for health, for dental, for vision, for life? Whatever it is that you're doing— and then there's always this instance— where there's a certain segment of the population that gets hired during that time of year that they're enrolling ... The whole company is enrolling in benefits for the following year, but that individual still has anywhere from three to six months within the current plan, so suddenly they have to enroll in their benefits for the current year, and, also it's open enrollment and they have to do their benefits for the following year.
That's an example of a fringe case, where when we're designing benefits enrollment we're not doing the, "What if people are hired during the open enrollment window?" We're actually just trying to design for the majority of employees who are there, who go through this process every year, but then we need to swing back around and accommodate that additional fringe case.
All right, so we've also in the process of doing the work around the fringes cases have identified three terrible ways that we have seen fringe cases addressed and accommodated in projects and dealt with, and we thought it would also be good to talk about the “what not to do” with fringe cases.
|Mahtab||So thing number one: what have we seen? What's the first thing?|
|Rebecca||People get completely obsessed with the "what if's." They're just hunting down fringe cases like they're a truffle pig. They're really like, "Well what if?"|
|Mahtab||We sometimes jokingly call those people the fringe case fetishists.|
|Rebecca||Yes. They will focus on these weird little scenarios and they will find, "But what about the time when there's a same sex couple and they have the same name and the same date of birth?" Like the odds of that happening are so slim and yes that could be a real customer, but they won't let the project move forward because they just focus on identifying weird situations that may come up.|
|Mahtab||Yeah, so thinking about, yes, we need to think of them- yes, we need to keep track of them- yes, we need to ultimately ensure that we have included a resolution for them in the process but we do not need to become obsessed with them and not allow anything to move forward.|
|Rebecca||Right. We still have to identify the happy path, what needs to be included and how it should work.|
|Mahtab||Awesome. So, what's the second thing?|
|Rebecca||The second thing is the people who just dismiss them wholeheartedly, "That's an edge case. We don't need to deal with it." These are customers. They do matter. Yes you want to document your edge cases and swing back around to make sure that those people are accommodated somewhere.|
|Mahtab||Yep. We often find that people who fall into that category are so obsessed with getting it done, with demonstrating progress, with moving forward that they just are reticent to even consider something that is going to slow us down, make us have to consider a solution- a different solution than the one that we've thought of or designed for already.
And then last?
|Rebecca||Last is when an edge case is wielded as a weapon. I'm sure everyone has had this experience where they're in a meeting discussing a process, a system and someone brings up a topic and someone else screams, "Edge case." Maybe doesn't scream it, but definitely uses it as a means to shut down anyone bringing up something that does not match their thinking and their approach.|
|Mahtab||That's just such ... it's so transparent to us. Sort of seeing when it's being used as a weapon, and it has nothing to do with meeting the objectives of the project, or of meeting the business objectives or user objectives. It's simply an individual who wants to make their point and sort of put themselves ahead.|
|Rebecca||In all of these cases, documenting the edge case and putting it somewhere where it gets addressed later is the key to managing all of this.|
|Mahtab||Yes. Helping organizations and teams not lose them, but to appropriately contextualize and prioritize them. Yep. Awesome.
All right. Well, that's what we wanted to say about that in the 10 minutes we had today. Let us know if you have any feedback about what we shared or if you have any other questions about edge cases or any other topic you want us to discuss. Our contact information is on our website. Thank you for listening.
You can find us on SoundCloud, iTunes, Google Play, Stitcher and on cruxcollaborative.com/thecruxofit. Bye.
Want more of our Point of View?
Sign up, and you’ll be the first to know when we’ve published a new article or podcast.
Hosted by: Mahtab Rezai
Principal & CEO
With guest: Rebecca Grazzini
Senior User Experience Specialist
Rebecca has worked on user experiences in a variety of industries including online education, health care, financial services, tourism, energy, and agriculture. She has spent much of her career developing complex transactional experiences under strict regulatory constraints.
View Rebecca’s Bio