You can read the show notes and listen to the podcast here.
Michaela 0:00
Welcome back to the show. I'm here today with Dee Sadler, and you may know from CF united where she spoke many times all about design things, which Guess what, that's what I'm going to do about today. Design Thinking for ColdFusion developers. And we're going to learn 10 tips to make your apps totally amazing. And if you don't know Dee, she used to run a whole conference on design, as well as speaking at ColdFusion conferences. She's been doing UX work for 20 plus years. And from the front end visual interactive research. And she's now in charge of herding cats. I mean, now she's in charge of a whole UX team of designers who are very easy to work with.
And she is in based in now in New York City, though she did a little stint in in Boston recently. So she's currently UX director for Cox automotive, and she's also on the board of directors for UX PA, whatever. What is UX PA, Dee?
Dee Sadler 1:04
It's a UX organization national. I mean, it's an international organization.
Michaela 1:09
Oh, alright. You're the Big Cheese, then?
Dee Sadler 1:12
No, oh, no, no, no, no, I just, I'm on the board. I'm on board of directors, or the LA chapter.
Michaela 1:21
Great. So we're looking at how to use design thinking for ColdFusion developers. And maybe we ought to just start off with what the heck is design thinking, because not everyone may have come across that and and then we'll look at why CFers should be using this.
Dee Sadler 1:38
Yeah, so the definition is, basically, it basically asserts that, you know, a hands on approach to problem solving, you know, can be, you know, is human centered by, you know,
making sure that you are empathizing, you're defining your ideating, prototyping, testing, and implementing, you know, and it's just a, it's this continuous loop really, of what it is, is, you're, you're always iterating, it's never really, truly done. It's kind of fits with agile fairly well, in that we always want to empathize with our user first, and then you define what the problem is more so than, you know, thinking about the solution, you know, being first, quite often, at least where I work Currently, we, I hear the word feature all the time. Now, we're going to do put this feature in the software and for us,
for us UXers, it is about what problem are we trying to solve for the youth? You know,
do they have the right workflow? Do they
do they understand, you know, what, from what's on the page, you know, how to get things done? Are we making sure that the page is loading fast? So, for us designers, we work really hand in hand with the developers to make sure that we know, you know, is there an API that needs to be called is there, you know, a service that, you know, I'm not aware of, you know, what I'm designing. So, it's a, to me, it's a hand in hand, working with the product owner, the developers and myself or my team to make sure that we are, you know, doing all of that together, you know, we're it eating together, we're creating prototypes, you know, we're doing usability testing on a regular basis. And that, you know, we're then implementing, you know, what, that what that is? So that's the kind of the basic
they define design thinking, as, you know, it's the design is the intent behind an outcome. Does that make sense?
Michaela 4:21
Um, well, it's the way you guys the way you go about creating the user experience,
and the intention you have for the user experience in this particular app.
Dee Sadler 4:34
Yeah, it is, it's really definitely all about having empathy for the user, and thinking and writing, you know, your epics and your stories
with the user in mind. And so what's the user trained to do, instead of, I see so many stories being written about just trying to accomplish something in the software.
So I think, for me, it's total writing of stories differently as well, making sure that you've got
the user in mind. So as a sales manager, you know, I need a way to
except around instead of
the software needs a way to
Unknown 5:28
do what, whatever it is
Michaela 5:30
now, a story is like a use case, or is that a special UX work? That's a
Dee Sadler 5:34
well, no, that's a special that's a, that's a word in Agile.
So quite often, you know, we're trying to get people to think in terms of agile, where it's, you know, you're always iterating. And that way, you're, you never feel like, you know, you you're done done, you know, you may have a date that you want to get a piece of software, but that doesn't mean that you need to have 1,000% of it perfect. Before it's done. That's waterfall, right? So in Agile, we try and, you know, like, put out there, you know, that the kind of the minimum viable, you know, product, what, what can I get out there that would help them get whatever done. And then we can iterate to add, you know, more things to it
as a UX, or we try and designed the future state. So, you know, I'm looking, I'm always looking at a roadmap of, you know, three to five years, I'm in a software company where they can't think more than, you know, you know,
a quarter or two ahead. So, sometimes it is me then thinking, you know, okay, so what's the one to three year instead of the three to five year, you know, I will design
for that future state, and then we can all then iterate towards that, you know, so you are thinking about putting out, you know, smaller chunks of something, you know, towards that goal, instead of, if you don't, then you're just going to Frankenstein stuff, right?
We don't want Frankenstein products,
Michaela 7:24
what do you mean by Frankenstein products back from the dead and they've been around a long time,
Dee Sadler 7:30
I kind of think of that,
that's funny. Um,
if you don't design the future state, then you're just adding things, you know, on to what you've got with no real plan in mind. So if you don't
know, figure out what should it look like, three years from now. And then we build towards that. So we already know kind of what we want to do. And maybe sometimes the technology isn't quite there yet, to make sure that that's, you know, also available. So if I wanted to put an AI in my, in my software, or design or machine learning, it's like, maybe I've designed something that requires that, well, maybe where I'm at at the time isn't the company isn't quite, you know, ready for that. So,
so sometimes you've got a, you know, or voice enabled or, you know, whatever the heck that you know, it is that, you know, we want to try and get to, and, you know, just maybe we're not quite there yet, so, huh. Otherwise, you you have the intention of your good intentions. But sometimes, then you start adding what I hear all the time here is what we need another button to make sure that that happens.
That doesn't do anybody good. More buttons isn't, you know, a solution? Why is not adding a button the solution?
Michaela 9:10
What is the solution? Well,
Dee Sadler 9:12
the solution is what I just you know described is making sure that you are empathizing with whom it is. So what we do as designers, you know, kind of my art, our process, if you will, is we will do the research to find out in the demographics of who the actual user is, quite often companies will UX in general, is, is the idea we marry the business needs with the user needs. It's kind of what we do. And so the business says, Oh, well, you know, our users need this, this. And this will typically those users are the people that are paying for the software, not necessarily the actual users of the software.
So it's the design team, and hopefully, the developers and the product owners that go, Wait a minute, you know, that's not who's actually consuming what we're creating. Mm hmm.
Michaela 10:22
So you go out in the wild and capture one of these actual end users? So, yes, so we,
Dee Sadler 10:28
I mean, we have hundreds of different research techniques, but the most common is actual user interviews.
So we'll actually drink talk to the people talk to them.
Michaela 10:42
Isn't that dangerous?
Dee Sadler 10:45
Sometimes, yes.
Michaela 10:48
Right. They might have ideas you hadn't considered?
Dee Sadler 10:51
Well, we don't, we, the questions are key, you know, we try and ask, you know, open ended questions, we don't try and lead them to say that the software is already awesome and fantastic. And we're trying to figure out their pain points really, and, and, and what they're using, and how we can then make their workflow and what they're doing, you know, kind of, you're always trying to trying to find that transparent
interface, where they don't even know they're just doing their job. And they're making things happen, and they don't even know how they did it. Um,
that's, that's kind of what we try and always strive for. So a
Michaela 11:40
transparent input interface will be like, if you had a paintbrush, and you were doing a drawing with that, there's no interface, you just do it, and then saw where you you want something with sewing easy to intuitive, you don't have to have a manual, figure it out. Yeah, so
Dee Sadler 11:55
that's the key, right? I don't have to put somebody through hours and hours of training just to to get something done.
Michaela 12:03
So let's look at these 10 keys to doing Yeah, design thinking and see how they apply to the folks listening who are developing apps in cold fusion. Yeah,
Dee Sadler 12:16
so I think the first one is really, you know, being empathetic, the, that is the,
the number one key.
So you have to understand your, your user. And how this can can matter is when I'm designing something, or when I'm developing something, if I know how that the user would like to have it done, or what, you know, if I keep them in mind. So what I typically do for my development teams is I take the week, we end up creating personas for them. So at a persona is based on research based on data, it's based on, you know, demographics, you know, of the user, you know, we bother to, you know, go through all that pain, just so that we then all understand who we're designing for. So, it could be, you know,
Joe Jones as 54, and, you know, he makes X amount of money. And his motivations are this, and he's, you know, only he's not very tax tech savvy, and, you know, etc. So you try and find out, you know, their behaviors, their motivations, kind of, like who this person is, essentially, and we look for the 80% rule. So we're not just, you know, randomly coming up with, you know,
somebody in mind, it's always based off of, you know, the data that we can get about the actual users, you know, whether it's male or female, I try often to have, you know, if it's appropriate to have a female as maybe a secondary if the main user, you know, we talked about the 8020 rule all the time in UX, you know, so I'm always, you know, looking for that, the main flow, so who, you know, you've always got outliers on when you're creating an application, especially,
Michaela 14:28
so code of the 8020 rule. Well, how are you what exactly is 80% of what is
Dee Sadler 14:34
the way that so, like, 80% of the, of our users are male, and, you know, whatever, whatever, that, okay, that's the, you know, but we apply that in how we look at a flow as well. So, I'm looking at creating an application I'm also looking at are, so what do the majority already have people? How are they how would they use, you know, this software? So,
it's always a consideration that, you know, like it, we just call it the 8020 rule, just because it is just whoever, whatever is the majority of the time that people, you know, what, what are they going to, what are they trying to accomplish? Yeah, so, we put the personas of these people, you know, up in, and so that the developers can understand who it is that they're designing for, so they can be empathetic, you know, towards that person. So, I always asked myself the question, you know, would this person do you know, whatever it is, so, that way, you're like, Oh, well, this is, you know, this, you know, is the easiest way to do this, ABC, whatever it is, but what the user do it like that. So,
that in essence, is what really kind of doing Rives everything is trying to figure out you know, would the user actually do that we have you know, and then we'll have the research etc, to backup, you know, that hypothesis of what would they do you know, this thing, how would they like to work, you know, we're doing surveys and interviews, and no, always observing. Now, that's probably my favorite thing to do. I work at a automotive software company. So it's, our users are, our primary user is a dealer, you know,
from a dealership, so it could be a salesperson, it could be a, you know, depending on what part of our software, you know, we're looking at the time, you know, it could be a, what we call an FBI manager meets a financial person, you know,
a long because we kind of own the whole process of, you know, buying a car, one of the major software's that we have in, in the, in the country in the US, you know, so we go out and observe. So, I'm like, watching the sales,
Michaela 17:14
you literally look over their shoulders to
Dee Sadler 17:17
us. Yeah, absolutely. Yeah.
Michaela 17:20
And then see where they get confused. Or Oh, yeah,
Dee Sadler 17:25
yeah, because they get hung up. It's like, Oh, so, are they do they have multiple tabs open, you know, to get something done? Because they want to see, you know, multiple pages at the same time? Are they using somebody else's software to do a part of it? Are they going to, you know, grab, you know, some paper, are they looking at an Excel spreadsheet, you know, trying to copy and paste, you know, something, you know, like, so, we want the observation captures, that when you couldn't do that through like Google Analytics or something like that, you you couldn't actually view you know, all the different things that a person is trying to do. So, that's why observation is probably, you know, kind of the most essential when, especially if you've got a complicated piece of software that you're trying to do, you know, observing them is key, like, what else are they trained to do to get their job done? You know,
besides our software, is it you know, where else are they, you know, trying to do, you know, so,
I would say, then, it would be, you know, be contextual
is, is also, you know, really important. So, just kind of, you want the user to be aware of, you know, kind of where they're at, you know, in the, in the journey,
Unknown 18:48
it's funny,
Dee Sadler 18:50
being human right. seems obvious.
I had a, I did a design thinking workshop last week. Week for the services and APIs team.
Unknown 19:07
I'm where I were
Dee Sadler 19:10
one of the guys who is this big Russian guy,
nice, loud voice was like, why should I have empathy? Why should I care about my users? just it's just a developer, I'm like, really?
Why should you care they are then going to consume your service or API, right you have somebody who's still going to use whatever that is, you know, even if it's another developer
you know so it was it was kind of funny we finally were able to you know, kind of talking you know, talking down off the ledge of know why should I care about who my user is I'm like well you know they're trying to you know, consume it and put it in you know an interface so it's still like they're not dealing with an interface of any kind but their user is yeah so again
Michaela 20:14
at the end of the day you want the users to trust your software
Dee Sadler 20:17
absolutely absolutely yeah so that's that's the you know kind of be discoverable
Michaela 20:28
right it's in the fourth point in the yeah be you know
Dee Sadler 20:35
no one wants to you know look you know deep for something I think that's the kind of the main point is like don't hide something don't make somebody look for the Back button right no make somebody figure out in a the the the true call to action on the page don't put so many buttons on the page that look all the same that they can't feel you're out you know what they're trying to do
even designers though I this is a problem that I have with designers as well is I used to work for h&r block. And
we worked with a an outside design firm.
And I couldn't believe that I had to actually tell them, it's like, okay, just because our logo is green does not mean that everything on the page needs to be green.
And they had they designed an everything was Green Man. So I mean, the, all the links were green, and all those graphics were had green tint to them. And, you know, green this and agreeing that and so then by the when you were looking at the page you can use couldn't figure out what the true you know, call to action was on the page, what do you you really want them to do.
And so make sure that that is really obvious for them. So if if you're
a alone developer, without a design team, in a company,
these are the things that again, I mean, it's not, you know, it's not always intuitive, you know, two designers either, I can't believe the number of times I've had to remind people that, you know, make things discoverable know, the, the fifth one is the intuitive part,
I think that's easier said than done. So this is also where, you know, trying to find a designer or work with a work with your, you know, UX team makes all the difference in the world. Because you can say that you want something to be easy and intuitive. And that's a phrase that will make any UX designer kind of cringe,
because you hear it all the time. It's like, it's kind of like, Oh, well, you know, can you make that sexier? Shouldn't that be a sexy application? Like, what do you even mean by that it's one of those words that people say, but, you know, just like design, design means something different to every single person, you put 20 people in a room and the, say the word design, and it's going to mean something different to every single, you know, person, the developers think of design in a totally different way that the designers think of design. So you have to be careful with those words, I try. And every time I started a new project, I tried, the very first thing I do is come up with a terminology sheet, make sure that we all can agree on the on the terminology that we're talking about. So that if I say design, it always is going to then mean this, if I say
try to think of a, you know, another, you know, developers have their own lingo, you know, as well. So, I think that's certainly why I had my,
that's why I created that conference that I had designer developer workflow conference was all about how to communicate between designers and developers and, you know, understanding each other because I think that's, you know, kind of key as well, you know, have empathy, you know, for your, you know, fellow work people, you know, understand, you know, what business is trying to do, I had my designers recently being we have a lunch and learns with the product owners on what, you know, what business needs so that we understand what business we have empathy towards, in the business side of things, what the product owners, you know, are trying to do, you know, we'll do the same thing with the, with the developers trying to make sure that we understand, you know, their needs, and quite often, you know, I mean, we have a whole huge teams, you know, we have these, we call them caves of developers,
Michaela 25:27
caves. Yeah, hope that very well decorated capes
Dee Sadler 25:31
they are, they're very well decorated. The developers have really developed it, and they've done a great job. Each one has their own name, like the transformers and
district 13, and they have all these, you know, fun, fun, cool name. Sounds a
Michaela 25:52
little dystopian district seen games, right? Was it?
Dee Sadler 25:57
Oh, yeah, it's true. Um, and then, like, the usual suspects, and
Mark Drew 26:03
I don't think I'm going to go into that cave might be dangerous.
Dee Sadler 26:07
That one especially, right, yeah, yeah. Um, so then the, just kind of be clear, the, the sixth one, then, is be clear and concise. Make sure that you show that you understand the user's needs. And, and, you know,
just get to the point, you know, don't put a bunch of extra, you know, kind of stuff, you know, on the page that you don't really need, you know, I come from the, the last couple of years, I've been in the healthcare software business where they try and put every little single thing
on the page, you know, especially the ones that were, you know, I'm, and I'm using air quotes designed by the, like, one person who they like, Oh, I found this radiologist, you know, and he's, he helped me just, you know, design this thing. And it's got every button imaginable, you know, on it, and no rhyme or reason, it's like, but that's what the user wanted. Well, that's what one user wanted, you know, that's not all, that's not a, you know, a good sample set of all of the users that use, you know, the software they we try in, even though doctors especially want everything on the page, they are trying to accomplish one particular thing. So, you know,
you want to give them focus, you know, to that thing. So, that's why, you know, being clear and concise is important. Yeah, to, like, find out, you know, and do that deep dive into what they that user actually is trying to accomplish at that time, particular time, and give that the focus instead of just giving them everything that could ever absolutely no need to have on the page,
Michaela 28:12
right? Because you follow me the 8020 rule, either. Oh, yeah, make 80% of the tasks real quick and easy. The ones that they do the most? Yeah,
Dee Sadler 28:21
well, you should see some of the software, it was crazy before, you know, they got up, we got a hold of it was
just every, like a rainbow of buttons, you know, they had the different buttons in different colors.
Unknown 28:40
So they could,
Dee Sadler 28:42
but they were all buttons on the pain, it was quite, it was quite crazy.
So seven is be learn double thick, that's fairly intuitive to, you know, kind of, you know, figure out, yeah, you
Michaela 28:55
want them to be able to just learn it easily, they don't have to go through training to use the software, which may mean that software me needs to be simpler.
Dee Sadler 29:06
Well, I mean, I think that kind of goes with the really just the next three in general, which is, you know, the be efficient, be delightful, be better. But I want to go back to the delightful part, just because designers quite often use crazy words like that. But really, what it means is giving the, the user and making them happy to, you know, to use what they have, you know, sometimes, like the software that I'm using right now, or that we're creating right now, I'm not using it, but our what we're what we're trying to accomplish, these people are just trying to, I mean, the bottom line is for them to make money, the bottom line is to sell somebody a car, the bottom line is, you know, to be able to make that sale quickly. And, you know, move on to the next one, you know, so the delightful part is, then, you know, is the page loads fast, and, you know, they're able to accomplish their task in a in a very short amount of time, you know, in design thinking, one of the things that IBM came up with is, is pretty interesting. So they came up with the idea, I mean, design thinking, in general, you can look it up,
Don Norman is kind of the godfather of UX, and the godfather of design thinking.
But IBM put a weird little twist on to the whole topic of design thinking, which was to find sponsor users.
And I love that idea. It's, it's really helpful for us as well. And what that basically means is, you know, you find a group of, of your users, hopefully, a good sample set, you know, of the types of users and not just one type of the user,
and they are then willing for you to be able to test often. So,
like, for instance, as I'm working, we could come up with, you know, some initial, like, paper prototypes that we could put in front of them really fast thing, like, in the concept of, you know, do they get it, you know, do they get, you know,
how to, you know, to do something, and then the developers can help create this thing, you know, as a prototype, not, you know, it's, to me, it's throwaway code, right? It's not necessarily real, because there's going to be iterations, you know, done to it. So, then we put another, you know,
as we as we go along a little ways, then we put another usability test together, and maybe we can they accomplish this task. Yeah. So, then you can, you know, use this group of people to get in front of on a regular basis, and it doesn't negate the idea of doing, you know, some final usability testing, and then make iterations from that. But hopefully, it's a group of people, a group of users that you can get in front of, you know, quickly and often so that you can then feel much better about, you know, creating the final, the final application and you're like, Oh, no, I think we've, you know, I think we've made enough iterations now that we finally got it, and, you know, now we can just make the crazy thing, and then we can always make, you know, some changes later. But hopefully, you don't have to make a lot of really major changes, you know, because you've already, you know, at least put, you know, stuff in front of users, and they get it or not, so, I think that's the, you know, delay part of that they also came up with something called hills. So, it's basically the concept of, it's a military, you know, kind of term of storming a hill. So,
what it kind of it what it is, it's, it's a huge, it's boo, what, and, wow, so the, the,
who is your user, you know, the, what is what they're trying to accomplish, and the Wow, is measurable and time bound, so that you can, you know, create that, you know, how do we measure success, you know, as I work with my designers, I'm always pushing them to do the reviews with the stakeholders in the terms of
what was the problem that you were trying to solve, you know, here, and then here's how we solved it. And then the third thing, which is always the most important, and when I'm looking at portfolios, as well as, like, then how did you measure success, you know,
what was that measurement that made it successful. So, the Wow, is, you know, helps you then, you know, kind of figure that out. And then, and then I can create epics and stories, you know, from that. So, I can say, like, a
example might be as a sales manager, I need a way
Unknown 34:34
to
Unknown 34:37
have my customer
Dee Sadler 34:40
fill out their, you know, their personal information, so that
I don't have to do it manually, and maybe get something wrong, and it takes less time. So, I mean, I would probably, you know, and then and in in a, you know, in five minutes or less, you know, so trying to you, we try and make that, you know, so the Wow, is it takes less time. And in five minutes or less, it's more accurate than if the, if they had tried to, you know, type it themselves, you know, quite often the sales manager, for instance, or, you know, they're take somebody's ID, and then they're trying to type in all the information when, you know, it's way faster, right? If you did your own, you know, you would, you would spell your name, right. And you would put in your address, right, rather than somebody else, you know, trying to do so, it's just an example. You know,
Michaela 35:39
how that might work out better. Great. Well, thanks for sharing those 10 tips with us. It sounds like this far more to it than just the UI, the whole UX thing is something quite bigger. It is it is it but again, all goes back to just making sure you have empathy with your with you're using. Um, so let's just pivot to a couple of closing questions. d. First of all, I know you're a UX director, and you've got all these UX designers working for you. Right? Why are you proud to be UX director?
Dee Sadler 36:18
Well, you know, I think, you know, you mentioned it to begin with that I was a speaker at CF united, I loved doing that. I love
making sure that everybody works well together. I feel like I'm the cruise director on a on a on a ship
Unknown 36:43
where
Dee Sadler 36:45
I pull everyone together a myki is communication and getting the developers and the product owners business and the developers all communicating well together.
Unknown 37:02
And I love doing that.
Michaela 37:05
That sounds great. So as you probably know, I'm on a mission to make cold fusion more alive. Because sometimes you hear these rumors that cold fusion is dying, which is kind of ridiculous. I'm writing a book all about that.
So why for you? What, what would it take to make cold fusion more alive this year?
Dee Sadler 37:29
That's a great question. I think getting I was kind of, I feel like beside yourself, and maybe just a small handful, we've kind of lost that voice of how using cold fusion can make your life easier, rather than Java or, you know, some other, you know, nonsense. And companies don't seem to understand, you know, the boy, they could have a whole crew of really amazing, passionate, that's the thing for, for me with cold fusion. And why I love speaking at your conference was the cold fusion developers are a passionate bunch and really seem to love what they do. And I know when I went into the, you know, the rest of the world and I started working with other types of developers. I mean, they're boring bunch, man. Yeah, like,
they don't, they don't have passion. I didn't hear anybody talking about, you know, like, wow, I, you know, I saw this cold fusion podcast where I saw that they weren't self educating the way cold fusion developers and educate themselves. And I think it's a shame that we don't see, you know, more of that. And, you know,
I think that would make a big difference, you know, kind of, like, word of mouth to influence companies, you know, to, to use it. Hmm. Well, it's a great tool. So, if people want to find you online, one of the best ways to do that, so I'm on Twitter always have been, so it's just, you know, D sad le are, you know, at at D. Sadler, I have a website. It's a box of pixels.com
from when I used to train as well. So
that's pretty I'm pretty easy to find. Great.
Michaela 39:51
Well, I really appreciate you coming on the podcast and have fun in New York with all these caves full of developers.
Dee Sadler 40:00
Thanks for having me.
