20: App Development Lifecycle Series - Design

In Part 2 of our App Development Lifecycle Series, Tim breaks down the Design phase. Design is not only how your app looks, but also how it works. In this episode, we share how we work with our clients to design a valuable and easy-to-use mobile app experience for their users.

In this episode, you will learn:

• What is design, and why it’s not just what the app looks like
• Four principles we use at The Jed Mahonis Group to make well designed apps
• How we use constructive criticism to make better-designed apps

This episode is brought to you by The Jed Mahonis Group, who builds mobile software solutions for the on-demand economy. Learn more at https://jmg.mn.

Recorded January 17, 2019 | Edited by Jordan Daoust

Show Notes

Episode Transcript:

Welcome to Constant Variables, a podcast where we take a non-technical look at mobile app development. I'm Tim Bornholdt. Let's get nerdy.

Today on the show, we are continuing our mini series on the app development lifecycle with the second phase, design. So in the previous phase, the strategy phase, we held a strategy session, we drew up some wireframes, we established our user stories, and we got our team in place. So by the end of the design phase, we will have an asset catalog, which contains all the images, colors, fonts, layouts, all the things that you would think of when you think of design that our developers can take and turn into a functioning app.

So first off, what is design? Well, I think when most people think of design, they think of what you see on the screen, the pretty pictures, the colors, the way things are formatted and laid out. And that is part of it. That's about half of it. That's what we call user interface or UI. The other half that people don't think about so often, but is just as important as UI, is UX, which is user experience. It really takes both of those concepts, UI and UX, to pull off a well polished, and well designed app.

So when we are going through design here at JMG, we adhere to a few core design principles. And when we follow these principles, we think it leads to a better design experience for the user, which again, UI and UX. The key word in both of those is user. So I want to go over just four principles that we consider here when we're designing apps and see how, you know, that can apply to your app.

So first of all, one of our core design principles is we want to make the user look like a rockstar, so I don't really like, I want to find a better way to phrase this, but I can't think of one. Because I really don't like when people say like, "Oh, we need a ninja coder, or we need a rockstar developer." It's all, you know, kind of just B.S. fluff. But I think in this case, what we're really trying to get after here is that people don't use apps, really, in a business context unless they have to. And generally speaking, I think most people have, for the most part, when you use software, you don't really get to choose what software you're using. And pretty frequently, the software that you do use doesn't really do what you need it to do. So what we really strive to do when we design apps is we want to make it so that people use the app. And it makes them feel like they're actually getting their job done. And it's seamless, and it makes them feel like they're able to go to their boss and say, "Look what I did," and they can show the app as part of enhancing what they're doing. At the end of the day, people aren't app users. They're, you know, plumbers or they're managers or they have other job titles. They're not just trying to use your app. So when we design apps, we do it in such a way that it gets the user to look like a rockstar in whatever profession that they're in.

The second core design principle is, we really try to take what we call the Super Mario Brothers approach with design. So I'm sure most of you have played the original Super Mario Brothers for Nintendo. But if you haven't, the way that the game is designed, it's very fascinating from my point of view and from how we design things. So when you start the game, you turn the power on to the Nintendo, and you're presented with one option. You basically say one player or two. Once you say, one, you're dropped right into this world that says World 1-1 and just your character is all of a sudden just in this world. And it's up to you to kind of figure out what the next step is. So the way that the first screen is laid out, you kind of get the feeling, you know, maybe I should move to the right. So you start moving to the right and you realize oh, the game scrolls to the right. I should you know, we're gonna be moving this direction this whole time. And then you see these little characters walking around on the ground and you think oh, I wonder if I can go up and give them a hug and you go up and touch them and the your player dies and you go Oh, I guess I can't do that. So you learn, Hmm, I wonder how I get rid of these guys and you kind of jump and you jump on top of them and you see these little boxes that you can jump up and you know, they make it look like you should punch these little question mark things and see what happens and, Oh, I got coins that seems to be a good thing.

The point of all of this is that if Mario Brothers was designed that you turn, you hit the power button, and it had this massive splash screen that says Welcome to Super Mario Brothers. Let's get started with the tutorial and you have to sit there and it explains, Okay, the game goes from left to right and press A to jump and you can jump on Goombas and don't touch the the little guys that spit fire out at you out of the water pipes. If it went through and did that, it would be a pretty poorly designed game. What makes Super Mario Brothers such a great example of how well designed things can be designed is that they basically give you what you need to know right when you need to know it. And then as you progress through the game, you learn new tricks, you learn new tips, you learn ways that you can navigate through this world that weren't apparent right when you started and that's what makes it so much fun is world 1.1 is it's pretty straightforward. You know, you get through and you learn, Okay, here's how I jump, here's how I move, here's how I power up and the point of it is to collect coins and get to the end. If it went right away into Alright, go fight the final boss, go fight Bowser at the very end, that would not be a very fun game. And it would discourage users from continuing to use it.

