Mobile App Development Cost and Design

By John Houghton on January 28, 2014

Two of the toughest issues for mobile app development company stakeholders are cost and design.  On the iOS platform (iPhone/iPad), particular attention is paid to design, and Android also has its own design language; however, the navigation patterns can be quite different between the two platforms.  In this video episode of Mobile App Development TV, we talk to Pete Petras, who is the US Creative Director for Globant.  Globant is a technology service provider focused on developing compelling experiences with particular expertise in mobile app development.  Pete talks about the cost incurred when companies undertake development projects, and how user experience is becoming a driving factor in app success.  Watch the video now:

Watch MP4 (iPhone/iPad)

People are figuring out that mobile is a different platform which requires more of a user-focused product definition with an impeccable focus on detail.  According to Pete, “It ultimately does what design should do, it’s invisible in a way, especially when you’re talking about an iPhone.  When you look at the iPhone, all eyes are on the interface.”  I’ve heard it said at Apple before, that good design is invisible, and I don’t think a lot of people understand how much work it takes to come up with a design that is exceptional.  When you see it, it looks so simple.

I think design and user experience are the missing factors in many apps, and achieving excellence here takes time and revision.  Usually when I’m working on a design, the client likes the first draft and doesn’t want to pay for revisions, but I think this is short-sighted if you’re goal is to design the killer app.  You arrive at the first design, and then deconstruct it, to see what the user is really trying to do with your app.  Then you incorporate the new lessons in your redesign.

Just yesterday, there was a post in The Wall Street Journal blog, asking Why Aren’t App Designers as Famous as Chefs? John Maeda, the new design partner at Kleiner Perkins Caufield and Byers says, “We’ve hit this plateau where technology alone is not enough to sell a product.  So what is it that we need to make us want something?  It’s about the design.”  Design is something that should be thought of first, and it should be started early in the development project.  You can find out more about Pete’s design tastes on his Pinterest Board.

MobileCast Media offers app design and development services.  Please contact us for more information.

Transcript

John: Welcome To Mobile App Development TV, I’m your host John Houghton and today we’re talking about mobile app development cost and design. We’re joined in the studio by Pete Petras. Pete is a US Creative Director for Globant. Globant is a technology service provider that focuses on developing compelling experiences and they have particular expertise in mobile.

How are you doing Pete?

Pete: I’m doing well, thanks John.

John: What does it cost to design and develop a mobile app?

Pete: One billion dollars.

John: One billion, not a million?

Pete: No I guess in this market it’s a billion dollars, right that the bar. No, that all depends on the length of the project, it all depends on the complexity of the app and ultimately whatever the cost is that you figure out that it will actually take to develop. You can do an analysis and say, “hey we have x amount of people that costs us x amount of time and we predicted that this takes six months or nine months to develop and there for that’s our budget or that’s what it’s going to cost us. I would say times that by two, maybe by three. Because nothing ever goes the way you think it will go and a month into it you’re going to have to grow the team by two maybe even by three and then who knows. You’ll have other costs that you’ll have to take into consideration, licensing, who knows, there are all sorts of elements that are always unforeseen and it will defiantly cost always more than you really think it will.

John: So this is typical software development you might say with the added element that people haven’t done this type of thing before.

Pete: Yeah, I mean it is your standard software development. I think the real shift from being a standard software development is really a focus on user experience. I think with Apple and a lot of the start-ups, the Square, the Instagram etcetera, these rich experiences that have really set the bar for what users expect. On top of that paired with the adoption of smart phones has made this a different platform and a different focus to really spend your attention on. Otherwise those problems are still the same. I think the teams are structured a little differently now, the approach is different and I think it’s for better. I think a lot of this has a trickle down or a trickle back effect to other software development aspects. So the ability to understand your users to have a user focused product definition is defiantly a thing that isn’t just unique to mobile development it’s something that goes beyond that to all sorts of different products that we all use or will develop for.

John: So I think of everybody following Steve Jobs in this industry and him pushing towards the idea of having a delightful user experience and delighting the user- and those are the words he used and then he was able to push his whole company in that direction.

Pete: Yeah, so Apple’s a unique case. Apple did a very interesting thing, it’s basically Dieter Rams 2.0 if you will and it’s not to demean anyone within Apple by any means. It’s something I love. I think that the hardware the I.D. is beautiful, it’s simplistic. The attention to detail is impeccable.

