So, you’re developing a mobile app - how do you streamline and perfect the process? Keep these 7 mobile app development mistakes in mind throughout mobile product development for best results.
Refining the mobile app development process, one step at a time.
MOBILE PRODUCT Development MISTAKE #1 - IGNORING THE USER AS A SOURCE OF TRUTH
There are many factors that go into making great mobile products—for startups and enterprises—and one of the largest universal mistakes I’ve seen over the past few years is a product team ignoring the user as a source of truth. It has two parts:
1. Figuring out who is going to use your product (if you’re reading this, you should already know the answer to this question)
2. Incorporating the user’s feedback while you build a mobile product
The users that will be interacting with your application are the ultimate source of truth.
Does this feature make sense in their minds? Is it intuitive? Does this communicate what users desire or create confusion? All of these questions will be answered by your users—whether you like it or not—when you put the product out to the public.
If you want to save time and money, start to incorporate user feedback throughout the product building cycle starting with design. Do not wait until you’ve designed and developed the product before your first user intercept—it is too late. Start introducing your product to users as early as wireframes and sketches, and watch, record and inquire on their thoughts.
MOBILE PRODUCT Development MISTAKE #2 - SILOING DESIGN AND DEVELOPMENT
Design and development should not work separately in effort to make mobile products come to life. This is an old “waterfall” software development practice. Great mobile products are built with integrated design and development teams, usually in an agile environment.
Old method (waterfall):
-
Business analysts create very specific requirements.
-
Requirements are passed to design.
-
Design creates end-to-end high fidelity designs.
-
Design passes these to development.
-
Development can’t build full designs so developers change the designs.
-
Software is delivered to the business side of the house.
-
Users get frustrated and request feature changes.
-
Design redesigns and passes to development, development can’t do designs but tries and passes to business.
New method (agile):
-
Business side of the house creates high level requirements/goals with user experience and development input.
-
Design and development work hand in hand to create features that are both technically feasible and deliver value to users.
-
These features are divided into user stories, and each user story is designed with development input.
-
Designers hand over designs as they finish. Development builds designs with design oversight/input.
To build great mobile products in an efficient and rewarding manner, product teams need to have integrated design and development during the mobile app development process.
Design can solve problems visually, but if the designs aren’t possible on the technical side, or if there isn’t a budget large enough to deliver a certain experience (most of the time), then design needs to figure out a different solution, which isn’t possible unless design and development are working hand-in-hand.
MOBILE PRODUCT Development MISTAKE #3 - TRYING TO DO TOO MUCH IN A Minimum Viable Product (MVP)
Okay, I get it, there are SO many things that your new product will do, and you think your users want it all. They want the chat function from Facebook, the wayfinding application of Foursquare, the reviews of Yelp, and the ability to facetime with a monkey in the Chilean jungle. Your users are always going to want additional features, and there will always be requests, but do these new features belong in your product?
A great product is SIMPLE—especially an MVP.
“But it’s the Foursquare of events with an Uber-like on-demand system and a Salesforce CRM backend.”
But it also could be separated into three products. Doing too much in an initial release will ruin feedback loops, confuse your users, and fog the business strategy. Additionally, your product team will have a hard time optimizing for any individual experience or business metric.
MOBILE PRODUCT Development MISTAKE #4 – THINKING USER EXPERIENCE DESIGN IS THE SAME AS USER INTERFACE DESIGN
UX is not UI.
What is the difference?
For mobile products, User Experience is the strategy, and User Interface is the execution.
Typically the best way to build great mobile products is with a team comprised of at least a Product Owner + Designer combination, with each role responsible for different elements.
What problem is the product solving, who is going to use it, and how are they going to feel while using it?
These are the questions a great Product Owner will answer. Find one who understands user personas, product strategy, and the two minute rule — what are my users doing two minutes before and two minutes after using the product. Pair those people up with great designers, and you’re moving in the right direction.
MOBILE PRODUCT Development MISTAKE #5 – RUSHING THE LAUNCH OF YOUR MOBILE PRODUCT
All the hype, excitement and hard work all “culminates” into one momentous moment — product launch!
Right?
Not so much in the mobile and digital industry. Products are continuous iterations that require very particular launch strategies over a period of time - all these steps need to be considered to support mobile product success.
-
Do not launch without a user ramp up period.
-
Invite feedback during the launch and after.
-
Stagger the launch of each platform.
-
Invite users into the product launch.
-
Maintain constant user contact.
Think, plan, and involve the development team in the creation of a ramp up strategy. Do not rush. You’re building something for the long term, a couple extra weeks won’t hurt as much as a non-working product.
MOBILE PRODUCT Development MISTAKE #6 – CHOOSING THE WRONG PARTNER
The single most costly mistake in the mobile app development process is choosing the wrong partner. The wrong partner will obviously cost money, but most importantly, it will cost trust, time, and market share.
Since I work at a custom software firm, I help clients understand our process, people, and capabilities to identify if we are the right partner for their specific project. Sometimes we aren’t the best fit, and I have this conversation with potential clients. At Seamgen, we frequently refer people away that inquire about a service our team shouldn’t be solving.
How to choose the right partner?
1. Before you choose a partner, you need to understand how your internal team functions.s.
Do you need multiple approvals?
How fast is your feedback loop?
Do you have internal project management?
How much legitimate budget do you have?
Can your team pivot during development, or are they use to pre-defined requirements?
What happens if they don’t hit a deadline?
What personalities are at play?
Do you have strong product owners?
Who are the major stakeholders?
2. Choose a partner with similar working styles — not just expertise
Most likely, your potential partners have already passed the basic screening — Fortune level client roster, relevant work history, a process that looks tested, and a nice-looking team.
But, do they fit with your internal culture?
Do they have relevant experience solving similar problems?
The only way to figure this out is by asking very specific questions to the potential partner that provide insight on working styles, communication, preparation, and expectations.
What communication tools do you use?
What happens when a deadline doesn’t get hit?
How do you measure velocity?
How do you plan to involve our team in the process?
3. Start with an appropriate budget for your vision.
Design, development, and consulting partners all cost money, and you get what you pay for. Firms that have a higher billable rate can pay their employees more, which allows the firm to constantly recruit and pay the best talent. This is especially true for boutique firms with low overhead.
MOBILE PRODUCT Development MISTAKE #7 – ASSUMING YOU NEED A NATIVE APP
Whether you have a web product that you want to take mobile, or an idea for a mobile product that you want to build, figuring out the right platform to launch is one of the first questions your team should ask.
Not every product needs a native app component.
Mobile has the unique ability to transform every industry, and users expect anything internet related to work seamlessly on their phone. This doesn’t mean every product is a great fit for an app, or that every app needs to be native.
Figure out a delineating strategy between mobile web and native apps.
Stop thinking about the benefit of having a mobile application only from the business perspective, and think about it from the users perspective. Does your app add reasonable value to somebody’s life? What is the purpose? There is a barrier to downloading new apps, and a barrier to having people keep the app on their phone — does what you are building cross these hurdles?
Frequency is a leading indicator for app value.
Depending on how often people are engaging with your brand or application, this can be a leading indicator for building a native application. If the app is going to live on a phone, it should have a delineating reason and frequency of use is a leading indicator. The more often a user uses or interacts with the product or brand, the higher the expectation is to have a mobile application.
If you have decided that an app is going to be part of the strategy, now it’s time to understand there are a lot of routes to travel. One strategy is not better than the other; it’s just a question of which strategy is right for your project.
As you go through the trials and tribulations of the mobile app development process, keep these 7 common mobile app development mistakes in mind. And if you have questions or want support for your mobile product project, contact Seamgen.