So in that vein, as it relates to mobile app development, we want to design things so that when you get dropped into this world of an app, you should be dropped in and kind of know what to do already. You should kind of get a feel as you're using the app, the app kind of guides you at the beginning. So you get what you need done, done. And then as you continue to power up, so to speak through the app, you're learning new tips and tricks in order to get better and perform even faster and to unlock new features of the app, you know, metaphorically speaking. So that's the second core design principle is we really try to design as if it's super mario brothers inspired wherever possible.

The third core design principle I want to cover is follow industry standards. So you know, some development shops, maybe they are cutting edge and try to invent the new paradigms and things like that. From what we've seen with our customers and our clients is people don't want to reinvent the wheel. Most of the time, people just know they need to get their job done. And so we should use whatever tools are at our disposal. I'm very fond of saying, you know, standing on the shoulders of giants, there's all this body of work that's been done already by people that are way smarter with user testing and usability and all that kind of stuff. So why don't we just take what they've done and make tweaks where we need to.

So first of all, follow the industry standards. It's very great because Apple and Google both have design, basically, frameworks, languages that we can look at to make sure that we're following whether you're on iOS or Android, you're following industry standards. So on Apple, they have the human interface guidelines, better known as the HIG. And on Google, on Android, they have material design. And there's a ton of advantages to following both of these design languages. So first of all, when you're using the HIG, and you're using material design, you're using design languages that users are familiar with. So most Android apps, for example, if you're using like a tab bar layout, the tab bar is kind of towards the top of the screen where on iOS, it's towards the bottom. Those are things that people are comfortable with; they understand that, I see a list of things, you know, I can scroll that up and down, that's a table view. Using these languages and not reinventing the wheel, it's kind of baked in and your users can kind of use that Super Mario Brothers inspired design just right out of the box. Also, the other thing is, like I said before, both the HIG and material design are incredibly well researched, well received and people have implemented these, you know, people get what they're doing when they make these design documents.

For example, on iOS when the HIG was first released with the very first SDK, it's fascinating. If you go and read through these, there's things like buttons on iOS, they recommend a minimum height of 44 pixels, so 44 pixels tall, 44 pixels wide. And the reason for that is because the human fingertip on average is about that many pixels wide and deep. So tapping on an item is a lot easier if it's at least 44 pixels wide. That's why you can only fit so much on a screen, it's because your fingers are so big. So there's little tips and tricks that are in these documents where it's just like, I would have never sat and done the research and thought of that, but other people have, so why don't we use it.

The other third advantage of using the HIG or material design is that following these industry standards often have advantages going down the road. Adhering to the platform always gives you advantages than trying to battle it. There's two examples of this, one, on iOS when they switched from iOS six to iOS seven, if you recall, before in iOS six and earlier, it was what they called skeuomorphic, where it was like a button actually looked like a physical button in the real world. They had like the Game Center app, for example, it looked like a card table where it was green-felt looking and the woodgrain around the table and stuff. Everything had a very realistic comparison to something in the real world where as soon as they switch to iOS seven, everything went away. It was all flat design, just black and white, basic lines, just incredibly clean and simple and way easier than skeuomorphism. And if you were following the designs, and you were using the tools that Apple had built in, if you were already using those established frameworks, you could just right in and your app, if you recompile that and submitted it to the App Store, your app already inherited all these things. So that's one example.

The second example is that with accessibility, things like table views and buttons, if you're using industry defined buttons and things like that, you are unlocking way more in terms of the ability to compensate for accessibility. So things like screen readers and other things that people that have those different needs need. You don't have to reinvent the wheel with helping those people out, you know, you can come in and make sure that it's designed for those individuals as well. But for the most part, you're able to just jump right in, and you get 80% of the way there by just following what the industry does.

So, design principle number three, follow the industry standards. But design principle number four is know where to deviate. And again, as we said before, user interface, user experience, it's all about the users. So the way that you learn how to deviate is use, again, stand on the shoulders of giants. Use these tools that have been built up over a decade now and get so far, but then consult your users and see, does it make more sense to have a bigger button than normal here because our users have big hands, or that's kind of a weird example. But you see where I'm going with it is, talk to your users, figure out how your design could differ so that you're helping them be able to ultimately be rock stars.

So we've made it through all of the design principles. So we're in the design phase. How does this process look? So again, we've exited the strategy session with a bunch of user stories and wireframes. So what we do now is we hand off those user stories and wireframes to our designers. And what they do is they create the UI and the UX mock ups. And typically, they use tools like Sketch and Photoshop to create the interface. And then they use a prototyping tool. And Sketch has one built in but a lot of people use Envision, and there's a bunch of other prototyping tools. It's really whatever our designers are comfortable with. And they'll mock up the user experience. So you can actually click through and go from screen to screen to screen and see how the flow of the app feels without actually having to code anything.