John: For those that don’t know what is Dieter Rams 2.0?

Pete: So Dieter Rams was the Chief Creative Director for Braun and he designed this very simplistic design language and its been resurrected by Jony Ives at Apple and expanded onto the digital products and it has a very similar parallel design principal involved. A lot of it is just simplicity core of the function and ultimately what it does really well not just the details of it. It ultimately does what design should do, it’s invisible in a way, especially when you’re talking about an iPhone. When you look at the iPhone all eyes are on the interface. The iPhone itself is just a frame and it’s such a beautiful frame, it’s an amazing frame that they’ve created this created this element of luxury because of the quality aspect of this. So now with iOS7 you have this, finally you have this unification of Apple’s digital offering you have this hardware product that was actually unified you had this design language came along but as iPhone was first introduced all the different digital properties within the iPhone stated drifting apart. You have a lot of the skeuomorphic stuff, you had the app store you have all different departments.

John: What’s skeuomorphic?

Pete: Skeuomorphic is basically something that is pretending to be something that it’s not. A fake leather interface or fake wood or taking on the look and feel of other objects.

John: Sort of a metaphor for physical objects.

Pete: Yeah.

John: And it kind of all went away with iOS7.

Pete: So what iOS7 did whether people like it or not it unified all the Apple elements of the interface. So any of the actual iOS touch points where all unified under iOS7, which is great because it finally brought it together. Now they took a step beyond and actually went away some of the best practices within user interface design guidelines or UX design principles and took buttons out of where buttons usually where and just relied on the actual titles and really made things simple. And I mean they did this to follow along with what they’ve done with the hardware product right. So they took a big step into designing something that was really premium made it very expensive yet desirable, obviously we’ve seen this work. They’re very successful at it. They’re doing the same thing with the interface, they’re unifying it but they are also taking a step of making it very simple and also just focusing it on a particular client. Now those design principals that they followed or that they didn’t follow aren’t great. They didn’t do the things that they needed to do to make things perfect but then again they’re not designing the beige box, right? So they went way from designing beige towers, beige computers, they’re also not designing a beige user interface. So they’re taking that stance and shifting a little bit towards the apple side of things.

John: Well Pete its been great having you on the show thanks so much for being here.

Pete: Thanks John, I appreciate being here it’s great to see all the content that you’ve been producing and I’d love to see more.

Extended Transcript

John: Designing a mobile app is a daunting task, where do you start?

Pete: So, starting to design an app, I would say the first thing you have to do is to identify and understand who your users are. Identifying and understanding the broad aspect of your user base is important but you’re never going to design an app that solves a problem for every single person. So really a first good part to start with is to understand the extreme parts of who your user base might be, understanding what is on the furthest right or left side of your user base but really picking one particular audience member and designing for one person.

John: Maybe someone that more towards the center? Or would that be out in the ends?

Pete: Understanding the extremes is important.  It’s important to understand what those niche elements might be but really identifying one particular person and using them as a case and a target.  That is probably most valuable. You’re never going to be kind of the do all for everyone.

John: So does that involve making user personas?

Pete: User personas are great. They’re really great for understanding and identifying task flows that you might actually incorporate in different parts of a more complex app but if it’s something that’s simple and something that’s straight forward you really want to make sure that you have a clear goal and a clear target. What will usually happen is if you identify and design towards one particular goal or person or user the rest of the users will actually fold in and follow along. They’re a lot more flexible than having an app that will try to do everything else because then you won’t do anything really well. If you do one thing really well, everyone will actually fold into that.

John: That makes sense. One thing I find that user personas do is they help people focus and simplify. Typically when people design apps they’re too complex. Do you find that personas help people define, like having a single purpose for the effort or focusing on a single function.

Pete: Yeah, it’s not necessarily around simplification I think but it’s around being a little bit more contextual. You can actually craft a story or craft a look or understanding how someone, a figurative person you might have developed or a persona that might be done by certain metrics that you have identified. It might be that you craft a particular use case around this person.  Now those won’t always be right, they’re sort of a shot in the dark. Again it comes back to really identifying that one and going after that one. Identifying multiples is just a good place to say ‘ok is the interface or is the product actually flexible enough to accommodate these different personas and then in which case you actually go down these multiple paths and understand have we actually we actually covered all the bases. Now again, when defining an app from the very beginning you might want to really narrow that down and focus on what those aspects are rather that start to build it out immediately. A lot of those are also really valuable to take into consideration once you’re actually taking and evolving that app later on.

