How do you build an app? Pt 1. (Design)
--
What is involved in building an app? Who do you need to talk to you when you’re building it? Can I build my own app? Can I outsource building my app to developers overseas?
If you’re asking those questions you’re in the right place.
This post builds on my previous one What kind of apps are there?. If you haven’t read that now is a good time to check back there, just in case some of the concepts from there that I refer to in this post don’t make sense.
This is the second post in my series on for folks new to app development. Check that introduction for context to the whole series on “How to Build an App”, and links to the other articles.
Its a long post! So I’ve broken it into two parts.
That way after you’ve read this first part about the design side of the app building process; you can make some notes, and get a breath of fresh air. And then you’ll be ready for the rest of the story in part 2, which covers the technical side of the app building process.
Getting Started as an App-preneur
In this post I’ll be digging deep into that core question of how to get started building your own app. We will discover who are the specialist people that work on building apps.
And most importantly I’ll go over mistakes that folks new to building apps make and show you the path to avoiding those mistakes.
So by now you know that developers have to write the code to build an app. Then they create a package, which they upload to the App Store or Google Play store. In the case of a Web app they deploy the app to a web server.
App Development Cycles
This is how the cycle of app development begins. Once some code has been written for an app and it has been installed onto a device, or deployed to the web developers try out the app to see if it works and matches what the app is supposed to look like.
The developers will find things that need to be fixed and changed. Each day they’ll meet with others in the team who also look at the work on the app so far and feed in changes. Then the developers make changes to the code and go around again.
Image credit: undraw.co
Each week or two a version of the app is released for the team and stakeholders to test & try out. Close to go-live early “beta test” versions of the app are tested thoroughly. After go-live there’s already typically a backlog of features that are wanted, and issues that are known about.
App building has a cadence. Regular releases that are tested and tried out are at the core of the app development cycle.
At go live date you have a backlog of features. This means the delivery of the app is always a compromise. Because there’s always at launch some features that are desired being left out. You have some issues you have not yet fixed, waiting for the next version to be released.
This is the number one mistake made by folks who don’t know how to build an app. When building an app you need to plan for the ongoing life cycle of the app.
I cannot stress this enough.
Tip: Plan for the Ongoing Process of App Development
As a coach I see a red flag that folks have failed to plan for the ongoing life cycle of an app. It’s when I hear ingenue app-entrepreneurs talk about launching when the app is finished.
Successful apps are never finished. Corollary: the only finished apps are failed apps.
So many app entrepreneurs that I’ve met, who have given post-mortem talks at conferences & who have written articles online, blame the terrible developers, the App Store or the vicissitudes of fortune for the fact that at their first launch their app was not ready.
Image credit: undraw.co
Newsflash! Are you planning a big launch day? You should prepare for a huge gap between your expectations and delivery. This is true even with an army of perfect developers. Its even true if there’s no problems with the App Store or Google Play store.
There’s a huge raft of reasons why this gap occurs, and keeps occurring, but the biggest one is because building an app is a learning experience. Both you as the app owner and the team building it are learning all about what this app will do to meet customer needs.
So how do you avoid this mistake?
Gaps Between Product and Market Fit
As the owner of an app when you first develop it you will cycle around with your app development team, changing it several times from your original plan, until you’re happy enough to go live.
But even after you go live on the App Store or Google Play store you will keep cycling and changing your app based on how your customers respond to the app. Analytics, download numbers, advertising campaigns and App Store feedback will all play into your plans for improvements to the app.
Image credit: undraw.co
Your launch date does not have to be tied to go live of your app. You can do a soft launch. Once your app is in the store these days no one will notice it or download it typically. So you can time your launch date for a later update when you release some additional functionality and make your big marketing splash at that time instead.
Give strong consideration to a soft-launch for your app. This is so technical completion of the app is not tied to a big product launch. That big splash launch can happen weeks or months after the app first goes live, typically with an additional big feature update.
Throughout all this you were cycling through day by day, week by week with your developers improving the app and steering it closer to product market fit. So the key to success with building an app is actually building a relationship with your app development team through the delivery date and beyond into the life cycle of the app after delivery.
Who is on the App Building Team?
Before we go on to understand the app building process let’s turn and look at the team of specialist people involved in the success of a modern mobile app.
We’ve already discussed the app developer or software engineer. This person writes the code that implements the functionality of the app. They create connections up from the app to the Internet to access cloud based services. They write code to access platform Apis to leverage the power of the iOS or android platform that the app is running on.
But the developer needs to know with great clarity exactly what the app they are building should look like and how it should function in the hands of the customer. This is the job of the UX designer.
Start with User Experience Design
Developers are talented at implementing functionality. But a separate specialist UX designer has to do the job of experience design.
The UX designer will listen to all of the product requirements, what the app needs to do, who will use it, what it should look like and how it will handle the content it needs to display.
With all this information the UX designer will prepare graphical mock ups of all of the app screens including detailed descriptions, button sizes and interaction details.
How to build an app: engage a UX designer before you begin writing any code at all. Its even possible for you to be that UX designer.
By viewing these mockups on an actual phone or tablet you can quickly see whether or not the app will work the way you want it to. Iterating this way, with mock-ups is much less expensive than doing it with a coded app. It’s very difficult to succeed with your app if you rely on coded apps to begin feeling out the user experience.
Special mockup software even allows you to experience tapping buttons and swiping to change screens. If you’re comfortable with graphics software you can even begin with this step yourself — but its a lot of work. Still: that work it cheap compared to the coding of those designs. It’s cheap to change a mockup. It’s expensive to change already written code.
Sorry, No Plain Vanilla
Another big mistake made by those new to app development is to believe that there are simple defaults that will work for their app design. There are an infinite number of possible apps and for each app an infinite number of possible ways to build it.
Developers will create something that can work. But this is leaving app design up to chance. The developers have to guess. They will take a basic verbal or written description, then add their imagination.
The other way to say this is that there are defaults, but you are not going to like them, in my experience.
Let’s say an inexperienced product owner authorised some hand-wavey “defaults”. I hear folks new to development say “Just do something that works”. Then the developers demonstrate what they’ve coded up. Then you find it doesn’t fit business needs and you have expensive rework.
Avoid the mistake of thinking there’s some simple defaults for the controls and user experience in your app.
To avoid this mistake make sure you use a talented UX designer to create application mockups or wireframes. If you are talented creatively and with graphics it’s possible to build wireframes yourself.
Image credit: undraw.co
There’s tools to create the graphics including buttons and other phone and tablet user interface elements, and other tools to share them online collaboratively with developers.
There’s tutorials available on the Internet and you can learn how to use these tools. However if you’re busy trying to launch an app it’s probably best to get a professional to do this work.
As a bonus once you have wireframes it’s much easier to talk to different developers about your ambitions for your app.
Use the Targeting Computer, Luke
Another heartbreaking mistake that folks new to app building make is trying to describe what they want by writing an email.
Apps are completely graphical in how they work with buttons, scrolling, and swiping. Because of this always use graphical tools to describe what you want the app to.
And then when your app changes, you want to communicate that too. App designs will change throughout its lifetime. You’ll want to use online collaboration tools built to handle wireframe designs so you can handle those changes.
The same goes to having meetings. In my time in startups and the app business, I have watched as desperate business owners drag their entire development team into time wasting meeting after meeting where they wave their hands around trying to describe what they want; only to have the developers completely misunderstand their intent.
Development professionals, Jedi and ninjas, know the right kind of tools for this critical communication. Use the force Luke!
Customer and Product Input
I do my app development work by beginning with customer and business needs. Typically I then work with someone who is a specialist at framing and communicating those needs. A person I will work with during the ongoing process of development. I refer to that person is as the product owner or product manager. But they could be an app development client, or a figure from a client company.
The product owner, UX designer and developer work together on a daily basis. The cycle of design code and test happens daily and weekly with the product owner checking that the results of the development process actually fit the customer’s needs.
Image credit: undraw.co
The product owner shoulders the burden of representing all of the people who will be using the app. Sometimes there is difficulty between the app developer and the UX designer as to how a button should work or look. When that happens the product owner can resolve that difficulty. They will do that by looking at the business case for that part of the app.
Continued in Part 2
From here we continue the story with a discussion of the technical team members and what they do to build apps.
There’s also a handy summary section at the end of part 2, that wraps up all the learnings from these two part-posts.
Grab a break, stretch your legs; get a cup of tea or a coffee; and I’ll see you over in part 2 of How to Build an App!
❖
Images (where noted) are the work of Katerina Limpitsouni. Check Katerina’s stuff on undraw.co.
Originally published at https://www.smithsoft.com.au on August 25, 2020.