Once the designer has created these mock ups, they then sit down with our developers and they get feedback. I want to make a point about feedback before we jump further down the road, so again, with anything in life, constructive feedback is so important. It's not enough to just say, I don't like this design. That's super unhelpful; it doesn't really accomplish anything, and it just makes people feel bad. So what we strive to do is give constructive feedback. And there's a few points that we follow when we're doing that, first of all, criticize the design, not the designer. So when you're making critiques, by saying, I really don't get why you would have chosen not to put whitespace there. You know, you're attacking the designer, not the design, instead of saying, I don't understand, can you explain to me your reasoning for not putting in whitespace? Or what do you think about putting whitespace in at this spot? You can phrase things so that you're criticizing the work and not the employee.

Second is, we want to give a feedback that's both reinforcing feedback and redirecting feedback. So reinforcing feedback is encouraging people to keep doing something that you want them to keep doing. And redirecting feedback is telling them to stop doing x and start doing y. So again, like I was saying earlier, we're offering an alternative. As you're giving feedback, you're giving an alternative to something that they did, as opposed to just saying this stinks and saying this stinks, here's how I would do it better, in more polite terms.

So with that in mind of how to give constructive feedback, here's the big things that our developers are looking for when they're critiquing the design. They're looking for features that could take a while to implement. So a lot of times in development, if you're handed a design, you might be handed a design that if you would make just a couple of tweaks here or there and, you know, move this part of the flow a little bit later, or, you know, something like that, you could make the project easier and faster to implement. So those kinds of wins are what we're looking for at this point. And also, the developers are looking for deviations from the HIG and from material design, and they're questioning you know, why are you deviating from the HIG? And we're really looking for the developers to buy into that. Because, you know, quite often, like I said before earlier in this episode, where if we deviate from it, we want to do it because the users are requesting it, more or less. And so if that's the case, we want our developers to know the actual reason for implementing something. So then when they're actually going down the road and making a lot of little small, detailed decisions, they're able to understand the reasoning for it.

So again, that's really the two things that our developers are looking for. And designers from their part, so once they've received criticism from the developers, they're encouraged to ask as much questions as they can to basically understand why they're getting pushback on certain aspects of the design. After the designer has implemented that developer feedback, that designer then will take it to the project manager. Now the project may, again, following the constructive criticism that we outlined earlier, the big things that they're looking for are, one is the all the user stories being met with the design in front of them, and two, will the end user be able to understand how to use the app that's in front of them. So they're really looking, instead of getting into the nitty gritty, which our developers are doing, they're looking more big picture and making sure that we're hitting everybody's goals with whatever software we're building.

So after we implement the project manager's feedback, we now put it in the hands of the client, and we get feedback from them. So again, following the same constructive criticism guidelines, the big things that the client is going to be looking for would be, does this match the vision? You know, everybody that is a project manager and owner has a vision for where it needs to go. So does this design match that vision? And also does this meet all the user stories? Ultimately, what we're trying to avoid here is we don't want to get down the road where you say, Oh, the design should have had this feature in it. If we're all clear on what those user stories are, and our designer has checked the box next to every single user story, then in theory, we've hit all of them. But we want to make sure that the client agrees that we're hitting all those user stories. Usually, I should have probably said this earlier, but after all of these, there's, you know, implementing the feedback and getting more feedback if things need to be tweaked, or whatever. But at this point, let's assume that the client has okayed everything.

So now we create a final version of the designs, and we get written confirmation from the client that we're good to go. Once we've gotten written confirmation that this final version is it, the designer can then generate the asset catalog. So what this entails, again, is a clickable prototype of being able to go from screen to screen to screen to see how the flow of the app should work. We also want to create a static PDF version of the designs so that we can all look at something later on down the road. We have to have a holistic view of what it should look like, the fonts, the colors, the images, everything that we would need as developers to go in and implement the layout that was provided by the designer. And that's it.

So coming out of the design phase, we now have an asset catalog that we can give to our development team. And we are now ready to enter the development phase, which will be our next episode. I would love to hear what you guys think of this miniseries. If you have any questions or comments or any anything I can help with, please don't hesitate to reach out. You can get in touch with us by emailing Hello@constantvariables.co. I'm @TimBornholdt on Twitter and the show is @CV_podcast.

Show N=notes for this episode can be found at constantvariables.co. Today's episode was edited by the laudable Jordan Daoust. This episode was brought to you by The Jed Mahonis Group who builds mobile software solutions for the ondemand economy. Learn more at JMG.mn.