John: I notice that a lot of people try to cram too much into the initial release when there’s really a concept of the minimum viable product. Do you ever use that in your app designs?

Pete: Absolutely, this is all about focus. I think it’s the kitchen sink syndrome right? It’s the misguided desire to throw every single feature set into an app, wanting to define or develop all these great ideas that you’ve might have come up with in the very beginning of the concept phase. It’s really important again to come back and just focus on ‘what does this do’ what is that minimum viable. It’s not just minimum viable in a sense of development of what you can actually get out there in the users hands, but ultimately what the focus of what the app is actually intending to do rather than all the little tiny features that you’ve actually thought about along the way.

John: Kind of like having a business and saying, “what business are we in? What’s the core of what we’re doing?”

Pete: Yeah, you can be a coffee shop and you need to know how to make coffee, right? Coffee is your core product you can slowly start introducing pastries but if you don’t do coffee well you’re never going to be a good coffee shop.

John: What the most important best practice to keep in mind when designing a mobile app?

Pete: I always come back to the K.I.S.S. metaphor, the keep it simple stupid way of looking at things. The simplest approach is always the best but I would say I think one of the core elements is really content, understanding your content. Starting from content and understanding the context in which that content can play. I think driving toward what you’re actually defining as a product and then figuring out how that applies to the design is really important.

John: So content is pretty wide, can you give me an example or focus in a little bit of what that would mean?

Pete: Content could be if you’re a photo app you really need to focus on the content of the imagery of the photography the ability to share the actual photography or the imagery that you’re doing. If you’re focused on travel, is that something that’s around geolocation and the content that’s related to that particular element. I think understanding that content what’s relevant in particular the context of what you’re doing. With mobile you have all these different attributes that you can really utilize to a better experience such as the geolocation and/or the accelerometers or what have you and some of those elements can cloud the experience or they can enhance it depends on that content and how you actually apply it.

John: So contexts is obviously thinking about where the user might be when they’re viewing the content say it’s a geolocation photo app, say for example for Google Maps, the designer really has to think about how those two intersect.

Pete: Yes, it is location, it is also time-based. It might be during your commute, during your work hours, is it weekend, is it evenings, during day, are you traveling, are you near your house. All these things are relative to a really good experience. Especially when you’re dealing with more complex experiences like e-commerce, right? There are a lot of elements around context that people start doing a lot of research during certain times whereas they do the actual purchases at different times as well and that also is location based. Usually purchases will happen at home versus on the go. A lot of these are security issues. So understanding these behaviors that are actually in the real world and how they apply to the digital world is really important.

John: Are there any design guidelines that you live by? For example, when you have a new customer are there certain guidelines that you have to make them aware of?

Pete: So design guidelines, there are a number of just basic elements basic principles, and some of those are guidelines you start with. Those are guidelines that you continue to keep throughout the process. Guidelines that you begin with are ultimately you have to understand the brand as an extension of the brand or what is the brand trying to evoke. There are a number of elements of the brand extension that can be visual but they can also be emotional, visceral.  You can extend them through transitions or any of these other elements. Now once you extend that throughout a product consistently, it is a key aspect of keeping a strong design guidelines that will make sure that if you’re doing certain actions or if you’re even including fonts or buttons or whatever these things are, that they are very consistent throughout the whole entire experience.

John: You’ve probably seen a lot of apps. Any big mistakes that you have seen? People make and maybe not with your own customers just out in the market place in general?

Pete: I think the big mistakes that are made out there is one thing we mentioned the ‘kitchen sink syndrome,’ trying to do too many things at once. If you don’t have a clear focus or a clear understanding what the app actually does then it becomes really irrelevant for a user. If it’s overly complex that becomes something that you’ll have people just say “alright, I don’t know how to use this thing so why would I continue to use it?” Ultimately the one thing that also I think is a big downfall is if there is a previous web experience or web product that has a direct translation to mobile and that’s not always appropriate. I believe that if you have an application or a service or product that you’re trying to extend to mobile you have to really take into consideration of redefining that product from scratch for a mobile specific audience and a mobile specific platform simply because there are so many different elements such as the contextual touch points that play in effect. As well you’re not doing your typical mouse click interactions; you’re doing swipes or touches. All these things are very different from translating one to another. If they’re not done correctly I think that’s one of the biggest mistakes you might see out there.

