Let's Make an App: Why Strategy and Scope are the Keys to Success
This is the first of a two-episode series focusing on what to think about when making an app. In this episode, Alex Therrien and Nicole Kelley discuss how strategy and project scope can be used as the foundation of a logic structure in developing an app.
We share our experience on how you can use your user and business needs to build a solid foundation and set you up for later success.
We reference the frameworks and diagrams in Chapter 2 of Jesse James Garrett’s seminal user experience book, ‘The Elements of User Experience’ throughout our discussion. If you would like to learn more Download Here
Alex Therrien 0:01
Hi, everyone, Alex here to apologize for some audio issues in this episode, my laptop had some problems. And you know, it happens. We worked hard to clean it up for you. But you’re still going to notice some audio issues in today’s episode. thanks for bearing with us, I promise that the content is worth it.
Nicole Kelley 0:30
Welcome, welcome back to user centered by design, the podcast where we talk about all things related to user centered design. I’m Nicole Kelley Ux UI design.
Alex Therrien 0:41
And I’m Alex Therrien, the director of user centered design at sunrise labs. And today we’re going to talk about making an app. So you know, to understand today’s conversation, there’s a great reference book. It’s by an author named Jesse James Garrett. It’s called the elements of user experience. And it does a really great job of breaking down the design of any product into the into some specific layers that helped to explain the how to build a solid foundation for good design.
Nicole Kelley 1:14
Yeah, we use this framework in our team as well, Alex, I know you’ve been using it a lot longer than I have. So could you quickly go over a bit deeper into what exactly it means. And then later on, we can explain where it fits in, especially for helping people figure out, you know, if they even want to know,
Alex Therrien 1:30
to anybody listening, you can download this, this chapter of this book that we’re referencing for free on the internet, Jesse James Garrett has been very generous to put this out there. And I think it’s a great reference. So there are five layers to any design according to this framework, you start off with the strategy layer, which is the foundation and basis of the product. The strategy is the reason why the product exists. It usually focuses on user centered reasons. And it’s why somebody might incorporate this into the life. And it’s also where you express your perspective on how you’re going to approach the users problems and in why this product should exist. The next layer up from that is the scope. So what are the features that are are part of the project scope? What’s the MVP definition, what what goes into what’s in and what’s out, and how we are representing the strategy in a series of features and content. Above that is, is the structure the navigation architecture, the information architecture, sort of this? The the logic of the product past? That is the elements of the interaction? So you know, what kind of controls what kind of ways of navigation, what are the choices we’re making that start to come in, almost as wireframes. And the last level is the surface. And that’s what we perceive in any product when we look at it. So it’s the visual design, the colors, the typography, those kind of elements of the brand. And what happens is, these layers relate to each other. And they need to have a logical connection across those layers to be successful.
Nicole Kelley 3:12
That was a great explanation of the elements of user experience, Alex. So let’s take a step back and think about why somebody would even want to make an app right, we’ll talk we’ll talk about how to be successful if you want to make an app. But we really need to start thinking of the foundation. First of if you even need an app will first explore that if an app will fit with a user’s needs business needs, and even be technologically feasible. It happens to be a trend, but and we see it often. But we need to ask, will it actually add value to your patient and your patients needs? So what are your first thoughts when you start to think about that really setting the foundation for for a client.
Alex Therrien 3:54
So we really want to come back to the first two layers of the elements of the user experience, we’re looking at the strategy and then the scope for thinking about strategy. It really is grounded in the representation of the users needs, how they’re overlapping with the business needs. And then a lot of times we can even get into, you know, is it technologically feasible? So if we’re thinking about those, how do you how can we successfully define the strategy and scope players,
Nicole Kelley 4:26
you have to really look into the user needs and if the patient even needs the product, you need to ask yourself, will it actually add value to your patient, you know, sometimes an app or something that the patient has to log in, you know, fiddle with, when they’re already taking so many other things and on other equipment, it can create a sense of tension and can actually cause less adherence to the product or the medicine that they’re taking. So when you really start that strategy stage, you really need to go in depth with the user needs at first to even know if it’s going to help your business needs, you know, that’s the first layer of business needs there. a bunch more. But really seeing if it fits with your user, you know, is definitely a good start to that process. Yeah, if
Alex Therrien 5:08
we start from that standpoint of a common business need that we have is data data is is very interesting to a lot of clients these days. And so if we’re trying to get data for the client to be able to refine their product to improve their experience, it really comes out of the user incorporating this product into their life and incorporating the the new tool into their, their their daily living. And to be successful with that, you really have to invest the time and understanding their needs. And that’s the serve any program really needs to de risk itself. By looking at that as an initial point of research, and to develop concepts and to look at the different ways that you can embody a product, from a strategy standpoint, to explore those user needs and see how well they would reinforce what the business goals are and and what you’re finding from the business needs.
Nicole Kelley 6:12
I can think of a good example, especially in that and even if you have business needs that you want to click data, like you said, maybe impossibly, really thinking at this strategy stage of another way that you can get that data may not necessarily be in a mobile device that somebody has to log in and capture that data, maybe the device itself captures that data and sends it back. So you’re not adding another level of difficulty to that patient’s life. But you’re still, you know, getting that data that you need for refinement. That’s definitely happened in the past, where sometimes you just look at, let’s make an app because we really want it and we really think it’ll be great and the data is wonderful. But taking a step back and really thinking about it can help you understand the full ecosystem of the patient, and also your products ecosystem and making sure that you’re still getting what you need. But the patient’s not over bombarded with their potential medical products or medical devices in their life.
Alex Therrien 7:08
Yeah, it’s this sort of question about how ever present as your product need to be in their lives
do they are your product for you know, a chronic condition may be necessary, but it’s, it’s also not a lifestyle brand. If if I’m a patient who is dealing with a health condition, I want to be a person, I want to think about myself as a person and grounding somebody in a tool that requires constant care and feeding can actually send you down the wrong path as a strategy, it may get you there may be the pathway to getting you the data, but you may find disengagement very quickly because they aren’t, they are there for experiencing your brand every day and living in their health condition, they’re there to get better. And even if it’s a temporary despite from from their chronic condition or their, you know, maybe it’s even just a limited term condition. The goal is a transactional one, it’s not a continual investment in your brand. And asking that in the in the execution of the product means that your strategy is fundamentally misaligned with your users goals. And you’re going to end up not successful. And when you get down to it, that tension between business need and user need, really fleshing that out in your strategy layer, and your scope layer to kind of figure out where those tensions may be. And prototype methods of resolving them. It’s so key to success in in the app space, if your patients have stopped adhering to their their regimen or their therapy, they’re not going to be getting better. And that’s a major difference that we’re trying to have in their lives. It also means that the reimbursements are not going to be there because you’re not having health outcomes. And both of those are so critical to success in the space, that you have to find the alignment between user needs. And business needs to be successful, especially in apps. The connectivity and the expectations in this marketplace are are significant and to be relevant for the end user.
Nicole Kelley 9:21
It really sets up the foundation, I think definitely stressing on all those opinions. What if somebody gets to that point where they feel that their business needs and their user needs all align. And they’re actually it’s a very good product. And they’re, they really see value in making this app and improving the patient’s lifestyle. I mean, that’s when we kind of go into the scope realm of things where we start really defining timelines, features budget, and making sure that we are containing everything so that we don’t have scope increase. We don’t have surprises at the end when we really need to start defining all of the features and the requirements for this product to make sure that it’s meeting all the regulatory challenges that may come along.
Alex Therrien 10:04
Exactly. And, you know, there’s always this dance. And it comes back to the scope layer. You know, when we’re actually in the heart of development, building the product, where the trade offs between timeline features and budget impact roadmap, and we’re thinking about the prioritization, knowing what the core of the user experiences, knowing how those core features are aligned to your strategy. So your users, your user needs are to get better. But there’s also some some subordinate elements underneath that, where how are we returning them to their daily life? How are we getting their tasks out of the way so that they they are confident that they’ve successfully managed their health condition? How are we giving them feedback when something needs attention, but in a way that isn’t monopolizing their life? Well, those features, you know, those features support the experience that we want. The roadmap is sort of a key element of the MVP. It’s it’s a way of managing the project, to ensure we’re hitting the strategy and prioritizing the right features and moving the back and forth to achieve the business goal. Depending on how we’re doing against timeline, features and budget,
Nicole Kelley 11:26
you’re talking about roadmap that out, we can definitely obviously, we have to understand the connection between MVP and making sure you have a well defined MVP, which can lead into, you know, definitely making sure that you’re building clear definitions at a higher level. So that you’re ensuring that everybody’s aligned, you know, stakeholders will understand the definition from their perspective. And if not, then you make sure that you build a shared understanding, because there can definitely be scope increases within that MVP building, you want to make sure that you’re adding functionality in a type of approach that’s very robust in a way so that you’re making sure everybody’s aligned, because you need to make sure that there’s detailed descriptions of the functionality to make sure that you’re not confused, or there’s no misalignment when you’re actually starting to design these types of specifications and requirements and functionality.
Alex Therrien 12:27
And early experience of vision prototypes are kind of a key element of this, you know, there have been projects that have been part of in in the past where we were talking as a team about education. So a patient needs to learn how to use their device patient needs to learn how to manage the therapy, and one team member was talking about education as here’s some frequently asked questions, maybe a video and we’re out the door and other team mates were talking about you a series of courses that your clinician is going to assign to you with a lesson plan and grading and, you know, heavy, heavy interactive dynamics between the clinician and the patient. And the the interpretation of, you know, educational content was, was the difference between, you know, a feature in a product and an entire company based on education. And, you know, having that kind of misalignment in the product is what can scuttle an entire project and send it send it, you know, into the waste bin. So, investing in early experience, vision prototypes to help flesh out and understanding across the team and across the stakeholders and making sure that you’re referencing back to your strategy, each one of these layers has to be built sequentially. So that you’re staying grounded, your strategy should guide your your scope, and your appetite for that scope. And if your user need isn’t to have, you know, skillshare.com within your app, just to handle the education part, then you need to cut it back to be what is appropriate.
Nicole Kelley 14:12
When developing the MVP. I think there’s a level of making sure that you’re validating your reasoning, even at the scope layer to make sure that you’re going back and forth, you’re kind of overlapping those layers of that design framework to make sure that you’re not missing anything. And you’re not completely done with strategy yet, because you want to have a well rounded, secure, strong foundation of your strategy and scope to make sure that you can build off a bit later and not cause no increases in time budget, like we said before, so definitely when during MVP, validating that your features meet the user needs so that we can de risk any potential scope increases further on.
Alex Therrien 14:52
I can’t agree more and it’s actually a great principle from the Jesse James Garrett book is that these, these activities to define each of these layers in one should be ramping down. But it shouldn’t be completed until you’ve done some experimentation in the next layer up. So our strategy may make sense to us. But until we experiment with scope, and figure out what are the right features and how we define those features, we really haven’t validated the strategy yet, as you said, and, you know, at all layers, there’s there’s different types of fidelity of prototype that we can do that would help to confirm, do we have the right product defined,
Nicole Kelley 15:39
after going over the stack of strategy and scope, there’s a few examples that we have from our experience. And just other experience in general about, for example, user needs, has two different strategies, you could potentially hone in on clinician user needs typically focus on getting decision support, whereas they don’t want raw data. Usually, it’s easier for a company to give raw data versus a clinical recommendation. But it’s not always what they want. You know, there’s there’s definitely rationale and reasoning for this within the strategy, but you just kind of have to go over that and make sure you’re defining it pretty well. And you’re making sure that you’re not missing anything.
Alex Therrien 16:17
Yeah, from a regulatory standpoint, it’s certainly a lot easier to to give raw data, because there’s less, less responsibility taken for the outcome by by the Corporation. Right. So if you’re making clinical recommendations, have you met the patient? No, it makes it it’s a much bigger hurdle. What clinicians are asking for is not a mountain of raw data, because it’s overwhelming them, and what they what they need, and what the strategy may be suggesting. Depending off is based on user needs, or business needs, that they can actually be in conflict, this work we’re calling out here,
Nicole Kelley 16:59
there’s also another avenue to go for, which is, you know, really focusing and honing in on the patient’s needs, you need to make them confident in their ability to manage their own diagnosis, or to help them and facilitate them and being self driven in their therapy.
Alex Therrien 17:13
If we talk about some specific examples, from our experience, there are products where we have recommended not even implementing an app, there are products that we’ve worked on where the therapy device itself could have a much simpler user interface, a much more robust user interface, in some cases, without all the burden of trying to connect over Bluetooth of trying to control a device remotely. And it was a simple therapy. If you can manage the therapy with the device and carry it with you, then you were all set. And that really lessen the reason for an app to exist. So then it just became a problem of solving How do you get data off of the device to say that the patient is using it successfully, that there’s no, you know, risks or health issues that need to be flagged for the clinician to intervene. And those are simpler problems that that we can solve, where we’re able to, to simplify the implementation of the product, so that we’re not having to deal with the burden of incorporating an app into a user experience that doesn’t really need it. There’s other opportunities where we could be looking at diagnostic data, where can it be easily transcribed? Can it be, you know, communicated more easily? If if you’re just doing one symptom, once a day, or one symptom? infrequently? Really, do you need an app to support that experience, because you got to look at the burden of setting it up, building an account, building a profile, connecting the devices, that’s a lot of overhead for something that is a simple, infrequent interaction. And there might be a better way of serving the business need of getting data. So some positive examples where an app could really deliver value and have an impact. From a strategy and scope standpoint. You know, things like teaching a user how to perform a diagnostic test, or you know how to deliver their therapy successfully, it sort of extends beyond the 15 minute education that you could get at a clinician clinician visit. No therapy, adherence for more complex conditions is core to this, how you master the delivery in in your, in your day to day life so that you build the confidence and you’re successful.
Nicole Kelley 19:46
Another good example would be conditions or therapy calculations where an error could cause a lot of harm. You definitely never want to have a condition where or a product where you’re putting your user at a lot of risks that they can’t negate
Alex Therrien 20:00
and removing the opportunity for harm is is a great part of what we do is device developers. And it can also benefit from alleviating the burden on the end user. It bringing safety into the product doesn’t have to be in conflict with it with a great user experience, and what can we do to simplify the amount of touch points a user has to have with the product to still get the same benefit. And it also gives us the opportunity to increase therapy, a management touch points between clinicians and patients. If we can take the therapy intervention from once a quarter, once every half year to when something happens, the data is available to the clinician to make an intelligent decision, because they’re able to look in on their patients virtually, you can really hone in and dial in on the right amount of therapy to make our clinician and patient partnerships successful.
Nicole Kelley 21:05
So all these examples definitely are very good value adds for your strategy standpoint for user needs. You definitely, though, are not limited to these examples in medical device development. There may be other things within the fields in different fields where having good value adds can help your strategy improve
Alex Therrien 21:25
your product. There you go. You’re absolutely right, Nicole, this is not limited to just the medical environment. And the great strategy is really born out of the the crossover between well understood user needs and the needs of business, if we can align those, find the alignment between those two areas. That’s where the great products really are born from and having a great strategy in that space. And a great perspective on what you can do within the the overlap between those two areas of need, really gives us great guidance on what scope and what what feature decisions we should be making, to to really launch the product team off on the right foot. So that everyone is on the same page about the definition of each of the features, and an understanding of why these features are important to the end user and how adoption is going to both better the users lives, as well as the business’s ability to to, to thrive in this marketplace.
Nicole Kelley 22:37
I think when you fully define these two stages, as we probably mentioned beforehand, it really sets a foundation, a strong foundation is what you really want for developing an app specifically in this field, because you have, these are only the first two, you still have another three to go through. And you want to make sure that you’re adequately defining your process before you move on to the next one. And similarly what you said Alex, making sure that everybody understands the user needs and the business needs so that everybody’s in line and is on the same strategy, making sure that the product development and definitely making sure that the product development goes smoothly throughout the whole process
Alex Therrien 23:18
well said. And so many tough decisions happen later on in the product. Getting off on the right foot is key to our success later on. And you know, that’s when we start getting into some more subjective areas or potentially subjective areas of the design. And, you know, starting off from an align standpoint, on the strategy in scope, it makes all those conversations a lot more grounded and a lot more simpler. But that’s something for a nother podcast.
Nicole Kelley 23:46
In next month’s episode, we’re gonna be talking about the other three layers of the user experience. And we’ll also go more in depth on there. So if you have any more questions, if you happen to look at
Alex Therrien 23:56
Jesse James Garrett’s elements of the user experience,
Nicole Kelley 24:00
then you can let us know and we can try to answer some of your questions, as Alex has been really thorough within that process. So if you have any questions, let us know and we’ll incorporate them into our next episode.
Thanks