Nicole Kelley 0:09
Welcome to user centered by design a podcast where we talk about all things related to user centered design. Today we're going to be talking a little bit about what we talked about last time, you guys had listened into us, we're going to be recapping. But today we have myself, Nicole Kelly, UX UI designer.
Kelly Catale 0:29
And I'm Kelly Catale, Program Manager.
Alex Therrien 0:32
And I'm Alex Therrien, Director of user centered design.
Nicole Kelley 0:36
also pay attention to the new title, our Kelly kitale has garnished. Welcome to your new role.
Kelly Catale 0:43
Thank you very much. New ish, I suppose spend a few months.
Nicole Kelley 0:49
It has busy busy we've all been and especially you. So Alex, last time, we had spoken, we had talked about Jesse James garrett's layers of user experience. And the first two layers, which were strategy and then scope, we talked about a lot how they integrate within the beginning stages of creating an app and just how important they are. And do you want to briefly recap a little bit of what we talked about last time?
Alex Therrien 1:11
Absolutely. So you'll find in the show notes, there's a link to Jesse James garretts. It's the second chapter of his book, The elements of user experience. And in there, there is this framework that we referenced in the last episode, and we'll continue referencing In this episode, which is the five layers of user experience. And we did talk about strategy and scope and their foundational effect and their their level of impact on how you are can be successful in developing an app. This week, we're going to be talking about structure, skeleton and surface which are the more concrete layers of the user experience. And we're really, really where you start to see the manifestation of a design, especially in this case, and AP come together. So when we talk about strategy and scope, strategy, to recap, is the reason why a product might exist, it is how you are going to be competitive in the marketplace. And it's how, why you are a tool that a user may bring into their life. And the scope layer is defined by strategy. So the features that will be part of the product, the roadmap of where it hopes to grow in the future. And it defines what the MVP is, in a lot of cases. And for the for the purposes of our discussion today. It's an app. And once we understand what scope is going to be relevant to launching the product, that's really where these more concrete layers come into play with structure, skeleton and surface.
Unknown Speaker 2:47
Actually, I actually want to chime in here because I think, with this structure, well, I shouldn't use the terminology that we're using for explaining it. But I feel like with this conversation, or framework, Reek, kind of wanted to take a top down approach, which is higher up to lower because a lot of what we see at this level is the surface layer. without some people knowing those other two layers below it, you know, we did go bottom up was strategy and scope in this time, it kind of makes a little bit of sense going from surface to skeleton structure, though, that's not how you would normally work them through a project because it's more relatable, I feel like to listeners where they can hear
Alex Therrien 3:31
and understand,
Unknown Speaker 3:32
hear and understand the knowledge behind why these things are on this surface layer, what causes those decisions, because it is so fundamental to the rest of the layers that we go through. Whereas some people may not understand fully at it at a glimpse, so we can talk from the top down. Let's go.
Kelly Catale 3:50
Okay, I like that much. Well, I think that strategy and scope are a foundational, as you talked about the last episode. And they're abstract enough that you can speak to them on almost in their own levels. Obviously, strategy is the most foundational and then scope builds on top of strategy, and they interact with themselves in different ways. And then when you think of the remaining three layers that are set above those three, they are, as you mentioned, Alex concrete enough that we could start at the top and start to peel them away like onion layers. I think of Shrek the movie Shrek, like an onion, sort of peel them away as you understand them a little bit more to reveal what the motivation is below them. And that abstractness gets a little stronger, the deeper you get into the onion. And so if we can start with something that's more relatable and easier to conceptualize, it will help tell the story a bit better. So I do you like that?
Alex Therrien 4:48
Absolutely. And as the team member here today, who has the the role of project manager you in our world Are the substitute for the product owner. So yeah, it matters that you're bought in on this. So if we're doing any project, the product owner is going to be on board with how we're structuring it. So
Kelly Catale 5:09
that's very kind of you.
Alex Therrien 5:11
So that said, let's, let's dive into a little bit of a, you know, let's, let's unpack what what these other three layers are. So the easiest to understand is the service layer. So as we think about any digital product, and what your experience with it is, the most tangible elements of that are in the service layer. Let's use an app for example, because that's why we're here. That's what the the episode is labeled surface layer is going to be things like the color choices, the branding, the typography, the iconography, it is the the visual design of the product. And a lot of people look at the design in that layer, they believe that is everything. But below that, we actually have the skeleton layer. And that's really, that's where the layout does come more into play. And we do see still some of that in the visual design and the surface layer. But really the the architecture of each individual screen is taking place in the skeleton layer. And it's you know, how we're blocking out the, the screen individually, the the choice of functional buttons, the arrangement of content, the the type of content that might be in there, that's all decided at the skeleton level. And then below that is the structure. And usually when we think about that, it's it's architectural, the navigational architecture, the information architecture, the hierarchies that exists there. As we think about this, and their connection to scope, and to the strategy layers, there's a series of logical connections that take place across those layers, that when we think about when a product makes sense, and when we think about the usability issues that may come up, some of the user dissatisfaction that may come up in the inner product is really where we start to see, you know, broken connections between these layers. And across these layers,
Nicole Kelley 7:14
I definitely want to include when people look at an application, or an app, or even an interface in an embedded software system, people tend to look at the surface layer a lot, right, because it's what the person sees, it's what the user interacts with the most. It's what we create, and bring at the last layer of final product development. You know, that's what gets out into the users world. And I think a lot of times, oftentimes, people who aren't involved in the process that goes on below, tends to not realize that there's always a purpose. And there's always a reasoning behind every visual aspect, every UI element, every text or font choice, tends to be sometimes overshadowed by the fact that a good design or a good app design, it'll just work. And it just meshes well with the whole experience, because it has been brought up to that level of the foundational steps of the other four below it that cause a really, really strong foundation for these UI elements to kind of sit upon.
Kelly Catale 8:14
And I think one one word you use there that is key to highlight is good UI. So you mentioned that in a good user interface, it may be good isn't the right word here, but in a in a high quality user interface. That is the truth that every piece of the UI should be strategic in a way and should have a purpose and serve a need for the user or for the system in some way. And is not just placed there because it looks nice. And we there can be pitfalls with designs that don't think through every element. And that's why this framework works. That's why this framework exists that Jesse James Garrett has created because it helps tell that story. And it helps you work through those decisions to get you to the surface layer. And it's why the surface layer does not exist in its own little bubble.
Alex Therrien 9:10
Yeah. And when done well, it results in usability and utility. And I like what you said there, Kelly about design shouldn't exist just for design sake. When we're doing a great product, it needs to be fit and trim. And it needs to be focused on what its purpose is. And when you put things that are outside of that purpose. It leads to confusion and distraction and a lack of clear purpose. And great tools oftentimes have a great purpose. Even if they're well rounded and have broad utility. They have focus and each if there's more than one point of focus, each one needs to stand out and be clear in his communication to the end user. Otherwise we lose them and it's no longer As the tool no longer has a place of utility in the life of a user.
Nicole Kelley 10:05
Yes, I think there's a lot of risk that can happen at these three stages. If, as we talked about before, that our strategy and scope aren't well defined, this is the part where if you're not making sure that you're overlapping slightly before you close them out, you know, you're making sure that you're double checking, because this, like I said before, is one of the most tricky parts. If you start veering off course, it's a lot harder to go back and kind of make those adjustments Little by little, if you haven't, if you don't have those connections, or those relationships, or those definitions at that surface level, to your lower requirements, you know, all of the lower features that you had already discussed that kind of build out your scope, it can take a lot of time to go in and dig those out and kind of reroute all your error paths that may occur that you weren't foreseeing, you know, you may set up an entire flow that the user may never interact with, if you didn't have the right,
Alex Therrien 11:04
the right connection to the end users need
Nicole Kelley 11:06
Yes, if you didn't have the right user need that can definitely throw off course, your whole top three layers, because structure won't be able to be there. If you didn't define your strategy well enough, you'll be designing for the wrong purpose. And I think that can cause a lot of pitfalls later on during the development process. And it's a lot harder to get out of that. So tying these two episodes together, our last episode and this one, really do build off of each other and can create a great output.
Kelly Catale 11:34
This creates a framework that multiple stakeholders can use to communicate their needs and communicate their objectives. So you have marketing who has a clear objective and needs to discuss the scope and insert into strategy, right. So in that would pull in some of the technical folks to be able to talk about scope and features. And then when you're talking to designers, they need to be able to communicate with engineers, the software developers, for example, when we're talking about an app to help, really defined structure and what's possible and feasibility, there's, there's all of these layers together tie in, I would say almost every single role that you would have a multidisciplinary team. And that allows for much more code, much more coherent communication and project in general, now that I'm in the pm world, I can see how a framework like this would be really valuable because you're you can get buy in and you can see the dependencies between the different decisions that need to be made and are continuously made as you're developing a design. And the further down you get before thinking about how one decision impacts a different layer, the the more costly it is to change it. Later in the project.
Alex Therrien 12:53
Let's let's talk a little bit about the connection across the layers, we've touched a little bit on how they are relevant to one another. But let's let's talk a little bit more tactically about how how good connection can happen, moving from bottom up. So we've already talked about top down to kind of help ground everybody in in what each of the last three layers is for. But if we're coming up from strategy through scope, and now we're at the point of we understand where we are defining the boundaries of the product, and when we when we start to bring in, what's the architecture of the product? Where's the focus of the app? What's the navigational structure in the information architecture, you have to reflect the priorities of the strategy and you have to reflect the priorities of the scope in in that layer. First and foremost, you know, if this is a, if this is a product, for example, a diabetes, you know, an insulin pump monitoring app. So I need to see that my pump is running, I need to see that what's the rate that it's delivering all these things from the scope that we know that are critical to knowing that this is the system is operating and performing well and replacing, you know that that system in my body, we can anticipate that that may need to be part of the homescreen experience where I can look at a glance and know how my product is doing. Now depending on the particular strategy, we have to meet the user's needs, there may be different implementations of that, which then pass through into the structure or the skeleton layer where we start looking at Okay, what are the controls and features that are on the individual screen? What are the components that exists there? What What is the content that may exist there. And once we understand and reflect how that strategy pulls through the information architecture and the navigational architecture and puts features onto our home screen that we feel like For important, and we have a kind of implementation on them based on how we are trying to contrast with the competition, how we're trying to contrast with what we believe isn't being met in the current marketplace, we can start honing that in the surface layer with the colors, the typography, the illustration style, to speak to the personality of the app, to speak to the personality that we're trying to have reflect through from our strategy. And in the end, we have this connective tissue all the way through this chain through all those layers. And a decision at each layer limits our ability to reach certain functionality and the next layer up. So if we decide that, you know, we are, we want to be a, you know, a low attention requiring insulin pump controller? Well, you know, what do we need that that homescreen Actually, this is a bad example, I want to back away from that, because that's like a class three, that's, that's going to end up training.
Kelly Catale 16:15
For example, if you, you made a decision in your your structure layer, for example, that you wanted a really, really simple screen, that was your main screen that the user interacted with. So have very minimal functionality, because you want it to be minimally distractive and have not overloaded, overloaded with information to the user. That then means you have if you have a bunch of options, or other things settings, you have to define, you're going to have to be locked into certain options of where to put all those, right. And then you might that might mean you have to pick, you have a menu, you have to have this giant menu that is maybe unwieldy. Or it might mean that you're restricted in what you can show for messaging on the screen. So you've once you've picked a certain pathway, in one layer it to your point, Alex would stop you potentially, from certain options in the next layer up, essentially. And I don't know if that's a good example. But I'm trying to think of like, what things that I've seen in the past that have prevented design decisions later down the line. And
Alex Therrien 17:29
I think we talked a little bit about this in the last episode too. And there there is a good example from from work that I've done in the past where there was a therapy app, it was a therapy calculation app and you know, therapy delivery app. And, you know, the the desire from a user needs standpoint was to not live in their health condition. And for for chronic conditions. That's something that we hear a lot about, where motivation lives, where where resiliency lives for dealing with the demands on you know, your health management, it's getting a break from that is really important for maintaining, you know, mate, motivation and sort of behavior change elements as part of your health management. And where we had a big disconnect in the team was one side of the team was was highly focused on the delivery of that therapy information and getting somebody in and out and on their way, because that's their, that was the strategy that we all agreed with. And there were other members of the team who had a belief that there was a high value to education as a feature in the product where they believe that there was there was high value in sort of teaching people about their health, teaching them about how to manage their health. And they wanted almost this entire course curriculum that your your healthcare provider could assigned to you, grade you on your progress, evaluate your your your capabilities, and continue with this education portion, which on its own is a great product strategy, but it wasn't aligned with the strategy of our product. And where we ended up in a rough spot was trying to serve as both strategies within an architecture and within a skeleton. And within a surface layer that didn't support both of those products, as one each of them was was honestly its own. quite valuable. And yeah, you know, demanding product for what would fit into an app.
Nicole Kelley 19:34
You're giving too many options, too many core messages on one screen. It's like somebody's yelling stop and somebody yelling go on the same screen and you're like, which What do I do? What do I do? I think that tends to happen. You try to fill something with too many ideas, as in your case, at that bottom layer, two different strategies which are competing against each other, that can cause a lack of attention from the user that's trying to actually have a benefit from using This application or this method, or this device,
Alex Therrien 20:03
and increase friction in the navigation of like, Okay, I have to manage my health. You know, let me use the, the metaphor for, we're going to a GPS app, where it's telling us how to get from from point A to point B, if it's certain slowly starts trying to quiz you in French, you're gonna have some trouble navigating to where you're getting to, and you're gonna be really frustrated as a user, because you're like, well, I don't understand why the navigation app is really inserting a lot of choices in my my, as few steps as possible to get to understand where I need to go for two o'clock today, because I got a meeting. And I've got like four options on picking my next French class, like what's going on here, and I don't know what to do next. I'm out, I'm not doing this product anymore.
Kelly Catale 20:50
One of the pitfalls can be that you want to have a really flexible product, and you want to accommodate multiple user needs to your point, Nichol they might be directly conflicting, the more flexibility you allow, and the more options you allow for your design. And the product in general, usually makes it more complex. And I know I've worked on products where we've had requirements from marketing that says, oh, the user needs to be able to do X. And there's a certain condition that needs to be met to be able to meet to do this workflow. And it turns out that maybe they need to their to be able to meet that condition, they could have one of five different ways that they could meet it. And we have to accommodate every single five of those workflows. And then it becomes where do we put all those options? Where do you how do you accommodate every single one of them, and to please everyone can often mean that no one gets a nice workflow, no one gets a good experience, because everyone has to be satisfied. And that's where, again, this ties back into the strategy. And the scope is where where do we draw the line so that the design doesn't have to compensate for potentially unclear objectives at the beginning, and the foundation of the product? definition?
Alex Therrien 22:11
I can't second that enough. And I think a great product serves a great editorial perspective on why it exists. And without a strong editor. And usually that's it, the more editor's you have the less strong view you have, I am a big advocate for a good decider in the mix, you know, and many cooks in the kitchen. Exactly. Say that good old analogy. Yep. And it's fine to have a board that you discuss with but somebody's got to make the cuts at the end of the day. And yeah, I can't second what you said, Enough.
Kelly Catale 22:48
We've been using when we were preparing for this discussion, the phrase intentional design, and I think we're really hitting on it now is, we want to be intentional about every decision that's made. And it's not design is not hopefully, listeners of our podcast can now understand that design is not just the surface layer, that it is all five of these layers together. And each one of these layers has intentional decisions that need to be made together form the intentional design of a product. And we've talked a little bit about a few examples and whatnot. But this is really the underlying principle that we're getting at.
Alex Therrien 23:29
Absolutely. And, you know, we are believers in that that term intentional design, and we've started to push that more and more with our clients. And it really does reflect this logical chain through each of the layers and how each one is reinforcing the learnings and validating them, honestly, by trying to build it, does it work trying it out with users? Does it work? Does it make sense. And then, you know, a lot of times it's in the execution to there's these ideas of consistency and the consistent logic string through the product, as well as the consistent application of that logic. And as we look at those, you know, there's everything from the tactical, to the strategic, and I think we've been talking quite a bit about the strategic with how it promotes certain features. And, you know,
Nicole Kelley 24:19
I like similar to you mentioning, you know, making sure that your client understands also making sure that your fellow employees and teammates also understand that making intentional decisions with your designs, because even if it may seem like it's just a simple dashboard, or if it's just a simple data logger, making sure that even if a UI UX designer isn't involved in that process or wasn't on that team, having your engineers be conscious of those decisions and making sure there's a reason for them. Because I think even at that level, you can insert a little bit of user centered design in there, you can make sure that you're being conscious of the decisions you're making, so that if you want to make something a certain color, you're not Just throwing a random color, you're really thinking critically about these decisions, because at the end, it does affect the person using it, even though it may not seem like it is at the moment of the decision, you really need to peel back those layers of the onion, as we mentioned earlier, and, and dig deep into why. So going back to intentional design, making sure there's just a overall balance between all the things that you are thinking about,
Alex Therrien 25:24
and how we can help people take this tomorrow and make use of it. If you're not a user experience focused, or design focused individual, but you're interested in these principles. There's a few different ways that you can act on this, you know, from a tactical standpoint, there's internal consistency, you know, if you look at the upper three layers of the stack, you know, are your buttons, buttons, you know, or do they if you use one design for a button in one area of your product, is that the way a primary call to action button appears throughout your product, it's little things like that you could be surprised by is the the navigational patterns, the interaction design patterns and patterns, meaning you can walk through a flow, or you can get, you know, a piece of motion built into your product, things that lead a user through it, are they consistent between features, if you're if you have an expanding menu is that the the way all your menus work? Is there a logic for why they don't all operate that way, you need to be intentional about it. And then you need to find the internal consistency and logic within your product. But also think about external consistency. How you're looking at the way users are learning from other products around them, that are like your product, and reflecting similar user interface conventions. You know, it's important to think about intellectual property and what you can do that's unique and novel to your product. But at the same time, doing something wacky, that's brand new, just for the sake of being wacky and brand new, you can end up you know, causing your users to train wreck in the same exists at the strategy level, you know, if we're keeping our most prominent features, you know, first and foremost, you know that that starts to reflect our strategic logic. And, you know, growing beyond, you know, the the logic while executing the product, you want to keep yourself consistent with where you started. And acknowledging that your strategy has changed, if you start doing something in the navigational layer or with with feature creep, that, you know, takes you in a new direction,
Kelly Catale 27:40
I want to add something absolutely what you were just saying about external consistency. So being someone who's worked in risk management type realm for years, there is something to be said about consistency and the benefit, but also the potential drawback of being consistent with something. And this is something to keep in mind when you're developing an app, especially because in the medical realm, medical, and we should always emphasize this as in medical, we are risk driven. So everything we do needs to consider potential harm to the patient, or potential harm to the clinician or whoever it is that you're using the end product or being impacted by the end product. Sometimes being consistent with commercial apps, because that is what people know. And when you talk about, oh, we're developing an app, I use this app every day. It turns out that app I use every day is this harmless watch step fitness tracker that if it was wrong, it doesn't actually matter. And if I get if I have an error on it, then and I misinterpret the message or something, there is relatively minimal harm to me. Now, if we try to mirror those interactions and mirror the same expectations within a medical device related app, we could potentially present some level of harm to the end user. So there are times when it calls for having something that diverges away from commercial app, commercial expectations. And that's where we go back to intentional design. Sometimes we exactly. Sometimes we have to decide that. Yes, everyone knows the way that an iPhone works and the way that a different commercial products might work. And there might be a strong desire to mimic that because we know that it works and we know that it's easy, but there might be inherent harm when it comes to the medical application. And I'm trying to think of a good example where this might be the case but I can speak more generally saying that there are times when we have to go against the way that commercial expectations exist because we are dealing with medical products, and it's not to say that commercial isn't valuable, and that the way things are done there aren't clean and smooth and effective. But there are times when we have to consciously decide that Yeah, the risk associated with a certain action or a certain workflow or certain screen mandates that we have something in place that might be slightly more cumbersome, or might might appear to be less flashy than what you might see in a commercial application.
Alex Therrien 30:28
And, or, or simplified in terms of its user experience, you know, a good example that I can think of is the natural tension between user experience and security. So let's go back to our insulin pump design. And, you know, if, if I'm looking for some of the more novel ways of it just connects that you see in bluetooth headphones, you know, they're they're a low risk product, if somebody gets a hold of your Bluetooth headphone signal, there's, there's, you know, you might be embarrassed because somebody could listen in on your, your cell phone call at worst. But, you know, if somebody maliciously gets ahold of the the ability to access your insulin pump, suddenly they're driving your pancreas, there's sort of a different outcome associated with that and is an insulin dependent population there is is suddenly in a really bad way is it's I get teased about that metaphor of people driving, oh,
Kelly Catale 31:24
I just heard I, you know, driving your pancreas a little sterile.
Alex Therrien 31:30
A little person at the wheel of a of a, of a blob of pink.
Kelly Catale 31:34
Yes, but it's but it is no joke, right? Because the ease of which my headphones currently, when I go out for a run my headphones pair with my phone within seconds. And if for some reason it accidentally pairs is my husband's phone, and I listened to his podcast that he's listening to that's harmless, right. But if it to your point, someone connects into my insulin pump or something else that might connect, it could lead to serious harm. And that is, it's really true and valid consideration when you're talking about medical products that are wet, or trying to come close to commercial product experiences.
Alex Therrien 32:15
Absolutely. And as much as possible, we certainly acknowledge that there are pain points with that, that we have to trade off against. So sometimes it even can require you to over perform in other areas. So if you're having to trade this, so we're giving you security on connecting to your imaginary pump, well, maybe there's other areas where you have to give back now you invested once, now that you've sunk that capital into connecting the device now we we make sure that that's ironclad never gets disrupted. And it always works. Or there's other areas where we make every other experience with entry of information through your app or your phone. Once you've connected it, it all just comes in easily. You never have to touch it. Again, there are other trade offs that we can still Aspire and take that burden off of the users. Because we all know that to make a patient's life better, which is our mission is to you can't just say, well, it's a medical device. And it's okay, we certainly aren't advocating that we want the best for the patients because that will move the needle on their health indeed, fantastic.
That covers our discussion today, on the final three layers of the Jesse James Garrett, layers of user experience framework, we think that they are really powerful tools that all five layers working together and the logic structure that can happen across it. They're a powerful tool to help you build the most powerful experience and useful tools that you can imagine, and still relate them to the user and be successful in business. That was really, really roundabout. Let me try that again. So in summary, the Jesse James skerrit, five layers of user experience and their logical connection across those, it's a powerful framework for making sure that your app is relevant to your end users, and is a clear tool that will fit into their lives, we find it to be a very useful framework and method for reflecting on how we're building successful tools in our work every day. And I personally find it a good touch point at each milestone to be checking backwards on how we're succeeding against our original vision, and how our vision may need to change.
Kelly Catale 38:01
I fully agree with everything that you just said, is a good wrap up. But I love this framework, because it gives us an opportunity for all of the voices in a multidisciplinary team to express their needs. And like you said, the coherence across all five layers helps drive a really clean and effective design, intentional design, as I'll use the phrase, again, that addresses some of the complexities and potentially the simplicity of a potential design.
Nicole Kelley 38:31
I just want to mention that if you haven't already listened to the previous episode that talks highly, are talks more in depth about the strategy and scope layer, definitely go take a listen to that. And then it'll give you a bit more understanding of where we got to the three sections we talked about today. And it'll give you a really well understanding, like Alex and Kelly had mentioned about the foundations of really creating a good experience for your user, of your product of your device of your anything, honestly, this can be used multidisciplinary.
Alex Therrien 39:05
As a final note, I like the point about making the critique of design, very accessible to the broad parts of the team through using this framework, because it gives a non opinion based way of making sure that we're all heading in the right direction and in the right way, without being, you know, driven by personal aesthetic taste. It's it's driven by logic. And I don't think that that can be overstated enough, you know, having that inroad in that that way of building trust, and that may be a later episode about good critique and good frameworks for collaborating with design going forward. But I can't under I can't overstate that enough.
Nicole Kelley 39:48
Yeah. Well, thank you. I would say everyone that's listening today and listen to our previous episodes, we really appreciate all the listens and downloads and whatnot.
Alex Therrien 39:57
So definitely reach out and let us know if there's any ideas Is that you have about new topics.
Welcome to user centered by design a podcast where we talk about all things related to user centered design. Today we're going to be talking a little bit about what we talked about last time, you guys had listened into us, we're going to be recapping. But today we have myself, Nicole Kelly, UX UI designer.
Kelly Catale 0:29
And I'm Kelly Catale, Program Manager.
Alex Therrien 0:32
And I'm Alex Therrien, Director of user centered design.
Nicole Kelley 0:36
also pay attention to the new title, our Kelly kitale has garnished. Welcome to your new role.
Kelly Catale 0:43
Thank you very much. New ish, I suppose spend a few months.
Nicole Kelley 0:49
It has busy busy we've all been and especially you. So Alex, last time, we had spoken, we had talked about Jesse James garrett's layers of user experience. And the first two layers, which were strategy and then scope, we talked about a lot how they integrate within the beginning stages of creating an app and just how important they are. And do you want to briefly recap a little bit of what we talked about last time?
Alex Therrien 1:11
Absolutely. So you'll find in the show notes, there's a link to Jesse James garretts. It's the second chapter of his book, The elements of user experience. And in there, there is this framework that we referenced in the last episode, and we'll continue referencing In this episode, which is the five layers of user experience. And we did talk about strategy and scope and their foundational effect and their their level of impact on how you are can be successful in developing an app. This week, we're going to be talking about structure, skeleton and surface which are the more concrete layers of the user experience. And we're really, really where you start to see the manifestation of a design, especially in this case, and AP come together. So when we talk about strategy and scope, strategy, to recap, is the reason why a product might exist, it is how you are going to be competitive in the marketplace. And it's how, why you are a tool that a user may bring into their life. And the scope layer is defined by strategy. So the features that will be part of the product, the roadmap of where it hopes to grow in the future. And it defines what the MVP is, in a lot of cases. And for the for the purposes of our discussion today. It's an app. And once we understand what scope is going to be relevant to launching the product, that's really where these more concrete layers come into play with structure, skeleton and surface.
Unknown Speaker 2:47
Actually, I actually want to chime in here because I think, with this structure, well, I shouldn't use the terminology that we're using for explaining it. But I feel like with this conversation, or framework, Reek, kind of wanted to take a top down approach, which is higher up to lower because a lot of what we see at this level is the surface layer. without some people knowing those other two layers below it, you know, we did go bottom up was strategy and scope in this time, it kind of makes a little bit of sense going from surface to skeleton structure, though, that's not how you would normally work them through a project because it's more relatable, I feel like to listeners where they can hear
Alex Therrien 3:31
and understand,
Unknown Speaker 3:32
hear and understand the knowledge behind why these things are on this surface layer, what causes those decisions, because it is so fundamental to the rest of the layers that we go through. Whereas some people may not understand fully at it at a glimpse, so we can talk from the top down. Let's go.
Kelly Catale 3:50
Okay, I like that much. Well, I think that strategy and scope are a foundational, as you talked about the last episode. And they're abstract enough that you can speak to them on almost in their own levels. Obviously, strategy is the most foundational and then scope builds on top of strategy, and they interact with themselves in different ways. And then when you think of the remaining three layers that are set above those three, they are, as you mentioned, Alex concrete enough that we could start at the top and start to peel them away like onion layers. I think of Shrek the movie Shrek, like an onion, sort of peel them away as you understand them a little bit more to reveal what the motivation is below them. And that abstractness gets a little stronger, the deeper you get into the onion. And so if we can start with something that's more relatable and easier to conceptualize, it will help tell the story a bit better. So I do you like that?
Alex Therrien 4:48
Absolutely. And as the team member here today, who has the the role of project manager you in our world Are the substitute for the product owner. So yeah, it matters that you're bought in on this. So if we're doing any project, the product owner is going to be on board with how we're structuring it. So
Kelly Catale 5:09
that's very kind of you.
Alex Therrien 5:11
So that said, let's, let's dive into a little bit of a, you know, let's, let's unpack what what these other three layers are. So the easiest to understand is the service layer. So as we think about any digital product, and what your experience with it is, the most tangible elements of that are in the service layer. Let's use an app for example, because that's why we're here. That's what the the episode is labeled surface layer is going to be things like the color choices, the branding, the typography, the iconography, it is the the visual design of the product. And a lot of people look at the design in that layer, they believe that is everything. But below that, we actually have the skeleton layer. And that's really, that's where the layout does come more into play. And we do see still some of that in the visual design and the surface layer. But really the the architecture of each individual screen is taking place in the skeleton layer. And it's you know, how we're blocking out the, the screen individually, the the choice of functional buttons, the arrangement of content, the the type of content that might be in there, that's all decided at the skeleton level. And then below that is the structure. And usually when we think about that, it's it's architectural, the navigational architecture, the information architecture, the hierarchies that exists there. As we think about this, and their connection to scope, and to the strategy layers, there's a series of logical connections that take place across those layers, that when we think about when a product makes sense, and when we think about the usability issues that may come up, some of the user dissatisfaction that may come up in the inner product is really where we start to see, you know, broken connections between these layers. And across these layers,
Nicole Kelley 7:14
I definitely want to include when people look at an application, or an app, or even an interface in an embedded software system, people tend to look at the surface layer a lot, right, because it's what the person sees, it's what the user interacts with the most. It's what we create, and bring at the last layer of final product development. You know, that's what gets out into the users world. And I think a lot of times, oftentimes, people who aren't involved in the process that goes on below, tends to not realize that there's always a purpose. And there's always a reasoning behind every visual aspect, every UI element, every text or font choice, tends to be sometimes overshadowed by the fact that a good design or a good app design, it'll just work. And it just meshes well with the whole experience, because it has been brought up to that level of the foundational steps of the other four below it that cause a really, really strong foundation for these UI elements to kind of sit upon.
Kelly Catale 8:14
And I think one one word you use there that is key to highlight is good UI. So you mentioned that in a good user interface, it may be good isn't the right word here, but in a in a high quality user interface. That is the truth that every piece of the UI should be strategic in a way and should have a purpose and serve a need for the user or for the system in some way. And is not just placed there because it looks nice. And we there can be pitfalls with designs that don't think through every element. And that's why this framework works. That's why this framework exists that Jesse James Garrett has created because it helps tell that story. And it helps you work through those decisions to get you to the surface layer. And it's why the surface layer does not exist in its own little bubble.
Alex Therrien 9:10
Yeah. And when done well, it results in usability and utility. And I like what you said there, Kelly about design shouldn't exist just for design sake. When we're doing a great product, it needs to be fit and trim. And it needs to be focused on what its purpose is. And when you put things that are outside of that purpose. It leads to confusion and distraction and a lack of clear purpose. And great tools oftentimes have a great purpose. Even if they're well rounded and have broad utility. They have focus and each if there's more than one point of focus, each one needs to stand out and be clear in his communication to the end user. Otherwise we lose them and it's no longer As the tool no longer has a place of utility in the life of a user.
Nicole Kelley 10:05
Yes, I think there's a lot of risk that can happen at these three stages. If, as we talked about before, that our strategy and scope aren't well defined, this is the part where if you're not making sure that you're overlapping slightly before you close them out, you know, you're making sure that you're double checking, because this, like I said before, is one of the most tricky parts. If you start veering off course, it's a lot harder to go back and kind of make those adjustments Little by little, if you haven't, if you don't have those connections, or those relationships, or those definitions at that surface level, to your lower requirements, you know, all of the lower features that you had already discussed that kind of build out your scope, it can take a lot of time to go in and dig those out and kind of reroute all your error paths that may occur that you weren't foreseeing, you know, you may set up an entire flow that the user may never interact with, if you didn't have the right,
Alex Therrien 11:04
the right connection to the end users need
Nicole Kelley 11:06
Yes, if you didn't have the right user need that can definitely throw off course, your whole top three layers, because structure won't be able to be there. If you didn't define your strategy well enough, you'll be designing for the wrong purpose. And I think that can cause a lot of pitfalls later on during the development process. And it's a lot harder to get out of that. So tying these two episodes together, our last episode and this one, really do build off of each other and can create a great output.
Kelly Catale 11:34
This creates a framework that multiple stakeholders can use to communicate their needs and communicate their objectives. So you have marketing who has a clear objective and needs to discuss the scope and insert into strategy, right. So in that would pull in some of the technical folks to be able to talk about scope and features. And then when you're talking to designers, they need to be able to communicate with engineers, the software developers, for example, when we're talking about an app to help, really defined structure and what's possible and feasibility, there's, there's all of these layers together tie in, I would say almost every single role that you would have a multidisciplinary team. And that allows for much more code, much more coherent communication and project in general, now that I'm in the pm world, I can see how a framework like this would be really valuable because you're you can get buy in and you can see the dependencies between the different decisions that need to be made and are continuously made as you're developing a design. And the further down you get before thinking about how one decision impacts a different layer, the the more costly it is to change it. Later in the project.
Alex Therrien 12:53
Let's let's talk a little bit about the connection across the layers, we've touched a little bit on how they are relevant to one another. But let's let's talk a little bit more tactically about how how good connection can happen, moving from bottom up. So we've already talked about top down to kind of help ground everybody in in what each of the last three layers is for. But if we're coming up from strategy through scope, and now we're at the point of we understand where we are defining the boundaries of the product, and when we when we start to bring in, what's the architecture of the product? Where's the focus of the app? What's the navigational structure in the information architecture, you have to reflect the priorities of the strategy and you have to reflect the priorities of the scope in in that layer. First and foremost, you know, if this is a, if this is a product, for example, a diabetes, you know, an insulin pump monitoring app. So I need to see that my pump is running, I need to see that what's the rate that it's delivering all these things from the scope that we know that are critical to knowing that this is the system is operating and performing well and replacing, you know that that system in my body, we can anticipate that that may need to be part of the homescreen experience where I can look at a glance and know how my product is doing. Now depending on the particular strategy, we have to meet the user's needs, there may be different implementations of that, which then pass through into the structure or the skeleton layer where we start looking at Okay, what are the controls and features that are on the individual screen? What are the components that exists there? What What is the content that may exist there. And once we understand and reflect how that strategy pulls through the information architecture and the navigational architecture and puts features onto our home screen that we feel like For important, and we have a kind of implementation on them based on how we are trying to contrast with the competition, how we're trying to contrast with what we believe isn't being met in the current marketplace, we can start honing that in the surface layer with the colors, the typography, the illustration style, to speak to the personality of the app, to speak to the personality that we're trying to have reflect through from our strategy. And in the end, we have this connective tissue all the way through this chain through all those layers. And a decision at each layer limits our ability to reach certain functionality and the next layer up. So if we decide that, you know, we are, we want to be a, you know, a low attention requiring insulin pump controller? Well, you know, what do we need that that homescreen Actually, this is a bad example, I want to back away from that, because that's like a class three, that's, that's going to end up training.
Kelly Catale 16:15
For example, if you, you made a decision in your your structure layer, for example, that you wanted a really, really simple screen, that was your main screen that the user interacted with. So have very minimal functionality, because you want it to be minimally distractive and have not overloaded, overloaded with information to the user. That then means you have if you have a bunch of options, or other things settings, you have to define, you're going to have to be locked into certain options of where to put all those, right. And then you might that might mean you have to pick, you have a menu, you have to have this giant menu that is maybe unwieldy. Or it might mean that you're restricted in what you can show for messaging on the screen. So you've once you've picked a certain pathway, in one layer it to your point, Alex would stop you potentially, from certain options in the next layer up, essentially. And I don't know if that's a good example. But I'm trying to think of like, what things that I've seen in the past that have prevented design decisions later down the line. And
Alex Therrien 17:29
I think we talked a little bit about this in the last episode too. And there there is a good example from from work that I've done in the past where there was a therapy app, it was a therapy calculation app and you know, therapy delivery app. And, you know, the the desire from a user needs standpoint was to not live in their health condition. And for for chronic conditions. That's something that we hear a lot about, where motivation lives, where where resiliency lives for dealing with the demands on you know, your health management, it's getting a break from that is really important for maintaining, you know, mate, motivation and sort of behavior change elements as part of your health management. And where we had a big disconnect in the team was one side of the team was was highly focused on the delivery of that therapy information and getting somebody in and out and on their way, because that's their, that was the strategy that we all agreed with. And there were other members of the team who had a belief that there was a high value to education as a feature in the product where they believe that there was there was high value in sort of teaching people about their health, teaching them about how to manage their health. And they wanted almost this entire course curriculum that your your healthcare provider could assigned to you, grade you on your progress, evaluate your your your capabilities, and continue with this education portion, which on its own is a great product strategy, but it wasn't aligned with the strategy of our product. And where we ended up in a rough spot was trying to serve as both strategies within an architecture and within a skeleton. And within a surface layer that didn't support both of those products, as one each of them was was honestly its own. quite valuable. And yeah, you know, demanding product for what would fit into an app.
Nicole Kelley 19:34
You're giving too many options, too many core messages on one screen. It's like somebody's yelling stop and somebody yelling go on the same screen and you're like, which What do I do? What do I do? I think that tends to happen. You try to fill something with too many ideas, as in your case, at that bottom layer, two different strategies which are competing against each other, that can cause a lack of attention from the user that's trying to actually have a benefit from using This application or this method, or this device,
Alex Therrien 20:03
and increase friction in the navigation of like, Okay, I have to manage my health. You know, let me use the, the metaphor for, we're going to a GPS app, where it's telling us how to get from from point A to point B, if it's certain slowly starts trying to quiz you in French, you're gonna have some trouble navigating to where you're getting to, and you're gonna be really frustrated as a user, because you're like, well, I don't understand why the navigation app is really inserting a lot of choices in my my, as few steps as possible to get to understand where I need to go for two o'clock today, because I got a meeting. And I've got like four options on picking my next French class, like what's going on here, and I don't know what to do next. I'm out, I'm not doing this product anymore.
Kelly Catale 20:50
One of the pitfalls can be that you want to have a really flexible product, and you want to accommodate multiple user needs to your point, Nichol they might be directly conflicting, the more flexibility you allow, and the more options you allow for your design. And the product in general, usually makes it more complex. And I know I've worked on products where we've had requirements from marketing that says, oh, the user needs to be able to do X. And there's a certain condition that needs to be met to be able to meet to do this workflow. And it turns out that maybe they need to their to be able to meet that condition, they could have one of five different ways that they could meet it. And we have to accommodate every single five of those workflows. And then it becomes where do we put all those options? Where do you how do you accommodate every single one of them, and to please everyone can often mean that no one gets a nice workflow, no one gets a good experience, because everyone has to be satisfied. And that's where, again, this ties back into the strategy. And the scope is where where do we draw the line so that the design doesn't have to compensate for potentially unclear objectives at the beginning, and the foundation of the product? definition?
Alex Therrien 22:11
I can't second that enough. And I think a great product serves a great editorial perspective on why it exists. And without a strong editor. And usually that's it, the more editor's you have the less strong view you have, I am a big advocate for a good decider in the mix, you know, and many cooks in the kitchen. Exactly. Say that good old analogy. Yep. And it's fine to have a board that you discuss with but somebody's got to make the cuts at the end of the day. And yeah, I can't second what you said, Enough.
Kelly Catale 22:48
We've been using when we were preparing for this discussion, the phrase intentional design, and I think we're really hitting on it now is, we want to be intentional about every decision that's made. And it's not design is not hopefully, listeners of our podcast can now understand that design is not just the surface layer, that it is all five of these layers together. And each one of these layers has intentional decisions that need to be made together form the intentional design of a product. And we've talked a little bit about a few examples and whatnot. But this is really the underlying principle that we're getting at.
Alex Therrien 23:29
Absolutely. And, you know, we are believers in that that term intentional design, and we've started to push that more and more with our clients. And it really does reflect this logical chain through each of the layers and how each one is reinforcing the learnings and validating them, honestly, by trying to build it, does it work trying it out with users? Does it work? Does it make sense. And then, you know, a lot of times it's in the execution to there's these ideas of consistency and the consistent logic string through the product, as well as the consistent application of that logic. And as we look at those, you know, there's everything from the tactical, to the strategic, and I think we've been talking quite a bit about the strategic with how it promotes certain features. And, you know,
Nicole Kelley 24:19
I like similar to you mentioning, you know, making sure that your client understands also making sure that your fellow employees and teammates also understand that making intentional decisions with your designs, because even if it may seem like it's just a simple dashboard, or if it's just a simple data logger, making sure that even if a UI UX designer isn't involved in that process or wasn't on that team, having your engineers be conscious of those decisions and making sure there's a reason for them. Because I think even at that level, you can insert a little bit of user centered design in there, you can make sure that you're being conscious of the decisions you're making, so that if you want to make something a certain color, you're not Just throwing a random color, you're really thinking critically about these decisions, because at the end, it does affect the person using it, even though it may not seem like it is at the moment of the decision, you really need to peel back those layers of the onion, as we mentioned earlier, and, and dig deep into why. So going back to intentional design, making sure there's just a overall balance between all the things that you are thinking about,
Alex Therrien 25:24
and how we can help people take this tomorrow and make use of it. If you're not a user experience focused, or design focused individual, but you're interested in these principles. There's a few different ways that you can act on this, you know, from a tactical standpoint, there's internal consistency, you know, if you look at the upper three layers of the stack, you know, are your buttons, buttons, you know, or do they if you use one design for a button in one area of your product, is that the way a primary call to action button appears throughout your product, it's little things like that you could be surprised by is the the navigational patterns, the interaction design patterns and patterns, meaning you can walk through a flow, or you can get, you know, a piece of motion built into your product, things that lead a user through it, are they consistent between features, if you're if you have an expanding menu is that the the way all your menus work? Is there a logic for why they don't all operate that way, you need to be intentional about it. And then you need to find the internal consistency and logic within your product. But also think about external consistency. How you're looking at the way users are learning from other products around them, that are like your product, and reflecting similar user interface conventions. You know, it's important to think about intellectual property and what you can do that's unique and novel to your product. But at the same time, doing something wacky, that's brand new, just for the sake of being wacky and brand new, you can end up you know, causing your users to train wreck in the same exists at the strategy level, you know, if we're keeping our most prominent features, you know, first and foremost, you know that that starts to reflect our strategic logic. And, you know, growing beyond, you know, the the logic while executing the product, you want to keep yourself consistent with where you started. And acknowledging that your strategy has changed, if you start doing something in the navigational layer or with with feature creep, that, you know, takes you in a new direction,
Kelly Catale 27:40
I want to add something absolutely what you were just saying about external consistency. So being someone who's worked in risk management type realm for years, there is something to be said about consistency and the benefit, but also the potential drawback of being consistent with something. And this is something to keep in mind when you're developing an app, especially because in the medical realm, medical, and we should always emphasize this as in medical, we are risk driven. So everything we do needs to consider potential harm to the patient, or potential harm to the clinician or whoever it is that you're using the end product or being impacted by the end product. Sometimes being consistent with commercial apps, because that is what people know. And when you talk about, oh, we're developing an app, I use this app every day. It turns out that app I use every day is this harmless watch step fitness tracker that if it was wrong, it doesn't actually matter. And if I get if I have an error on it, then and I misinterpret the message or something, there is relatively minimal harm to me. Now, if we try to mirror those interactions and mirror the same expectations within a medical device related app, we could potentially present some level of harm to the end user. So there are times when it calls for having something that diverges away from commercial app, commercial expectations. And that's where we go back to intentional design. Sometimes we exactly. Sometimes we have to decide that. Yes, everyone knows the way that an iPhone works and the way that a different commercial products might work. And there might be a strong desire to mimic that because we know that it works and we know that it's easy, but there might be inherent harm when it comes to the medical application. And I'm trying to think of a good example where this might be the case but I can speak more generally saying that there are times when we have to go against the way that commercial expectations exist because we are dealing with medical products, and it's not to say that commercial isn't valuable, and that the way things are done there aren't clean and smooth and effective. But there are times when we have to consciously decide that Yeah, the risk associated with a certain action or a certain workflow or certain screen mandates that we have something in place that might be slightly more cumbersome, or might might appear to be less flashy than what you might see in a commercial application.
Alex Therrien 30:28
And, or, or simplified in terms of its user experience, you know, a good example that I can think of is the natural tension between user experience and security. So let's go back to our insulin pump design. And, you know, if, if I'm looking for some of the more novel ways of it just connects that you see in bluetooth headphones, you know, they're they're a low risk product, if somebody gets a hold of your Bluetooth headphone signal, there's, there's, you know, you might be embarrassed because somebody could listen in on your, your cell phone call at worst. But, you know, if somebody maliciously gets ahold of the the ability to access your insulin pump, suddenly they're driving your pancreas, there's sort of a different outcome associated with that and is an insulin dependent population there is is suddenly in a really bad way is it's I get teased about that metaphor of people driving, oh,
Kelly Catale 31:24
I just heard I, you know, driving your pancreas a little sterile.
Alex Therrien 31:30
A little person at the wheel of a of a, of a blob of pink.
Kelly Catale 31:34
Yes, but it's but it is no joke, right? Because the ease of which my headphones currently, when I go out for a run my headphones pair with my phone within seconds. And if for some reason it accidentally pairs is my husband's phone, and I listened to his podcast that he's listening to that's harmless, right. But if it to your point, someone connects into my insulin pump or something else that might connect, it could lead to serious harm. And that is, it's really true and valid consideration when you're talking about medical products that are wet, or trying to come close to commercial product experiences.
Alex Therrien 32:15
Absolutely. And as much as possible, we certainly acknowledge that there are pain points with that, that we have to trade off against. So sometimes it even can require you to over perform in other areas. So if you're having to trade this, so we're giving you security on connecting to your imaginary pump, well, maybe there's other areas where you have to give back now you invested once, now that you've sunk that capital into connecting the device now we we make sure that that's ironclad never gets disrupted. And it always works. Or there's other areas where we make every other experience with entry of information through your app or your phone. Once you've connected it, it all just comes in easily. You never have to touch it. Again, there are other trade offs that we can still Aspire and take that burden off of the users. Because we all know that to make a patient's life better, which is our mission is to you can't just say, well, it's a medical device. And it's okay, we certainly aren't advocating that we want the best for the patients because that will move the needle on their health indeed, fantastic.
That covers our discussion today, on the final three layers of the Jesse James Garrett, layers of user experience framework, we think that they are really powerful tools that all five layers working together and the logic structure that can happen across it. They're a powerful tool to help you build the most powerful experience and useful tools that you can imagine, and still relate them to the user and be successful in business. That was really, really roundabout. Let me try that again. So in summary, the Jesse James skerrit, five layers of user experience and their logical connection across those, it's a powerful framework for making sure that your app is relevant to your end users, and is a clear tool that will fit into their lives, we find it to be a very useful framework and method for reflecting on how we're building successful tools in our work every day. And I personally find it a good touch point at each milestone to be checking backwards on how we're succeeding against our original vision, and how our vision may need to change.
Kelly Catale 38:01
I fully agree with everything that you just said, is a good wrap up. But I love this framework, because it gives us an opportunity for all of the voices in a multidisciplinary team to express their needs. And like you said, the coherence across all five layers helps drive a really clean and effective design, intentional design, as I'll use the phrase, again, that addresses some of the complexities and potentially the simplicity of a potential design.
Nicole Kelley 38:31
I just want to mention that if you haven't already listened to the previous episode that talks highly, are talks more in depth about the strategy and scope layer, definitely go take a listen to that. And then it'll give you a bit more understanding of where we got to the three sections we talked about today. And it'll give you a really well understanding, like Alex and Kelly had mentioned about the foundations of really creating a good experience for your user, of your product of your device of your anything, honestly, this can be used multidisciplinary.
Alex Therrien 39:05
As a final note, I like the point about making the critique of design, very accessible to the broad parts of the team through using this framework, because it gives a non opinion based way of making sure that we're all heading in the right direction and in the right way, without being, you know, driven by personal aesthetic taste. It's it's driven by logic. And I don't think that that can be overstated enough, you know, having that inroad in that that way of building trust, and that may be a later episode about good critique and good frameworks for collaborating with design going forward. But I can't under I can't overstate that enough.
Nicole Kelley 39:48
Yeah. Well, thank you. I would say everyone that's listening today and listen to our previous episodes, we really appreciate all the listens and downloads and whatnot.
Alex Therrien 39:57
So definitely reach out and let us know if there's any ideas Is that you have about new topics.