John: Any examples of major platforms? I can think of Amazon and Facebook having both a mobile platform and mobile app and also having a web app.

Pete: Yeah I think a lot of them are starting to get better now. I think those examples were pretty easy to identify maybe even a year ago. But now you’re starting to see a lot of the players really, really get this. Amazon was one of them that was terrible until recently were they started really getting their app out there. Same with eBay in the very early days I think now they have a great robust experience not only on mobile web but they have a mobile app and they have the tablet experience. So they’re really pushing for that and they understand the value of the different experiences there. As for bad ones, again I’m at a loss right now.

John: Can you think of what specifically made those two platforms, Amazon and Ebay sort of lacking on the mobile app side?

Pete: In the beginning?

John: Yeah.

Pete: Actually that’s a head scratcher, maybe it’s because a lot of the task at the very beginning of their development cycle was actually run strictly by the numbers, by the analytics and all analytics basically showed them that a lot of the traffic was driven by the web but as smart phones grew in adoption, as the users have actually been doing a lot of online transactions or m-commerce came to its maturity as its coming now, has come to a foresight. They understand that this is something that if they don’t do it well now they’re going to really lose out on that audience.

John: So a lot of people know what a user what user interface design is, but what is user experience and how does that relate to user interface?

Pete: User interface or UI as they call it, UX for user experience, are too separate but very independent elements of a design process- development process. The way that I typically define it within my practice, and these terms kind of get switched around in different ways. The way that I like to explain it is on the UI side of things it literally means user interface but it’s actually the development or the creation of the user interface. Now when I say creation that’s where a lot of people get a little bit hung up.

John: Is that with graphic designers and people like that?

Pete: The way that I actually comprise a team is we typically have a visual designer, a UX designer and then a UI designer or UI developer. Now on the UI side you’ll technically have a background that’s a little bit more technical. A little bit more focused on the design language but also with a keen sense or a tendency to understand things such as motion design an understudying of basic UX which I’ll get to, the UX principles and then just a keen sense for good visual design. Ultimately they’re the ones that are putting everything together and they’re the ones that are being able to translate what’s actually been designed to the code and onto the actual application. Now with user experience, user experience actually has a number of different things they’re responsible for and it stems all the way from general research, understanding and defining the users or as we mentioned user personas earlier to define mainly how that product might steer itself to a particular use case. Also understanding base principles around navigation and how to organize content on a screen and all the way up to what we also like to say information architecture, IA, basically the overall broader structure of the system. So a site map if you will at a high level. Really where do these pages live next to each other in association with each other, how do you actually navigate from one point to another and are there interdependencies within the whole app that actually tie from one end to another.

John: So if you wanted to increase the conversions in your app, that would be the UX person’s responsibility?

Pete: It would be partly the UX person’s responsibility. Conversion within an app…

John: We should probably define that too.

Pete: Yeah, conversion within an app can be defined in a number of different ways depending on what you’re trying to actually measure. Are you trying to get adoption, just general adoption? Are you trying to steer people down a particular path? Are you trying just to understand why users are going down a certain path? So those things can all be done with analytics. It can be done with being able to measure certain metrics, just basic traffic and the ability to actually work in a flexible way where you can actually do certain things on an app or set things up where you can turn things on and off to actually guide users down one path or another is also an important part of that and understanding that and really taking that information and being able to do something with that.

John: Would you say that the user experience person’s more responsible for the overall look and feel and flow of the app and the UI is more the element level?

Pete: Not necessarily the look and feel but quite possibly the flow or the interaction. So within user experience there again are a number of different elements, one is the insight aspect, where you are perhaps taking on the role of understanding or sitting or standing in the users shoes basically the empathy aspect of it. There’s the research part, understanding what are the different pieces of content or information or even what are the insights that the users actually do. And then there’s the application of how do we actually structure this information that we’ve gathered. How do we structure that content in a useable manner? And is there that actual element that translates a bit of that brand to that interface? Now the look and feel is actually where we have that visual designer working closely with the UX designer, not only understanding how this will be structured but how do you translate that look and feel and ultimately now that we see a lot of these really rich transitions how do we take that and create a brand out of it or extend that brand and make that into a real unique experience that stays with the user and actually becomes a brand element of the application for the product.

