Design & Development Planning Part 1
The work of building your app can be complex and confusing at times. There is always the question of priority and if you are spending the right amount of time on the right activities.
Too many projects have been compromised, over-budget, or canceled as result of poor planning, lacked of competency, or under estimation of the resources required to finish and launch.
This type of tunnel vision can happen from any side of the briskness, and oftentimes appears from the parts of the process that we are least familiar with.
With that in mind, its important to spend the time up front understanding the product development lifecycle, specifically the product development lifecycle of mobile apps.
In the next two sections, we will be diving deep into each of the main steps that you must know and own as part of the app-launching process. It’s not enough to be vaguely aware, we must master these steps and be able to repeat, rework, or reverse anything that happens across the entire process. essentially, we need to own the app development process if we want to succeed at launching mobile apps.
User Experience Design
In a previous section, we discussed in detail the different activities that are part of User Experience Design. We also covered how to strategically implement a memorable and effective user experience.
A fortunate side-effect of having millions of apps available, we are able to see what types of user experiences are yielding the best results.
The resources that we have access to are extensive. Apple provides a very detailed and thorough guide on their Human Interface Guidelines website.
As reviewed in our previous section dedicated to User Experience Design, we reviewed some of these resources and how they can be used in the concept and design phases of the app development process.
Among the most important moments in the user experience journey is the user-onboarding. We need to be hyper focused on the moment that a user becomes aware of your app, leading them naturally start the download process.
From successful download to user account creation, a million things could pull a user away from your app. Some of those things are out of your control – like a phone call, text message, or other app sending notifications.
With plenty of things that could cause your user to leave the app during onboarding, we need to make certain that they don’t leave because of a lack of interest, or poor execution on the part of your app.
Onboarding needs to be perfect, but not a single type of perfect. Onboarding needs to be perfect for each unique visitor to your app.
While creating a custom onboarding experience for each user is not probable, we can do the next best thing and break user onboarding by the ‘heat’ of each user.
The ‘heat’ of each user is determined by how excited they are to use your service, how much they already know, how much pain they’ve experienced not having your app in their lives, and their confidence in your app’s ability to meet their needs.
We can categorize incoming users into 3 distinct categories, cold, warm, and hot.
A cold user is one that knows very little about your app. These users might have found your app while browsing the App Store or the internet (if you’ve created a web presence as discussed in previous sections).
Cold users require the most effort for the lowest return. The cost of a cold user is directly tied to their knowledge of the problem you’re app solves and their acknowledgement that they have the problem to be solved. As a result, they are not invested in solving the problem, and aren’t yet convinced that your solution is the best solution. After all, they haven’t been trying to solve the problem, which means they don’t know how effective your solution is compared to the solution offered by others.
Warm users are aware of the problem that your app solves. These users might be arrive in your app as a result of well-done advertisement. However, warm users are difficult to persuade because they have already found a solution they haven’t become fully dissatisfied with (yet).
So, even though they are aware of the pain, they aren’t dissatisfied with their current solution – or alternatively – they aren’t convinced that your solution is better my a large-enough margins to make a change.
Hot users are those that are keenly aware of the problem your app solves, and are actively looking for a solution. These users could be coming from other solutions, or they might be at the end of extensive research on what solution will meet their needs best.
These people read reviews, ask others about their solutions, and are likely to be a long-term customer and eventually a brand advocate if you treat them well.
These hot users have the potential to quickly buy, subscribe, and integrate your app into their daily life.
If you need to be selective on what single onboarding flow should be focused on (for resources or timing reasons) you should focus on the onboarding of Hot Users who are anxious to use everything your app has to offer.
They are the best users, give the best feedback, and know understand that real value comes from value that you pay for. These users will be a solid source of income fro your app. So, focus on providing them with the best possible onboarding and in-app experience!
User Interface Design
Along with User Experience, we need to also give the users a User Interface that provides them a method of interaction with your app.
A user interface consists of anything that the user can touch, talk to, see, or hear. Your app should have a good mix of visual, audio, and haptic elements for users to fully experience your app.
Apple provides graphical elements that a developer or designer can use in the development process. These graphical elements are the same elements that are build into the operating system. The only difference is designers can use these elements to create different screens in their app for review before any code is written.
During the user interface design phase, you will be selecting colors, buttons, fonts, headers, logos, and placements for all these elements. You’ll figure out where buttons go, and how they look when they are pressed, held down, and released.
Now, there are millions of things you could do to make your app look unique and expressive. However, there is a very strong argument against heading down that road – at least for your first mobile app.
There is the obviously element of costs that should have come to mind immediately. The more time you spend tweaking your user interface, the more money you will have to pay a designer.
Ironically, the parts of the user interface that designers are most proud of are those parts that cost the most, confuse users, or both. To repeat, it’s important not to over-design your app to the point where it’s no longer a functional solution to your user’s problem. We’re building apps not art.
Functional Design
In this step you’ll need to use both sides of your brain. Developing the functional design is where you begin to bridge the gap between how your app looks and how your app works.
The next section is about technology selection, something that you wont need to be expert at, but you’ll need to understand the what and they why for each technology.
This section is all about mapping the functionality of your app to the user experience and user interface. We’ll answer questions like; “what should happen when a user hits ‘submit’” on a specific page, “What happens when a user taps ‘log-out’”, “What happens when a user taps on a url in a screen in your app”?
We’re looking to uncover the ‘what should happen here’ for each screen in your app.
For this exercise, you’ll answer the following for each screen:
- What is the Purpose of this screen
- What screen was the user on before this one
- What did the user do to trigger navigation to this screen
- Is there any data from the previous screen that should appear in this screen
- What additional data needs to be ready to present on this screen
- How is information organized and presented on this screen
- What is the purpose of the information displayed
- What is the function of the data
- What specific input from a user enables the primary function of the interface on the screen
- Does this screen need to save data after the function completes
- Does this screen navigate to another screen after the function completes
Technology Selection
Without getting into the weeds, even though it can be fun and exciting, we need to cover how technology is selected for your project.
We’ll break down the technology to first party and third party. (I’m not sure why we skip 2nd party, but we only have language to specify first and third). In the iOS development ecosystem, first party technology are those things that are provided by Apple as a framework that you can leverage in your app. These frameworks can be used to enable functionality that you are providing to your users.
Examples of these frameworks include, iCloud, Apple ID, Photos, Messages, Machine Learning, and lower-level frameworks like SwiftUI, UIKit, CoreData, and Notification Services. There are over 250,000 different frameworks and APIs (application programming interfaces) that Apple provides as part of the entire ecosystem that developers can leverage as part of their apps.
For developers, these technologies are accessible through Apple’s developer portal in their official documentation. But, for those that are less technically inclined, Apple has recently provided a more approachable way for entrepreneurs to learn about the technologies available to them for use in apps.
You can access documentation that is a little less technical here.
It’s important to become familiar with the technologies that are listed. It is from these technologies that you will be able to bring together the features that will turn your app idea into a reality. If you neglect to familiarize yourself with the tools and technologies available to you, you run the risk of over-spending, delaying your app launch, and potentially cornering yourself into a never ending development loop that will only make you miserable and demotivated.
The next step is to browse the site, see what technologies can be brought together that will enable your product vision, and document the ones that you think would be a good fit for your project goals. Do NOT delegate this work to your developer. You need to KNOW and OWN the tools and technology that your app needs to succeed.
This exercise includes sitting with your wireframes and mapping each button, image, feature and view to a technology that you think will meet requirements. Only after you’ve done this mapping do you take your work to your developer for review and feedback.
This process will take some effort, but don’t stress. You don’t have to be right about the technology you map to your features, but you do need to think about it. That way, when you developer gives you feedback on the correctness of you feature/technology mapping, you’ll be able to speak from a place of thoughtfulness.
In the next section, we’ll talk about the Build Phase, and the second half the design and development planning.