How to Help Developers Make Apps Users Love - posit::conf(2023)
Presented by Michał Parkoła There are many resources that can help you design better apps. But what if your org creates many apps? Scaling good design to larger groups dials the challenge up to 11. In this talk, I will share how we approach the problem at Appsilon. - I will present our in-house Design Guide. - I will share the successes and failures we've had building it and helping a wide variety of developers use it - I will then share some tips about what you might want to consider if you want to help your org build better apps at scale. Presented at Posit Conference, between Sept 19-20 2023, Learn more at posit.co/conference. -------------------------- Talk Track: Shiny user interfaces. Session Code: TALK-1127
image: thumbnail.jpg
Transcript#
This transcript was generated automatically and may contain errors.
Hello, welcome to my talk. Now we are going to talk about making apps that users love. Not only that, because it's hard enough to make one app that users love, but what we are trying to do is not only to do that for one team, but to help dozens of teams at the same time do it. So, this will be a story of some of the tools that we are using at Appsilon to address this problem.
But before we talk about what we do want to achieve, let's talk a little bit about what we want to avoid. So, welcome to the application graveyard. This is a place where applications go where they are not quite what we set out to achieve. For example, some apps, strictly speaking, satisfy requirements, but perhaps no one ends up using them. Perhaps they are just too hard to use. Maybe they are too slow, they are full of technical jargon, or have some other deficiencies that make them hard to use.
That can easily kill an app. And finally, maybe the app is just ugly. So, I'm not ashamed to admit that from time to time, one of our apps can reach or get close to the application graveyard. Hopefully, it can be rescued from there. And I wonder, like, what's your experience? So, put your hand up if you have seen an app that was in the application graveyard. Yeah. A lot of you. So, hopefully, this talk can help you to avoid it in the future. So, that's what we want to do. We want to escape the application graveyard.
What great design really means
Okay. So, first of all, like, of course, we are going to try to do it through great design. But we don't only care about design for its own sake. Of course, we care about it because great design is a path to what we really want, which is adoption, people using our apps, and impact. That their lives are better and the results of their companies are better as a result. And, of course, the opposite is also true. That if we ignore design, and we by accident end up with a bad design, this can be a significant obstacle to adoption and impact.
So, a few words about me. My name is Michał Parkowa. I'm a manager at Appsilon. And I manage our design team and the design tools, one of which I will tell you about in a second. And so, also, what I wanted to share is that in my career, I have learned two things that I wanted to share today. And that is that design is not only about how things look. And the second thing is that it's very hard to change a larger organization.
But first of all, it's good to start with answering the question, what is great design? Because design is a very general word. Many people have different ideas about what it means exactly. So, the first thing is to clarify what do we mean by great design in our context?
So, first of all, our assumption is that great design makes apps useful for a particular type of person, for a particular application solving an important problem for them in their particular context. So, number one trait or result of great design is usefulness. Number two, that great design makes apps easy to use. So, it's not enough that it technically solves some kind of problem. It helps if it's easy to use, if it doesn't provide or put unnecessary obstacles in the path of the users. So, number two, easy to use. And number three, beautiful. So, as I said, it's not the most important thing. It's not the only thing when it comes to design. But, of course, it is one of the factors. And one reason is that there is a bias that beauty equals virtue. So, if it's beautiful, it gets judged better regardless. And, of course, we want our users to be happy about using the app and we want to be proud for the apps that we create.
And one reason is that there is a bias that beauty equals virtue. So, if it's beautiful, it gets judged better regardless.
Okay. And one thing I wanted to underline, those are some high level aspirations. But in practice, we are not expecting that everyone will hit perfection every time. So, it's enough to use the tool to make things better, to make the app a little more useful, a little easier to use, a little more beautiful. And that's already the start of a success. It doesn't have to be perfect from the start.
Applying the framework: a real project
Okay. So, let me give you a quick example of how we use this framework in a recent project that we had. So, we built an app for Boston Medical Center. It took about two months. It's called the Health Equity Explorer. It helps doctors and researchers analyze data about population health to hopefully discover systematic factors that lead to good or bad health outcomes for a whole population or area.
And so, one thing we tried to put a lot of effort into making it useful. And we did it through, like, close collaboration with the client. We talked almost every day to make sure that we really understand their needs, that we understand their context, and that this app really fits those things. And second, we tried to make it easy to use. And, of course, the key tool to make it easy to use is user testing. So, as Maria told you a few minutes ago, it's about having the user attempt to perform their task in the app without too much explanation, without being led by the hand. And then we can see, are they successful? Are they not? Where do they get stuck? And so on. And then we can go from there. So, we did a lot of user testing for this app. And then in the end, of course, we tried to add some spit and polish to make it a little nicer to look at.
Who should be involved in design
So, the question is, like, okay. Great design. Nice story. But so, who should be involved? Like, one thing, a great design. So, maybe the designers are responsible for design. And, of course, designers should be involved. But it's not only designers. Like, other people need to be involved in the whole process to achieve that goal. Like, also managers, project leaders, engineers on the team, and maybe most importantly, the clients themselves. So, design is not only about beauty and design is also not only about designers.
The design planning and evaluation tool
So, how do you make it happen? Well, now I'll show you. So, we have several tools that help us do that. But today I'll show you one. And this one is our design planning and evaluation tool. It's a humble Google sheet with some sections. And so, now I will walk you through the various sections. Don't worry about reading the details later. I will give you a link and you can download it for yourself and learn more and hopefully adapt it or use it for your projects as well.
So, there are four sections. One is like a general information section, client app name, the history of our involvement. Because maybe we are taking over an app or maybe we build it from scratch or maybe we are evaluating an existing app that we didn't even make just to learn about stuff. So, that's the first part. And then there are three parts relating to the three traits of great design. So, blue section, usefulness, green section, easy to use, red section, beautiful.
So, zooming in on the usefulness section, one key thing is that we separate planning and evaluation. So, at first, we started with the evaluation part. But quickly found out that if we evaluate a project at the end, of course, that's too late to change anything about it. So, definitely, we have to plan to achieve great design up front. And then that's at the end, the evaluation will be better. So, one thing, there's a section to just answer the question, like, who is it for? What is the target audience? What kind of users will use the app? Of course, it's not enough to just say users. And what problem are we solving for them?
And then we have sections for the things that we really want to achieve, which is adoption. How many people will be using the app? How often? Over what time? And what impact is it going to make? So, for adoption, it helps to ask up front, okay, how are we going to measure it? Like, just putting in the instrumentation to measure adoption is already not obvious in some situations. So, how are we going to measure it? And then also, like, what would be a successful number? Like, what are we expecting to achieve? And then, let's say, after a few months, let's say we have ten users. Is that a success or not success? Well, it depends on what kind of users, what problem they are solving. Sometimes one user using the app once can be a success if it's like, I don't know, they show it to some senator and they then pass some law based on the that they are convinced based on the app. So, maybe that would be a success even though it's just one user. So, it's good to have those conversations up front.
And also, an important conversation that is good to have at the start is that to imagine, like, okay, we've shipped the we are talking about some app. The client maybe lists some functions that they expect in the app. But then it's important to ask, okay, so let's imagine we ship the app. All the functions are there. And what will happen then? A very simple question. But it helps to uncover maybe gaps in our thinking. Maybe to achieve the goal that they have in mind, maybe not all of those functionalities are necessary. Or maybe we need to do something extra. Maybe we need to do some training. Maybe we need to do a video explaining the app to people. Or maybe we just need to collect email addresses before we ship the app. There are many things in the general area of, let's say, product management that we can do to achieve this bigger impact regardless of the shape of the app. So, that's going through this section in the sheet helps teams to have those important conversations and to explain with clients, like, why are we asking those questions and in what context do we see it?
Ease of use and beauty sections
So, that was the usefulness section. Ease of use section includes some various methods. That's the general shape of the tool. In each section, we collect various methods that we are experimenting with. And over time, we can have conversations. It's not mandatory to use all the methods for all the projects. But it contains options to consider. So, for example, the main two things that we have in the ease of use section is, of course, user testing. So, that's the same thing that Mario was talking about with prototyping and quick prototyping showing users. And the most important thing is that we don't want to explain it to users and ask what they think. We want to see them use it with minimal explanation and then talk about it. So, that's the gold standard. User testing for us.
But, of course, there are also other ways. So, we like to use this list of 10 usability heuristics by Jakob Nielsen. That's an article that summarizes how to make apps that are easy to use. And so, for example, this is an example of a filled in evaluation for one of our apps with those Jakob Nielsen heuristics. So, as you can see, we did a good job on visibility of system status, but maybe not necessarily error prevention. So, that would be a signal to maybe in the next iteration, we should think about error handling.
And finally, the beauty part. So, of course, beauty is to some extent subjective, but the opinion of specific people is already a fact. So, we can work with that. We can have also expert feedback or also heuristic evaluation using a slightly different set of heuristic evaluations just for aesthetics, not usability. And finally, we had a good experience with an ebook called Refactoring UI, which contains a lot of design tips that is specifically tailored for developers to use. So, if we don't have a professional designer involved, it helps to use Refactoring UI and go through just tips that are there. And you can get surprisingly far that way.
Getting teams to actually use the tool
Okay. So, I showed you a lightning review of our this form that teams can fill in. But you might be asking yourself, but is anyone actually going to use it if we just send by email to all the teams, oh, here's a new form to fill. Please use it. That will probably not be effective. And you'll probably be right that we are not expecting for people to just use it automatically. But we are treating this tool itself with the same framework that we propose for apps. So, we try to understand the needs of the various teams of engineers, clients, leaders involved in those projects. We test it with users and improve. So, this sheet that you are seeing today is actually the third iteration. And hopefully, there will be more iterations after that.
So, and like we are using it also like talking about this tool. It's also a form of education. So, of course, we don't expect people to just understand and do everything perfectly themselves. Rather, we work with them like in a let's say interactive way. So, with that in mind, like we had in the past few months, we had nine practice applications of this approach. And here are some benefits that popped up again and again.
So, one benefit is that this kind of approach helps us identify problems that can lead to bad user experience that we might otherwise miss. It helps you like zoom out, look at the broader context, but also go through in a systematic way through various things that even if you are an experienced developer, even if you are an experienced designer, you might not think about every time. So, it's like a checklist for that. Second thing is it can help find low hanging fruit. So, sometimes like it takes the same effort to do it well compared to doing it poorly. If only we know what we should do. So, it can if we do this evaluation early in the planning phase or evaluate an early prototype, we can find things that we can just automatically do better without additional investment.
And number three, and maybe most importantly, it helps improve the quality of conversations that we have around design within the team and with clients to create a shared understanding of what we mean by various things like great design, like usefulness, and so on. And it also helps people to just learn about the topic if they're interested in it.
And number three, and maybe most importantly, it helps improve the quality of conversations that we have around design within the team and with clients to create a shared understanding of what we mean by various things like great design, like usefulness, and so on.
Summary and Q&A
So, to summarize how to make apps users love, well, first of all, think about more than just beauty. Number one, usefulness. Number two, usability. Making it easy to use. And finally, beautiful. And it helps to talk about it, to plan it, to be deliberate about this planning. And finally, to evaluate your progress so you can do it better next time. And most of all, just care about it. So, if you care about it, you can download the slides from this QR code and this link, go.appsion.com. And you can talk to me at the booth, although the booth is disappearing soon, I hear. But you can find me in the hallway, and if not, you can find me online. Yeah. So, thank you.
Thank you. So, I'm peeking at Slido for the questions. And one of them is how do you avoid overengineering apps? That's a problem. But one way is to do like we do that we think about usefulness. So, that automatically focuses our attention. Like what do we need to achieve this purpose? And then we do user testing and with early prototypes, which also shows like are we on the right track or not? And we do it in short iterations closely with the client. So, maybe it happens sometimes. But that's how we reduce this risk.
The other question we have is can you talk about getting buy-in from clients or users around design decisions? I guess, you know, that's going there. So, we frame the conversation about like what are we trying to achieve? Adoption and impact. So, if some design decision can be viewed in this light, then it will be easy to convince people. Like if they believe that we are actually addressing what they really want, then it will be easier to convince. It's not just design for design's sake. Thank you.