John: I find with transitions the Apple human interface guidelines kind of speaks a little bit against it but I think they can really enhance the brand experience. How do you feel about that?

Pete: So the Apple guidelines are a really interesting topic. I think in general they have these guidelines to basically give apps a direction to go down. Basically a general element of ‘this is what you should or shouldn’t do.’ They will not allow you on the app store if you break some of those elements but challenging those or creating a creative element or a workaround isn’t necessarily something that breaks it, it’s something that will actually be a new way of inventing perhaps a different way to showcase or transition or even navigate through an app. So that not necessarily a bad thing the bad thing becomes, ‘is the purpose of the app discoverability is it exploring content? It’s really what are you trying to do with the app and are those transitions actually appropriate. If you’re actually meaning for someone to come through and explore and continuously keep clicking on content further and further such as a YouTube or Pinterest type application then maybe the actual navigation or interactions or transitions might be a little more complex or a little more creative. Whereas if you’re trying to get the user to do one simple specific task then you want to probably shy away from complex or creative transitions and focus on something that happens very simply and in a straight forward manner.

John: That makes sense. So what do you think and how do you work when you’re giving a developer or coder documents, what are your documents deliverables so that they can begin coding and programming?

Pete: So this is part of the design process and what you’re talking about is your traditional kind of waterfall approach, it’s handing over documentation. I feel that a lot of documentation now becomes a little bit irrelevant and in fact not necessary. Now when you structure or you define a product and you actually start designing and defining that product a developer should be part of that process from the very first kick-off meeting. They should be part of defining what it is that you’re building and part of the design actually, the way that you’re reviewing and going through the different ideas and concepts that you’re creating. Without their insight you actually might be creating something that might not be possible to be developed. So their insight is not only something that’s very key but ultimately the ideas that come out of developers especially the developers that we have now are very creative in fact sometimes even more creative than “Creatives.”  So I think that this handing off a document to a developer is kind of a thing of the past and you start seeing this.  Agile has been something that’s been part of the development process for years but that is actually starting to shift into design now where you’re starting to be iterative and inclusive of the process as you go and especially with the actual design and development that is paired programming. So you have like a paired design/development process.

John: What’s the name of the process where you put the developers and the designers together?

Pete: I don’t know if there’s an official name for it but I’d like to basically say it’s a design/development process, kind of like a paired programming if you will. Having the ability of having a designer and a developers working side by side maybe not exactly in parallel but together while each one has their particular tasks and actually solves the problems while they’re going through the actual tasks is really valuable and it becomes something that creates a better more robust product in the end.

John: What would you say to people that are going out to O-desk and freelancer and places like that, and they are trying to develop a product and typically what sometimes happens is when you throw something off shore you get it back it’s nothing like what you expected and so sometimes in those cases where you haven’t worked with a development team before a little bit more documentation is better, what type of documents would you be writing in that case? Would you use wireframes, PRD’s, functional specifications, or would you have lots of conversations and video conferences or do you check their code every day?

Pete: So that type of work becomes very difficult and the only way I’ve seen this work successfully is basically daily scrums in a very Agile way of working and in fact overseas, I work with teams overseas quite a bit and we will be on hours long video conferences where we are literally working next to each other, talking through some of these ideas, having a clear understanding. The worst thing you can do is have this sort of ‘here’s a cookie recipe’ and you get back biscuits right it’s this lost in translation.  Your kind of right, you’re using sort of the same ingredients, you bake them but in the end it’s not the same thing. So making sure that you both have that alignment is very important.

John: For people who don’t know what a scrum is, you mentioned waterfall too it’s all part of Agile, maybe you can talk about that.

Pete: Waterfall approach was and is still kind of a traditional legacy agency model. It’s coming from a perspective of understanding a lot of this doing a lot of research, creating some beautiful design concepts, speaking with the client, understanding what the client wants etcetera. Taking that design language that you’ve established and extending it to a particular element that you’ve designed from a design platform point of view and then creating basically a brief, whether it’s a style guide or not. In the end some sort of documentation that basically says this is what it looks like here’s some of the spacing here’s how it should function and that could be really thick, it can be a paper document, digital document, what have you. But ultimately you take that and then you hand it off to whatever team is going to be developing it. You can see this in kind of this Gantt chart process where it is literally a step down, this is where this term waterfall comes from, it just trickles down. Now each time there’s this hand off from a team to a team to a team it’s kind of like playing telephone. You have something that kind of gets lost.

John: It gets distorted every time.

Pete: It gets distorted a little bit and so you get further and further away from what was originally intended by the original design team. Now with Agile, Agile was this process originally developed by Toyota I believe to help their manufacturing process on a factory platform on a factory floor. What this is, is basically you get the whole team together and you work in what they have, these daily check-ins. You understand what you’re actually developing towards you divide that into smaller, what they call stories or epics, which is a bunch of stories put together and you’re able to identify what do you think you can get done in a certain amount of time. You check in every single day on how you’re progressing. At the end of that particular said time frame that you’ve set up you see what you’ve gotten done and you figure out can you keep the same pace or can you go faster or slower and then you can accurately extend that out to however long that you need to get something done. Now what the value of that is, first off you have alignment, you always have the team on the same wavelength, they’re always talking they’re always working towards the same goal and they understand where they are. Even if the teams aren’t working exactly on the same parts of the project, maybe the design is ahead of development they still know what’s happening and are always abreast of what’s being developed.  They have the ability to see what’s being designed, see if the QA actually happening, is it actually syncing up exactly like it needs to.  (QA means quality assurance, meaning bug testing.)

John: Which is testing and making sure that it is all being delivered properly.

Pete: Exactly and then more importantly the other really valuable aspect of that is that when you do fail when you do find elements that don’t exactly go the way that you intended them to go, you don’t necessarily spend months and months of defining something only to understand that there are few things that don’t work at the end of this. Your investment at that point may be only a couple of weeks and you understand where it’s failed and you can easily change course or fix that or alter that without much impact.

John: So it could be a functional failure like the designer didn’t know that it’s illegal to sell other people’s music without getting the proper rights clearance. By doing these quick sprints and with this Agile development methodology you can figure some of these things out quicker and of course correct.

Pete: Correct, yeah the way that you structure an Agile team is different depending on if you have that team in-house or if you’re actually using that team to consult.

John: Lets have two different examples, one is a start-up example and one’s an in house big money, big team example. What would a team be made up of, in terms of people and skills?

Pete: So if we’re specifically designing mobile apps and we want to basically create an Agile mobile start up team, you would definitely have somebody that can have the project management hat or the product management hat in a way. They have the ability to make sure that team is always on track. It’s very easy for individuals to get really focused on what they’re doing and forget that there is this bigger goal and they need to go down this path. So Agile really requires someone to be this person sometimes they are called scrum masters or product managers or what have you. Ultimately you need someone to be able to actually manage that and be accountable for the team’s progress. Next you obviously need if you’re designing for the iPhone you’re going to need a developer that has an understanding of the technology and the platform and the differences between iOS7, iOS6 and obviously 5 which is kind of a departure.

John: And then at least a couple years of experience in Objective C.

Pete: Objective C is the core aspect of developing for the iPhone yeah obviously and then you’re going to need basically a real strong UX individual. Now a visual designer I always say that it is core and you need someone there because if you want really good looking, high quality application, you’re obviously going to need a designer that has a keen sense for attention to detail and the design. Otherwise a lot of that work you might have a beautifully functioning app that may just not look very good.

John: Because the fit and finish is not there.

Pete: Fit and finish isn’t there. You definitely need a well balanced team to have a fully crafted site because ultimately something can work really well but if it doesn’t look good I think the consumer perception might not be there and ultimately adoption won’t be there.

John: Sometimes we see a lot of designers trying to walk into a mobile design role where they are trying to design an iPhone app and they don’t have much experience there. Do you find it that a person needs a certain amount of experience to be effective and quick in designing mobile apps?

Pete: Obviously yes, anytime you have an experience for anything you are going to be more efficient at it. You’re going to have the foresight and the knowledge of where to start, where are some the pitfalls, what to look for that has to do with basically any platform that you’re designing for. I think the jump from maybe a web designer to a mobile designer could happen pretty quickly, I mean you’re still designing on digital platforms. You need to understand what the platforms are. You need to understand some of the basic rules. Ultimately that first step I think would be a pretty easy stepping stone, it’s beyond that when you need to understand some of the really discreet elements that might happen between platforms. iOS is a little bit more easy to design for I think. You have the non-retina versus the retina as far as resolution goes. Then you basically have the iPhone 4 and 5 which are the same width just variable height. Then you have a mini and you have a regular iPad. Now designing for Android is a completely different story. You have tens of thousands of worldwide platforms that run Android.

John: Different sizes, different aspect ratios.

Pete: Everything, it’s literally a moving target. The way that you approach designing for that platform is completely different than you would for iOS6 or 7. A lot of it is because there just is that moving target. You can also choose your battles and say all right I’ll only design for the top thirty percent which is a lot more adoption maybe with the Nexus or some of the Samsung products and there might be only seven to twelve different platforms that you’re going to design for and you’re going to maybe say the other three thousand nine hundred and seventy two platforms will just be ok as for focus. It’s still a bigger challenge and the way you set some of the structure to your application will be very different.

John: Getting back to the teams and how you make up these the teams. You’d obviously have a project or a product manager. I think of the product manager more as the CEO of the product and the project manager are the ones that organize the project, I’m not sure if you see things the same way. Then you have the UX and UI people and then the developers and QA, is that how you’d structure it?

Pete: Yeah so, project manager is definitely the overall organization and structure. A product manager or product owner now that can be one person, it can be a CEO in a start-up or it could be what we’ve seen in a lot of teams actually the UX person ends up being not only the UX person but also the product owner or the product manager. Simply because the way that we focused on defining the product. Much of the products that we found to be compelling are actually from a user focused point of view, user tasked based versus feature based product definition. So based off of looking at those user first elements we’ve actually made the lead UX designer actually the product owner or the product manager. So they’ll usually manage a team of a couple other UX designers as well as oversee the entire product from the very first kick-off to the launch and understanding how UX is actually progressing, how development is actually then translating that experience on all the way to the QA and to launch.

John: Then how would that team change if the project was being done at a larger company?

Pete: So obviously at a larger company that would scale and you can have the affordance to have specific individuals for specific tasks and you wouldn’t necessarily need one person that might wear multiple hats. In a lean start-up mode you would have a lot of people wearing multiple hats. Some designers are UX individuals as well they do UX and design. So that could be one person as well. You have a CEO that is a CEO and a product owner, that’s great. The problem with CEOs typically as product owners is that they can never devote the time that a product owner needs to devote to a product and that’s where some of the processes really fail when you have a product owner that can’t be there one hundred percent of the time with the team. Too many changes happen too often especially in an Agile environment where things are shifting around very quickly and if that product owner isn’t there then the team isn’t effective.

John: So how long does it take to design a mobile app?

Pete: Ok, so this is a great question. I would say that you can design an app within a weekend. If you’re talking about a lean start-up way of designing a pure core app and an MVP within a really lean team you should be able to get together, get alignment, define it and do something within a weekend. Now in the real world that’s not always possible especial when you’re in-house and you have a lot more stakeholders involved in the decision making.

John: So each stakeholder adds, is it squared then it’s cubed? Just kidding.

Pete: It’s not really kidding, it’s probably true. You can almost square it.

John: If you get too many you can’t do anything at all.

Pete: Exactly right, internal alignment is a big issue that I deal with all the time. Just to get passed that, “what is the actual definition they want to go down, what is the actual app?” They have this grand gesture around ‘Ok we’re going to make this thing that changes our industry’. But ultimately what is that? “Well you’re the professional; you tell us what it does.” And we tell them and they’re like, “no we want it this way,” ok well you didn’t tell us you wanted it that way. It all depends on the stakeholders involved.

When you’re a small team and you’re doing a product from the very beginning and you’re able to identify what that core thing should be, really focusing on that simple task, identifying that user, that one person you’re going after and taking that first stand, drawing that line in the sand and saying, ‘Hey this is what we’ll do’. You can do it in a couple of days, why not? Then start growing from there start able to understand ‘is that right, did I make a mistake here, should I go a little to the left, to the right or do I keep going down the course that I decided to go down?’ That allows you to really do things quickly, iteratively and able to ultimately get to market quickly. Again you shouldn’t have this throw the kitchen sink frame of mind involved here. You don’t want to take on too much, do too much, stay focused, keep it simple, and really make sure that you’re all in alignment with moving forward. Now how long does it really take to design and develop an app?

John: Say maybe at a larger company.

Pete: Now the question is difficult to ask, because it all depends on the content, it all depends on where you are getting the content, if you have to create the content from scratch, if you’re actually requiring or relying on user generated content. All these elements will actually allow you to drive towards what that app actually could be and ultimately how long it will take to develop. It can take a couple months, it can take six to nine months, it all depends. It all depends on what the amount of work you actually have to do and really a lot of that is around the content itself.

John: So nine months just for the design?

Pete: No, not just for the design, I’m talking about for the whole thing built, design and development.

John: What’s the longest you’ve seen an app take? Maybe it never made it.

Pete: I’ve seen plenty of apps that have never made it. I’ve seen probably nine months to a year is probably the longest I’ve seen apps take. But I’ve heard of apps taking a lot longer. I’ve heard of apps taking a couple years.

John: What’s the biggest reason that you’ve seen for apps not making it?

Pete: Again, not having clear understanding of what an MVP is.

John: Minimum Viable Product.

Pete: Minimum Viable Product. Perhaps just being too feature-rich, trying to do everything at once. Not comfortable by launching with a small subset of what the product could potentially be but having to include everything. And a lot of this happens where you have to be very inclusive of different departments or different people that are involved that will ultimately use this. A lot of these will be internal tools typically than external tools for mobile but a lot of is just everybody just needs to be involved and wanting their content in there. Without that then it doesn’t move forward.

John: Must be hard to educate other internal departments that you don’t get a lot of time with and they want their own features and functions, but you can’t really educate them, ‘look there needs to be a Minimal Viable Product,’ it’s kind of like the Obama care website, trying to do too much at once.

Pete: Yeah that’s a good example I guess. There’s definitely a lot of that. I can’t emphasis enough of anytime you build any kind of product mobile app. It’s having clear focus, clear vision of what is the simplest way for you to have a starting point of moving forward and ultimately beyond that having a road map of how you can be really pragmatic about incorporating new features and rolling that out as different elements. Because if you are not comfortable with doing that it will take you a long time to actually get something out there in the hands of your users and that means it will take a long time for you to understand if what you did was correct because ultimately the user will tell you whether what you’re doing is right or wrong. Without that information without that guidance you’re spending a lot of time, which means a lot of money and you’re showing very little results for that.

John: So what are top three tips for creating great mobile app interfaces or great mobile apps in general?

Pete: I think that the first one is starting from content. Understanding your content and designing with content in perspective. That’s going to influence how your product will look and feel from the start. If you don’t understand that then you are going to have a lot of iterations before you actually get to that point. Second I think, keeping it simple is really important. I think that overthinking or even over designing will not help. Keeping things simple especially in the very beginning is very important. Not only will it allow you to get to where you’re going faster but also allow you to communicate your ideas a lot clearer to your audience. Then ultimately third is consistency. Make sure whatever you do is consistent throughout your product and make sure you always keep that in mind. It’s so easy to get distracted and try and reinvent new metaphors or new ways of solving a particular solution you’ve already solved in one sense but ultimately with your app what you’re doing is you’re training a user to use your product in a specific way if you don’t keep that consistent those get confused if you hit certain parts that aren’t the way that you’ve already taught them in the very beginning. I think those are probably some of the three most important things to keep in mind when designing for an app.

John: What are some good online resources for mobile app design?

Pete: So there are a number of blogs out there that have great examples, they talk about great things. I love the simplicity of Pinterest. I look at some of the boards out there. I have my own board that focuses around great UX or UI examples.

John: What’s your username for your Pinterest.

Pete: My username is digitalczech cause I’m originally from the Czech Republic, you can find me up there.

John: A lot of good developers there around that region.

Pete: Yeah that too. I actually like a lot of the design pattern libraries that are out there. There are some sites that curate some of the design patterns like www.captivate.co.uk or www.useyourinterface.com. These are sites that basically focus on certain interactions rather than the actual visual design but they actually show how many menu structures might work or how certain transitions work. They’re very creative and curated very well.

John: So depending on the task you choose a certain one?

Pete: Exactly. Inspiration is everywhere right now and I definitely tell all of my designers go out there and get inspired. Look at what’s available, what other people are doing and push it, take it to the next level.

John: What are some good keywords to query on in Google?

Pete: “Pete Petras.” (Just kidding.) I think “UX design patterns” are great. I think that’s a great set of keywords. “Mobile design patterns.” there are a lot of great sites that refer back to those that are very insightful.

Posted in Android Apps, App Development, Enterprise Mobile Apps, iOS Apps, iPad Apps, iPhone Apps, Mobile App Development TV

Comments

Comments