How to build a mobile app: App design

/0 Comments/in , , /by

What makes a well-designed app? Is it the colors? The layout? The icons? The flow?

It’s simultaneously none and all of these things combined – and a whole lot more. In this addition to How to Build a Mobile App: The Ultimate Guide, we’re going to go through – step-by-step – how to properly design an app from the ground up.

Step 1: Find the problem

This might be the hundredth time we’ve stated it in our blog, but knowing your users’ pain point will drive every facet of your app’s development – from the logic in the backend to your color scheme and logo.

This is the most important step to take, as it will dictate everything your app does. When searching for a pain point, ask yourself the following questions:

  • Is this problem specific to my niche?
  • What solution does my niche expect?
  • What steps do they need to take in order to solve the problem?
  • Where does my app fit in those steps?

For example, let’s pretend you want to make an app for gardeners. Great! Now, what niche of gardeners are you attempting to connect with? Gardeners is much too broad of an audience. What about community gardens? Those are pretty big right now. Still too broad. Okay, how about community garden managers? Now there’s an idea.

What kinds of problems do community garden managers face? Are community gardens often managed by one individual, or a team? Is that team made of employees or volunteers?

Narrow your scope as much as you can, and know as much as you can about your audience. Go to a community garden. Get your hands dirty. Figure out what it’s all about, and put yourself in the shoes of a community garden manager. Then, figure out how to make their life easier.

Step 2: Know the problem – and the steps to solve it

Let’s continue to pretend you’re making an app for community garden managers, and the problem you’re planning to solve isn’t (after your extensive research) necessarily gardening related, but rather gardening adjacent. You found that two big issues community food gardens strive to solve are food waste and food deserts – community gardens tend to reach out to, well, the community, in an effort to get them eating healthier, fresher, and more local produce.

The community garden you’ve reached out to specifically wants to have a system put in place that keeps track of their food production, and how much of the food produced is wasted – but their group of volunteers doesn’t have the time to reach out to fifteen, thirty, or one hundred people every week.

So, your plan is to make an app that gives the community garden manager the tools they need to keep track of food production and food waste. But how do you go about doing that?

They have a limited budget, and since they’re volunteers, limited time. Because of this, they need a system that gives them the necessary data to effectively run the garden in the shortest amount of time possible. This is also a two step process – the community garden manager needs to know what’s happening in their garden, as well as what’s happening at their members’ dining room tables.

Your app needs to allow the community manager to collect data from remote locations – the community garden members’ kitchens, as well as the garden itself. So, you now know this app will be designed with two types of users in mind:

  1. The community manager keeping track of the different plots in the garden
  2. and the members who self report on their food consumption

Notice that both of these categories of users are organized by the role they play in solving the main paint point – secondary pain points are solved (like how to share and analyze data remotely) in the process of solving the main pain point – giving the manager the tools they need to adapt with members’ tastes, and grow more food that will actually be eaten.

Everyone’s brains work differently, so we won’t tell you to specifically sketch out your ideas, make wireframes, or write a list of steps users would take. Do whatever works for you – but it’s necessary for you to know the expected steps the people using your app will take. These are called your use case scenarios, or user stories.

So let’s map out the main use case scenario for this app. From now on, for brevity’s sake, we’ll call this app “Growr”:

  1. The community garden manager adds in the current produce to a selectable list on Growr
  2. A community garden member selects the types (and amounts) of produce they brought home from the garden from that list
  3. The member then reports on the types and amounts of produce they actually ate
  4. The data is sent to the community garden manager, who then uses that data to optimize the amounts and types of food grown in the garden

Step 3 – Build your brand

Whether you’re doing it DIY or by partnering with a dev shop, this is the time to figure out what your app is going to look like. By this point, you know the audience you’re trying to connect with, the problem they face, and the steps your app will take to help them solve that problem.

An app’s brand is determined by your audience, and measured by how well it solves their problem – not by its icon in the App Store. But, it doesn’t hurt to make your solution look pretty. This is where you’ll figure out Growr’s color palette, fonts, logo, and icons.

After you’ve created these individual elements that comprise your visual brand, and with a map of your use case scenarios, you can start to layout your app. This is a step in the process where we will advise the use of wireframes – this is to help you get a feel for the flow of your app, and save both time and money.

The next step is to add in all the individual elements you made previously (like the logo, and button styles), and fill in the wireframe layouts with final versions. When that’s done, it’s time to move on to the prototyping phase.

Step 4 – Make it work

You don’t need to know Swift or JAVA – there are plenty of prototyping apps available to use. Before we begin coding, our lead designer will create a prototype of the app in InVision, and we’ll all sit down in our conference room to test the build against the pain point. We get the whole company together for these meetings – the more eyes on your prototype the better.

Doing this will allow you to iron out any bumps in your app’s flow, UX, and design all before writing a single line of code. It will also give you an idea of what your app will really look like when it’s complete – it’s the difference between looking at a photo and watching a video – prototyping your app, while adding another step into the design process, will always give you more information that screenshots of your app’s layout.

After this, your design phase is complete! It’s on to coding for you!

Some other prototyping tools you can use:

Platforms, themes, and user expectations

Major decisions about your app’s design will be made by which platform you build your app for – either Android or iOS. Both have different style guidelines, as well as over-arching layout themes. Android and iOS users expect the same functionality to be interacted with in very different ways; Android users, for instance, will look for a “hamburger” style navigation menu, while iOS users will look for a bottom navigation bar.

Android design principles

Create. Unify. Customize. These are the ideals of Android, and specifically, Material design. Material design focuses on typography, grids, space, scale, color, and imagery, and a meaningful, focused hierarchy that immerses users in the UX of the app.

Click here for the full list of Android core design principles.

iOS design principles

Clarity. Deference. Depth. These are the themes that separate iOS from other platforms. Some other words that pop up a lot in Apple’s iOS design guide are understand, familiar, subtle, and functionality. iOS guidelines dictate apps with an esthetic that fits the brand of the app, consistency of theme with iOS as a whole, and fluid manipulation and feedback.

Click here for the iOS style guide.

General app design principles

Whether it’s print, web, or mobile, good design is more than making something look pretty – design is understanding both the project and the problem – and knowing how to present that information in a pleasing way.

An important thing to keep in mind when designing your app is that any interaction should provide a user with some sort of feedback. Think of the difference between a website that features scrolling parallax versus one that doesn’t. Which one feels like the better, more responsive UX?

Smartphones are much more intimate than a desktop – they spend most of their time right next to us – and because of this, we expect our inputs when using them to have a sort of visual conversation with us.

You want your app to feel like it belongs on the users device, and for iOS and Android users, this will mean different things. While Android apps tend to be more customized than iOS apps, both feature libraries of visual elements available to all UI/UX designers. Don’t be afraid to use these – in fact, Apple encourages it. Your app should feel as native to the user as their native texting app.

This is why we believe native development is always the best choice in the long run – even if that means increasing the time and money spent in the development stage. While building multiple apps for different platforms can be more expensive in the beginning, having two native apps that perform better with users than a single hybrid app is a more sustainable and scalable business model. For more reasons why we believe native is the better choice, visit our blog on the topic.

Another thing to consider is not only the hierarchal flow of your app, but the visual flow as well. For example, when an iOS user sees a screen come in from the bottom of their device (known as a presentation), they intuitively expect a step that must be completed before moving back to the previous screen. If a screen comes in from the side (known as a push), they intuitively know they’ve moved on to the next step.

It’s choices like this that may be small on their own, but the summation of their parts as a whole create a consistent visual language and flow throughout your app – which is one of the main hallmarks of good design.

Nitpick the details

Details matter – an app should never have to come with a set of instructions in order for a user to know how to properly interact with it. It’s the small details that will provide your users with the hints and visual cues they need to navigate your app.

Subtly is key to mobile app design. Something as simple as a highlighted or muted color can imply a button’s functionality – if a button is a bright color, your users will expect it to accomplish something. If a button is a muted color, like grey, they will intuitively expect it to perform an action analog to a canceling function.

There’s a balance to these fine details, however. Keep your design as simple as possible – if the people you present your prototype to can’t figure out how to navigate your app in a few minutes (or ideally, 30 seconds), it’s time to go back to the drawing board and figure out how you can simplify things.

Understand the problem

That’s the most important part of mobile app design. It doesn’t matter if you’re not a designer yourself – knowing what your app needs to accomplish will dictate everything about it. It’s a quote I’ve used before, but I feel Frank Lloyd Wright’s words fit perfectly in reference to mobile design:

Form follows function – that has been misunderstood. Form and function should be one, joined in a spiritual union.

How to build a mobile app: Actionable apps

/0 Comments/in , , /by

Did you know that within the first three days of an app being downloaded, 77% of the users who downloaded it have already deleted it from their device?

It doesn’t get any better with time, either – after a month, 90% of users will have abandoned the app. There’s many reasons for this – ranging from the app taking up too much storage space, to unresolved bugs like crashes causing users frustration, enough of which leads to the users switching to another, more reliable app.

For a lot of app publishers however, the problem isn’t user acquisition – it’s user retention. Sometimes it’s for the reasons listed above, but unfortunately, it’s quite often due to the app not providing anything solid for its users to act upon.

Actions speak louder than words

There are many tools you can use to drive user engagement through action – too many to cover completely. And for a lot of apps, the pain points they solve are unique, and therefore use toolsets tailor-made to the particular problem they are designed to solve.

There are, however, general categories of CTAs you can use to drive your app’s user engagement:

  • Tools
  • Push notifications
  • Empowerment
  • Limited time offers and other classic CTAs

Actionable tools

Sometimes, the only thing you need to make an actionable app is a good idea. These can come in many forms – apps like Uber solve a particular pain point brilliantly, Instagram gives users the tools to make every photo look good, and games like long-gone Flappybird toe the line perfectly between simplistic, eye-catching, and just downright fun.

All of these apps listed above are million dollar ideas, or to be more accurate, multi-million (or even billion) dollar ideas. If you’ve come up with a truly ground breaking solution that effects a wide ranging audience before anyone else, or you solve a common pain point better than anyone else, your app fits into this category. After acquisition, you’ve got little to worry about – your app will drive it’s own user engagement.

Not every app built from a good idea will achieve this rockstar status, however – and shouldn’t be compared to giants like Uber. Taxis have been a widespread thing in even the smallest of towns for a long time – Uber just provided a smoother user experience. The whole ride share industry is booming due to its enormous demand – everyone needs some form of transportation, whether it’s a car, bike, or scooter.

Some good ideas focus on smaller market segments – and that’s not a bad thing. A smaller market segment means a close-knit tribe to engage with. Take, for example, Whystle. It’s an app that provides its users with alerts about product and safety recalls announced from government agencies like the FDA or FTC, and the industries they regulate.

While an app like that won’t appeal to as many people as an app like Instagram, Whystle solves a pain point facing many users – health and safety conscious consumers no longer have to scour a multitude of websites for news about recalls – they can just open up Whystle and scroll through a list in a matter of seconds.

Creating an inherently actionable app is the hardest type of actionable app to achieve; but the best way to go about this isn’t to search for a moment of inspiration – it’s all about doing market research, identifying a pain point that has yet to be solved by an app, and then figuring out how to make an app that provides the solution.

For more tips about app ideation, check out our blog on the topic.

On the other side of the coin, you can look at what apps are doing well, and then provide the same tools for a different segment of that market. Think of Uber vs. Lyft.

The equation behind any successful app that serves users as a tool is: pain point + solution + user experience + ASO = high user retention and acquisition.

Push notifications

Push notifications are a powerful CTA tool – they can increase user retention by up to 180%, and users that opt in to push notifications engage with apps 88% more than those who don’t.

The trick is to remember that a push notification will almost 100% of the time be seen as an interruption to your users – the only time it wouldn’t be is if the user is currently navigating to open up your app.

Due to their inherently disruptive nature, push notifications must always have at least one of the following traits (and optimally, both):

  • Provides an immediately tangible benefit
  • Is a personalized reminder or offer

Sending spammy or plain broadcasted push notifications to your users doesn’t have the same impact as personalized ones – broadcasted push notifications have an engagement rate of 15%, while personalized more than triple that with an engagement rate of 54%. Take the time to analyze your user data and craft personalized messages for push notifications – it will pay off.

Look at user metrics like the time of day they engage with your app, the countries they live in, the device they use, the products or content they click on, and then make messages specific to those interests. If you have a segment of users that live in Portugal, craft them messages in Portuguese. If they’ve looked at a specific product a few times and then left their session, send them a push notification with a 5% off code for that product.

The more personal the better. They can also be used to make the most out of a bad situation – for instance, if a user experiences a crash while using your app, send them a push notification apologizing for the issue, and that you’re working to fix it. This kind of personal engagement gives you a much better chance at retaining the user after a bad experience.

An easy way to keep track and make sense of personalized user data is with an analytics platform like Kumulos. Kumulos also gives you a platform to both send out and analyze the results of personalized push notifications.

Due to geofencing and location services, push notifications can now be more personalized and poignant than ever with proximity marketing. These can be used to engage users when they are near a physical location pertinent to your app; for example, if you ran an e-bike service, you could send a user a push notification when they are within two blocks from a bike station.

For more information about proximity marketing check out our guest blog on the topic by Kumulos Marketing Manager Caroline McClelland.

Empowerment

These are apps that somewhat fall into the tool category, but rather than providing a service or tool, give users encouragement to complete tasks. This can be achieved in many different ways; an exercise app can keep track of a users gains or times in order to demonstrate their accomplishments, or a sandwich shop can use an app to keep track of how many lunches a customer has had, and reward them for every tenth meal purchased.

Apps that empower their users like this will often see high engagement – they give users a goal to continuously strive towards – whether it’s losing weight or buying that tenth turkey club. In order to check their progress, users have to open up your app, which consequently leads to higher engagement.

Limited time offers and other classic CTAs

Most marketing and sales tactics are transferrable to apps, and the most common channel for these strategies is through push notifications. Let’s revisit that proximity marketing example – not only can you alert a user that your service is close to their current location, you can make the offer even more enticing by adding fear of loss into the mix: Hey, we noticed you’re close to one of our scooter stations, but there’s only 2 left! Hurry before they’re all gone!

These tactics don’t have to be applied to only push notifications, however. Other digital mediums like newsletters, social media, the app store, and any other channel you engage users through can be used to promote limited time offers.

Personalization and user benefit

Those two features are the bottom line to creating an actionable app. Create pertinent CTAs that provide users with an immediate benefit – whether it’s through the tools your app provides, push notifications, or encouraging the completion of goals. Remember to specifically tailor your CTAs to both your brand and the users you’re engaging with, and don’t be afraid to try new things, as long as you follow the golden rule of user engagement – engage users like friends, not like customers.

Improving your business operations and culture with an internal app

/0 Comments/in , , /by

Very rarely does a change in your business’ process relate to a boost throughout the entirety of your company’s systems and departments – and you’d be right to be wary of anyone claiming to be able to facilitate such sweeping reform.

But there is one change you can make that will increase your company’s efficiency, communication, collaboration, training, and employee retention, as well as inventory management, accounting, service, and sales – all of these facets of your business can be improved simultaneously by creating an internal mobile app for your employees and operations.

Most companies understand the power of reaching out to their audiences using a consumer-facing mobile app. Global mobile traffic hovers at around 50% of all internet usage, and 82% of all mobile users in the U.S. made at least one online purchase through their mobile device as of December 2017. Out of all that mobile traffic, 90% comes from time spent using apps.

Stats like these are compelling – and make for good figures to show to board rooms. But here’s another stat to consider: A study conducted by the Society of Human Resource Management found that large corporations (~100,000 employees) reported an average loss of $62.4 million per year due to miscommunication, and small companies (<100 employees) on average report a loss of $420,000 a year for the same reason.

Those are the direct opposite of insignificant figures. Let’s look into the various ways a mobile app can boost your business’ bottom line and employee culture at the same time.

Improve your employees’ communication consistency

Have you ever called an employee’s phone, and not gotten an answer? Of course you have. Does your team struggle to keep on top of emails from other team members? More than likely, at least sometimes.

With your own internal app, you can keep all communication under one roof – a good way to ensure employees with multiple emails or phone numbers are kept in the loop. This also helps keep past conversations organized, which makes referencing data supplied by co-workers a much faster process for employees working on a project or being trained, lessening the amount of interruption in workflow they face on a daily, hourly, or even minute-by-minute basis.

Workers switching between programs or even devices might not seem like the massive time sink that it actually is – but consider the decision of UPS to not make left turns; they invested in a software that mapped the United States (as well as most of the world), in order to nearly eradicate left turns from their parcel delivery truck routes. This decision ended up saving the company over 20 million gallons of fuel every year – those seconds it takes to make a left turn add up, and the same is for employees waiting for that one program that always takes so long to boot up.

Email is the left turn of inter-office communication. An app keeps everyone, at all times (at least during work hours), in real-time communication with each other – no delays or time spent finding someone.

Your internal app doesn’t have to be limited to the four walls of your office, either – we actually include our clients in their own specific channel in order to ensure clear and quick communication, as well as transparency in the development process. Our business developer regularly sends us photos of cool things happening in the city during his client meet ups – or a photo of his passenger seat laden with donuts on their way back to the office.

If you work in collaboration with any outside teams, agencies, or freelancers, or have a sales or service team in the field, a mobile app keeps them in constant communication as well.

Communication is the key to a strong & collaborative culture

Everyone likes being heard – and from reasons ranging from remote workers to introverted employees, it can be difficult for some of your employees’ voices to be recognized. According to a Gallup poll, 70% of the work force is disengaged – and reasons reported include:

  • Lack of feedback or direction from their manager
  • Lack of socialization with their team
  • Lack of understanding of their company’s mission and values
  • Lack of proper communication between them and their manager

All of these issues can easily be solved with an internal business app. For example, a few months ago, I experienced a death in my family; in the following weeks, the messages and encouragement I would receive from our CEO and my team members were enormously beneficial to my productivity, my well being, and my connection to NS804.

All of our communication is done through this channel. The connection it provides is the backbone of our culture – it’s surprising how empty even a small office can feel without some form of instant communication available.

Our CEO can randomly quiz us on our core principles, and give out rewards to the person who responds the fastest; non-punitive competitions like this help keep employees engaged with your core values, promote healthy, lighthearted conversations between managers and employees, and empower introverted team members that might not be comfortable shouting out “Humble, passionate, unified, grateful, service!” in the conference room.

It’s a level playing field for all types of communication, and keeps employees focused on your goals, and engaged with the work necessary to achieve them. Remember that figure of 70% of the work force being disengaged from their employer? They cost organizations $450 – $500 billion annually – with an internal business app, those organizations could re-engage with a portion of that 70%. Even an employee engagement rate increase of 10% would be equivalent to a $50 billion increase in revenue for those organizations.

That’s not a paltry sum.

Efficiency

An internal business app doesn’t just provide your employees with a new way to talk to each other – it gives them the knowledge and tools of your entire company – and it’s all just a few inputs away.

There’s one word that will make any retail or manufacturing company shiver: inventory.

Between your accounting, sales, and service departments, there’s bound to be a discrepancy in numbers eventually – or, for example, a service employee could grab a part from your stock for a customer in your store, but accounting isn’t made aware of it in time to warn your sales rep that they can only guarantee that new client of yours 49 parts instead of the 50 they were just promised.

An internal business app can stop those handshakes from happening. With an internal business app, your business developer will never again make promise your company can’t keep because you’re one part short from a full order – instead, they’ll impress their client with: “Oh, looks like we just had another sale from that lot. I can get you the partial order right now for a discounted price, or get that order to you in full tomorrow.”

When a client sees that your business developer is that in tune with your company, and that knowledgeable about your capabilities, they are subtly shown that your company will be the most attentive to their needs. Rather than saying, “We take care of our clients,” you can show them in real time.

Internal business apps give these systems (inventory management, accounting, service, and sales) the ability to work off of the same number sets, the same SKUs, and the same reports. If your service department accesses inventory, accounting, sales, and the inventory manager are made aware of the change instantly. With the growing on-demand economy, the ability to report accurate numbers in real time will be imperative to your growth and success.

Internal business apps boost your workflow, make you more adaptable, and improve your client and customer relations

Mobile apps have undoubtably had an enormous impact on the way customers and clients engage with businesses – the companies that migrated to mobile engagement are reaping the rewards right now. The same will be true for companies that utilize internal business apps – they will be more efficient, providing a better customer experience, and they’ll boost employee retention and culture.

A company that boasts high customer and employee satisfaction? That’s one that I’d bet on.

How to communicate with developers

/0 Comments/in , , /by

We are recognized as a top App Design & Development Company on DesignRush.

The wind blew across the blue waves, and set the tone of the day: blue. There is a downed tree in their yard, I wonder when they’re going to take care of it? Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo.

Language is an imprecise tool – especially when you’re attempting to communicate abstract, involved ideas and concepts. Language barriers aren’t just limited to foreign languages – they’re present amongst different professions as well.

Take, for example, the muddy waters of acronyms (which tech is rife with): A chemical engineer is talking to a software engineer about APIs. The chemical engineer thinks they’re speaking about Active Pharmaceutical Ingredients, and the software engineer is thinking Application Programming Interfaces – they’re both engineers (admittedly in very different fields) but they’re talking about completely different subjects, all while using the exact same acronym.

This game of telephone is compounded when two (or more) people who work within completely different schools of thought are communicating the intentions of their ideas. We’ve all been trained to think in different ways, depending on our type of profession: writers live and die by the five w’s and the upside down pyramid, while graphic designers think in the rule of thirds and adhere to visual hierarchy. Mechanical engineers live and breathe f=ma and deal with safety regulations while physicists work with… well, who really knows? You get the idea.

Okay, okay… just one more. A software engineer is sent to the grocery store with a set of instructions: “Buy a carton of milk, and if they have eggs, get six.” The engineer comes back with six cartons of milk. The person who sent them to the store asks, “why did you buy six cartons of milk?” The engineer replies, “They had eggs.”

How to break through the barrier

The first thing to keep in mind (and this is very important) is that software engineers are people too. As much fun as it is to pretend like they’re robots, they have feelings just like you and me – and communicating with them as such is crucial to a successful development cycle.

The easiest way to get around miscommunication is to accept it will happen – and plan for it in your development schedule. There’s a lot going on during mobile app development – a UI designer will look at a project one way, while a programmer will look at it from a different lens, and a project manager will have a unique perspective as well.

Treat your people like people, and you’ll already be miles ahead.

Be organized

It doesn’t matter what tools your team uses to communicate with each other and keep tasks organized – all that matters is you do it. There’s a bunch of project management platforms out there for you to choose from, but it’s important to pick the one that fits your team’s needs and preferences the best.

We like to use Trello, as we can keep track of an entire sprint and the tasks that make up the sprint in an easily digestible format. Our project manager will break these tasks down into individual features that need to be implemented, with specific details of what the final product should be – the flow, the visuals, and the information that must be included.

It’s important to make a distinction here – a project manager doesn’t tell the software engineers how to implement a feature – just what features need to be implemented where. A good project manager can admit they aren’t as technically savvy as the software engineers (unless they were originally a programmer), and will communicate that to their dev team. A good project manager should also know every use case scenario, every step of the app’s process and it’s flow, and it’s entire feature set.

Our project manager rarely fields technical questions – most of the questions software engineers will ask are more about clarification than “how do I do this?” Questions you can expect from developers will be:

“Where should I place the quotations in the text field?” Or, “What font should I use?”

It’s best to provide every piece of information every time. Don’t worry about making your lists pretty – software engineers aren’t worried about that. What they’re concerned with is getting things to their exact specifications. If your project uses multiple fonts, denote which fonts should be used where for each and every task. If you need an to turn 50% opaque after being interacted with, include that information in the task.

There’s no such thing as “over describing” when it comes to code. Say what you mean in the simplest terms possible, repeat information whenever necessary, and communicate exactly what you want and expect. The less wiggle room, the better – be direct.

Code iterations can become repetitive – if you have a sneaking suspicion that you and a software developer are speaking about two different features, clarify. Programmers love clarification.

A picture is worth a thousand words

A prototype is worth a million. If your software engineers can actually analyze what the final product should look like, and how it should act, they’re much more likely to implement your concept correctly. Just like project management tools, there’s a lot of prototyping platforms out there. We prefer to use Invision.

It’s good practice to keep track of your assets by assigning a universal naming convention, i.e. “homescreen_header.svg” rather than just “header.svg”. This will help your developers keep track of what goes where. Checklists are a big help here.

Don’t be afraid to use sketches either – they don’t have to be pretty to get the idea across. Use every medium available to you to express your idea before development gets into the swing of things. Use flowcharts to help software engineers keep track of the flow of the app.

Know your project

Top to bottom, front to back. The more you know about your project – the better. Software engineers don’t have the answer to everything. The work they do might seem like magic, but a lot of programmers are very specialized – a front end developer might even have less knowledge about backend logic than you!

The key to good development is to build a good relationship with your software engineers – and this is achieved by clear and concise communication.

App Trends – If we were going to build an app, what would it be?

/0 Comments/in , , /by

So, I’ve been writing content for NS804 for about six months now (congrats, me!), and for four of those months, I’ve had a singular question written at the top of my cubicle’s whiteboard:

What is the number one question people ask about making apps?

It’s a question I’ve been mulling over when I’m trying to sleep at night, and it’s something I try to consider during all of my content ideation. But it’s a pretty open-ended, context-subjective query.

I’m not even attempting to say I figured it out – I believe it’s an important question to continuously ask because it’s so chase-able and mutable. But I do think the subject of this blog post, at the very least, skims the surface.

The insider’s perspective

Just because I’ve only been creating content for NS804 for six months doesn’t mean I only have access to six months worth of mobile development experience – we’ve been around since 2012, after all.

I wanted to write a piece about app trends (which, if you’re looking for more content relating to current trends of the mobile market, check out this fantastic blog post by Kumulos’ Marketing Manager, Caroline McClelland). I also wanted to at least try to answer this question I’ve been chasing continuously.

So, in my best attempt to answer this previously posed question, I grabbed our CEO, Nick Jones, in our motivational poster-lined hall and asked, “If you were going to make an app, what would it be?”

Without hesitation, he responded with “On-Demand.” He’s a man of few, but pertinent words.

I also proposed the same question to our Business Development Manager, Jon Osborn. As his headphones blasted Biggie in the background (turn the volume down, Jon! Your poor ears!), he answered with:

“Enterprise AR, Process Consolidation (think a master platform), and games.”

So, let’s talk about those.

On-Demand apps

“Wait,” you might find yourself thinking. “On-demand isn’t trendy. Uber was 2009.”

And you’d be right about that – but just because the taxi service industry was flipped upside down a decade ago, doesn’t mean every industry has had its own shake-up. Both millennials and Gen Z have incredibly high purchasing power (in the billions), and love on-demand services – I might belong to the “industry-killing” millennial generation, but I would tout it’s much more accurate to say we like what we like, and we don’t what we don’t. I’ve always failed to see why “the customer is always right” doesn’t apply to millennials for some reason. The inability to adapt spelled the doom of the dinosaurs, just as it’ll spell the doom of Applebee’s. But, I’ve gone on a tangent.

There’s more ground to cover in the on-demand industry than just transportation and entertainment. The amount of service-based sectors that could evolve to work within an on-demand business model is truly staggering – and that’s why it’s expected to become a $335 billion industry by 2025.

The on-demand business model is the greatest boon to local and small businesses since, well, anything. On-demand services benefit from an intensely personal relationship to the consumer, so smaller companies actually have a leg up when compared to big box retailers and the like. Small companies with low overhead also have a strong potential to tailor their services to the demands of an on-demand business model, unlike their larger counterparts.

This isn’t to say large companies can implement their own on-demand services – just look at Kroger’s Pickup. The difference is, however, the potential for growth. If you’re a small business owner, this is the time to build an app to create an on-demand service within your business. It might seem like a heavy investment, but the payoff is worth it.

Millennials don’t like talking on the phone. It takes a lot of time, it’s not conducive to accurate dissemination of information, and it’s not on-demand enough. If your business uses phone calls to communicate with customers in any step of your funnel, you can implement an on-demand form of communication for booking, delivery, or any other service. If millennials are given the chance to place an order online or through an app versus over the phone, they’ll go with the online order every time – even if it takes a little longer.

Enterprise AR

This isn’t the first time I’ve written about AR at the enterprise level, and it certainly won’t be the last. Right now, with a lack of truly pervasive and useful wearables, AR or MxR isn’t entirely ready to make a splash. This is, however, soon to change; wearables are on the rise, and MxR headsets like Microsoft’s HoloLens 2 are soon going to be making waves in the manufacturing industry.

If you want to get ahead of the game with an evergreen, scalable app, go with AR. Once companies realize AR’s potential to dramatically cut training costs, improve worker efficiency, and increase quality, everyone is going to want an AR app to enhance their potential revenue.

Most of the logic behind AR apps is adaptable to many situations, so it’s incredibly scalable. If you build out your logic now, your business could focus on front end development for AR apps, and basically re-brand your backend to fit with the needs of your current client.

The “master platform” app

Time is money. That’s nothing new – but the potential to streamline a business’ internal processes has never been greater.

A master platform app is the perfect way to cut through the chaff of running a business – your accountants can access their books on their desktops, while your sales team can jot down and track leads through their phones, and your customer service reps can engage customers on their POS.

With one platform containing all of these different systems, it cuts down on training time, subscription fees, and time wasted transferring data between incompatible enterprise services.

The best part is, just like AR apps, the backend of a master platform app would largely be the same between one company or another, so it too is scalable.

Games

There’s nothing trendy about games, per se. Gaming trends come about with the advancement of technology – from mancala to jacks, to Pac Man and Flappybird.

There is a new trend coming about with mobile devices, however – foldable phones. This will be a huge boost for the UX of mobile games – right now, mobile games need to account for the fact that at least a quarter of the device’s screen will be blocked by the users’ thumbs. This will all change with foldable phones.

With the ability to interact with two screens, one can be dedicated to controls, opening up the possibility for more intricate or challenging game design. Visuals will also be enhanced as an entire screen can now be dedicated solely to display, rather than acting as a hybrid between visuals and control schemes.

The clamshell design is the optimal design for mobile (what was previously called hand-held) gaming – Nintendo adopted this style with the Gameboy SP in 2003, and with the release of the first generation DS three years later, solidified the UX of this design. Nintendo has been creating addicting games that utilize two screens in truly inspiring ways – and now mobile gaming will have the ability to do the same.

If you’ve been considering making a mobile game, but have been overwhelmed by the amount of saturation in the mobile gaming market, think about what you could do with a foldable phone. Many existent games will attempt to adapt their current UI to foldable phones, but it’ll be the games that were made with two screens in mind that will truly shine.

Think about the user

Trends are called trends for a reason – they’re not permanent, nor fool-proof rules. Whenever you’re in the process of ideation for a mobile app, always focus on achieving one goal – solving your users’ pain point. Nothing is as powerful (or profitable) as an app that creates a positive change in your users’ lives, and that’s not a trend – it’s human nature.

Measuring your app’s success – with Kumulos

/2 Comments/in , , /by

For the past couple of months we’ve been going over both the basic theory of, and different strategies for the implementation of a successful ASO campaign. But one (very important) part we haven’t covered is how to actually measure your app’s growth.

There are many different ways to go about measuring your app’s success, but we’re going do a virtual tour of our favorite app analytics platform – Kumulos.

Before we do, we’re (really quickly) going to go over the absolute basics of ASO, and why it’s just as important to keep track of your ASO campaign as it is to come up with one.

ASO: Just the facts

  • ASO stands for App Store Optimization, and is the process of improving the visibility of an app through the means provided in the App Store or Google Play
  • Keywords are the basis of ASO – just like SEO
  • ASO isn’t just limited to the App Store or Google Play – it ties in with your SEO, as well as the UX of your app itself
  • The rules and trends of ASO are ever changing – just like SEO

Why you need to keep track of your app’s performance

Just because a keyword works well one week doesn’t mean it will perform well the next – staying on top of keyword trends requires close observation of your install rates when changes occur. Also, a powerful tool, A/B testing, can provide a big boost to your app’s rankings – but only if you analyze the data your changes bring.

Keeping track of your competitors performance is just as important as analyzing your own app’s success, and we’ll cover how to do just that a little bit later in this blog. To put it simply, if you’re not analyzing your app’s (and your competitors’) performance, you’re flying blind – and your ASO efforts will eventually hit a wall.

Measuring your app’s success – with Kumulos

There’s a lot you can do through Kumulos:

    Keep track of your ASO campaigns on both the App Store and Google Play – from your app’s description to when you last updated it, and everything in between

  1. Analyze (and create) reports on user acquisition and retention, as well as audience engagement, conversion rates, and your API performance
  2. Explore and analyze events
  3. Keep track of your backend: API use, current SDKs, tables, and more
  4. View reports that are updated every 5 minutes covering app issues, crashes, and other monitoring checks
  5. Last but not least- schedule, implement, and analyze push notifications

    6. Managing your ASO with Kumulos

    Kumulos

    This is the screen you will see after opening your app’s ASO tab. From here you can view all of the information your app displays on the App Store and Google play.

    From the ASO tab, you can compare both your App Store and Google Play efforts. This keeps the access of this information in one place, making it easy for developers to keep track of both campaigns – and allows for simple synchronization, or differentiation, depending on how users on both platforms respond to your ASO campaign implementations.

    Kumulos

    When you click on a specific tab under ASO, Kumulos will give you a detailed breakdown of all pertinent data

    Not only does Kumulos keep track of your keyword rankings, it also helps you figure out how your competitors are doing as well:

    Kumulos

    By clicking the gear highlighted above, you can find a lot of information on your own keywords, and your competition’s:

    Kumulos

    Knowing what keywords your competition is ranking for can help you decide where to focus – consider the following when strategizing your keywords:

    • Just because everyone else is competing for a certain keyword or phrase, doesn’t mean it’s the best
    • Try putting high-competition keywords in the title of your app. For example, “Brew Trader – Trade Beer Better”
    • Mix in low-competition keywords to catch potential users, such as “Beer Trader” versus the more popular “Beer Swap”
    • Make sure most of your keywords and phrases are as specific as possible – while it is important to rank for generic keywords like “beer,” you’ll achieve higher rankings by getting specific with your keywords

    Kumulos also keeps track of your app’s user ranking and user reviews, so you never have to leave the Kumulos portal to analyze the entirety of your ASO.

    Tracking analytics with Kumulos

    Kumulos

    This is where things start to get really cool – as you can see above, there’s a lot you can do with the analytics tab.

    1. Acquisition

    Kumulos

    By clicking the menu button highlighted above, you can select specific items to visualize

    Some things to keep in mind when looking at your app’s acquisition:

    • Retention is an important stat if you app has a demand for daily use – if it doesn’t, you don’t need to worry about it too much
    • Daily users and monthly installs are key metrics to keep track of
    • Look for power users (users who log in continually and daily)

      • Your acquisition report is your key to A/B testing – this is where you’ll find out if the change you made (such as switching your app’s icon or swapping a keyword) had a positive or negative impact on your conversion rates.

      Under acquisition, you’ll also find:

      Kumulos

      How your rankings have changed over time, compared to your competitors.

      2. Audience

      Kumulos

      You’ll use this tab to figure out where you users are coming from, as well as:

      Kumulos

      Breakdowns of which users are using which platform (sorted by version), and which version of your app they are using.

      Use this section to help plan your acquisition campaigns, and keep track of the OS users are on – if a large portion of your users are on older versions of an OS, you’ll want to make sure your updates don’t ruin their UX (such as reducing the compatibility with smaller screen resolutions).

      3. Engagement

      The first thing you’ll see under engagement is this:

      Kumulos

      By studying your session distribution chart, you can figure out the best times to send out push notifications. There are two ways to go about scheduling push notifications:

      1. Send notifications on a busy day right before a peak usage time (in order to maximize the number of users in a given span of time)
      2. Or, send notifications on slower days to boost retention on low volume days

      You can always mix and match to get the most from your push notifications, but we’ll get more into that later.

      Reports via Kumulos

      My favorite Kumulos feature is the report tab. You can generate an interactive PDF based on a range of dates that will provide a breakdown of all the information you’ll need to make strategic decisions for your ASO campaign.

      Kumulos

      Push

      Kumulos

      Under the push tab, you can keep track of who is subscribing to your push notifications. You can also schedule and automate notifications, as well as target specific groups of users, and analyze who’s opening what.

      Kumulos

      Kumulos does a fantastic job of organizing a facet of ASO that is difficult to keep track of, especially with the “sent” tab. Here, you can look back through your app’s history of campaign-driven and event-driven notifications in order to keep track of where you are within a campaign.

      Backend

      Kumulos

      Here you can find everything you need to keep track of your app’s backend: API use, SDKs, API performance, Hookup connection, and all of your application’s details.

      Diagnostics

      Kumulos

      This is a tab you should visit at least once a day – the effects of crashes or app issues on your app’s ASO can quickly spiral out of control. Kumulos helps you keep track by continuously updating this tab every five minutes, so you know as soon as something happens.

      Kumulos is an all-in-one app analytics platform

      Not only does Kumulos provide a complete hub of all your ASO information, it’s very user friendly – this is especially due to the report feature, which allows you to send all the analytics of a campaign in an auto-populated PDF for easy dissemination of information. We love sending these reports to clients, as the data breakdowns are simple enough for anyone to digest – whether or not they know the theory behind ASO.

      The push feature is great as well – not only does Kumulos keep track of all your analytics, it actually provides an actionable service. This is a powerful inclusion in the platform, as it gives you the ability to directly analyze user opening trends, and create a new push campaign based on your analytics, all without ever leaving their service!

      Anyway, I just want to say a thank you to the folks over at Kumulos for their help with this blog – and if you’re interested in getting started with Kumulos, drop by and give them a ring! They’re all fantastic people!

All about beta testing: When, why, and how

/0 Comments/in , , /by

There’s no harsher reality than facing criticism about something you call your own, especially after investing time and resources into your brainchild. This is, however, a crucial step to the success of any business venture, and doubly so when it comes to the app development cycle – and by facing the music before launch, you can jumpstart your app on its path to success.

Marketing companies use focus groups, manufacturers meet standards with quality assurance, and software developers rely on beta testing.

What is beta testing?

There comes a time in every app’s cycle of development where it’s mostly put together, and it’s ready to test its wings. Before its inaugural flight, however, it’s a smart move to have a dress rehearsal in order to identify bugs. This is the purpose of a beta test; it’s a limited release of your app (as its most current, nearly-complete version) among a select audience, with the expectation of receiving constructive criticism about your app from that audience.

It’s an integral but over-looked facet of software development, and while this does add another step to the app development cycle, it ultimately reduces cost, cuts time spent debugging, and serves as a testing ground for future user acquisition and retention strategies.

Below, you’ll find a bunch of reasons detailing why beta testing is important, what you need to know in order to successfully run a beta test, and who to include in your app’s beta test.

Improve your app’s quality

Most developers have their own app testers, and software engineers and project managers will also test builds after every sprint, but there is one major issue when it comes to a dev team testing their own app: they know the ins and outs of the build, the exact specifications of the app’s intended use, and every aspect of the app’s flow. While it’s important to have the team test their own work, it’s virtually essential to bring in outside perspectives in order to catch every snag and bug.

Different testing environments: When you open your app to beta testing, you gain access to a wide variety of devices and usage environments through which to test your app. This is important because your app might not work or display the same way on a Galaxy when compared to a Pixel, just like how a website can look different depending on what browser you’re viewing it in. The actual environment a user is in can also affect the functionality of an app – especially if it requires a wi-fi connection. Your app must work the same everywhere, regardless if the user is in a sub way or a corn field.

Bug detection: The more people that are involved in testing, the greater a chance of a bug being caught. This is because the user base involved in the beta test won’t follow intended user paths as readily as your own dev team, due to lacking the familiarity your team has with the app from actually building it. Its like the difference between an artist explaining their work, versus someone else describing how it makes them feel – while the artist might have a more intimate connection to their piece, what really matters is how their audience feels about it.

There’s something to be said about making something yourself, whether it be a meal or piece of art. There’s nothing like coming up with an idea and executing it from inception to completion, all on your own.

A lot of developers will pay to have a dedicated tester for this very reason, and launching a beta test of your app is essentially adding hundreds (sometimes even thousands) of testers for free.

Improve user friendliness: Not everyone thinks the same way – and that’s a good thing when it comes to beta testing. By bringing in extra pairs of eyes into the testing of your app, you get a clearer picture about how your users will actually interact with your app. Steps in your apps flow might have seemed clear to your development team, but might not be to your beta test users, and it’s always better to rework your app’s flow before its true launch. Users are naturally more forgiving during beta tests than they are with finished products, so they are more likely to give feedback when confused, rather than just abandoning your app for another.

App performance (tech stack): During your beta test, you can analyze different aspects of your app’s performance, the first being the technical side of your app. By looking through multiple user scenarios, you can see what functionalities are used, and which are ignored. If possible, either take these ignored features out of your app entirely, or reduce them to the aspects that are actually being used. Reducing the overall size of your app is important, as 25% of smartphone users have deleted an app from their device solely to free up storage space.

You can also test for crashes and other app-breaking bugs, another big detractor from your app’s user retention.

App performance (user behavior): The second aspect of app performance you can analyze is your app’s user behavior. Despite mapping out the obvious aspects, like user flow within your app, you can analyze other trends, such as the daily, weekly, and monthly patterns of user retention. By figuring out the rate of engagement within your app, you can set a schedule of push notifications, and try it out, all during the beta testing. This will take away some of the burden of creating your ASO campaign.

Reduce cost

It might seem a little backwards, but adding in the extra step and taking the extra hours to conduct beta testing actually reduces the overall cost of making an app. This is for two main reasons:

  1. Speeds up the publishing and app launch process
  2. Reduces overall testing time

Both the App Store and Google Play have rules for publishing your app, and the App Store has an actual app review process. If your app doesn’t meet certain guidelines, it will be denied, and you’ll have to go through the process all over again, which delays your app’s launch, therefore increasing the chances of a competing app getting to market before yours does.

Beta testing also reduces your time spent testing your app – this is because you iron out all the kinks in one fell swoop – rather than testing being staggered and dispersed over the course of weeks, or sometimes even months. When you have your entire team (as well as a dedicated user base) focused on the testing of your app, you can dedicate more resources and developers to identifying and fixing issues before launch – rather than launching first, and then attempting to fix issues that are hurting your app’s reputation, all while working on the development of another app.

Increase your potential for growth

Beta testing can increase your app’s growth potential in two ways:

  1. Word of mouth advertising
  2. Boosting your app’s ASO by building a dedicated user base before its actual launch

When users are included in a beta test, it makes them feel special – it is exclusive, early access to the app, after all. Early adopters tend to be more engaged with apps than regular users, and are more likely to view your app favorably, as they will witness the app grow to accommodate their criticisms. If you listen carefully, and implement changes based off of your beta testers’ feedback, they’ll form a strong bond with your app, and are much more likely to advocate your app to their friends than if they found it naturally. Beta testers will sometimes tell their friends about a new app they get to use before everyone else, instilling feelings of envy among potential users. When your app is actually published, those users will immediately jump on board.

A huge portion of your app’s ranking on the App Store and Google Play is determined by user ratings and reviews. While users can’t review or rate your app during its beta testing phase, they’ll be ready to review and rate it on day one of its actual release. Rather than slowly building up ratings and reviews after launch, you’ll have multiple from the beginning, giving you an extra boost, and helping to differentiate your app from competitors. New users are much more likely to download an app if it already has ratings and reviews, giving you another leg up on increasing your user acquisition – which increases your app’s rank, and provides the foundation for an upward trend of growth.

You can also pay attention to the language beta testers use, and implement popular phrases or words as keywords for your ASO campaign.

Who you need

It’s important to include the right people in your beta test – you’ll want a mix of users who are well-versed with your app and those who are new to it, as well as technically proficient users, and not-so-technically savvy users. The most important audience to include, however, is the community you intend to engage the most with.

From your own development team, you’ll want to include:

  • Product managers
  • Sales staff
  • UX/UI designers (preferably those who haven’t worked on you app)
  • Quality managers
  • The developer’s dedicated app tester(s)

Externally, you’ll want to find:

  • Early adopters
  • The community your app is intended to engage with

Social media is a fantastic way to find (and engage) your app’s intended audience. Reddit is, perhaps, the best place to find your tribe, however. Say, for example, you want to run a beta test for AnswersNow, an app that connects autism experts with caretakers, and helps the caretakers provide better care by answering their questions in real-time.

By going to Reddit and searching “autism,” you can find r/autism, a ten-year-old community with a user base of over 40,000 subscribers. When you directly engage with a community like this, you’ll usually find more people signing up for your beta test than you have spots to fill, and the community will be especially forthcoming if you’re giving them early access to an app that provides a solution to a pain point in their daily lives like AnswersNow does.

When to beta test

There’s definitely a right and wrong time to beta test. Too early, and your testers will abandon your app due to lack of functionality. Too late, and there’s hardly any benefit to the actual testing – the more complete an app is, the more difficult it is to implement changes to its code, UI, and UX.

You’ll want to implement your beta testing when your app has enough functionality to test 90% of scenarios from start to completion. For example, if you’re running the beta test for AnswersNow, you’ll definitely want to make sure the chat functionality of your app works, as that’s the backbone of the app. Quality of life features and elements like graphic icons don’t necessarily have to be there yet – but your app should at least have a logo. Think about a dress rehearsal versus an actual play; during the dress rehearsal, costumes aren’t used, and every actor knows their lines, but they can always ask for help if they forget. During the actual play, everyone is dressed up and 100% ready to go.

How to build a mobile app: Build cycles

/0 Comments/in , , /by

Every business has a process, just like every recipe has a set order of steps – and, just like a recipe, if a business’ process is out of order or incomplete, the final product can end up tasting pretty bad.

Developing a mobile app is no different – missing (or incorrectly implementing) a single step of development can throw a wrench in the process, causing days or sometimes even weeks of delays and re-structuring code.

Every developer has their own tweaks and differences in their development process, but the overarching steps are generally universal in their order. You wouldn’t bake a cake and then put in the flour, after all.

The mobile development cycle

  1. Research
  2. Design
  3. Prototype
  4. Determine feasibility
  5. Program
  6. Test
  7. Publish
  8. ASO & app marketing

These steps, while ultimately implemented in this order, do share some give and take, especially between steps 5 and 6; a dev team will program and then test – and after finding bugs, may return to any point of the process depending on the problem that was discovered.

This method of coding, testing, and then coding again is what’s called agile development. Dev teams that work within an agile development cycle work in sprints – coders will build a feature or feature set usually over a period of one to two weeks (we like to work in one week sprints to really take advantage of agile’s full potential), test the build, debug, and then implement their current branch into the master branch of code.

But, before we get more into steps five and six, let’s talk about step one…

Research

This is possibly the most important step of any business venture – without properly researching your target market, audience, and the competition you will face, there’s no foundation to build a solid structure upon. The story about the three little piggies? Yeah, it’s like that – but it’s your money being blown away, not straw. As we’ve gone over before, there are a few questions to ask that can help guide your research:

  • What do I want my app to accomplish?
  • What platform(s) do I want my app to be on?
  • What is my competition?
  • What is my time table?
  • What is my budget?

Some of these questions will lead the direction of your research, and others will be answered by your research. For instance, your findings about your target audience will dictate what platform(s) you will publish your app on, while knowing what you want your app to accomplish will determine the target audience you will want to tap into. If you want to build a productivity app, for example, your target audience will mostly be persons over the age of 25, while a mobile game might go after a target audience in their teens.

Other times, finding an untapped market might dictate what you want your app to accomplish – there’s a lot of research methodologies out there – but no matter what, every step you take should be to figure out the best way to solve your intended audience’s pain point.

What’s a pain point? Let’s pretend our target audience is… squirrels. Yeah, squirrels. You’ve seen a lot of the furry critters complaining on social media about always losing the acorns they’ve buried, and you’ve decided your going to build an app that helps them keep track of their acorn haul.

The pain point is squirrels are constantly losing acorns – your app, and everything it does, is intended to solve it.

Design

Sketch

Good design is the blending of both form and function to create a simultaneously visually pleasing and useful tool that provides the functions necessary to solving your users’ pain point.

In other words, don’t just make something that’s pretty – make it work for your users. A good way to go about getting into your users’ heads is to come up with user stories; a helpful tool for figuring out what design choices you should make, and how the functions of your app will flow together.

For example, our squirrel-based acorn finder app (which from now on will be referred to as Nutsapp) should have a pretty simple design, as it really only needs to accomplish a few functions to solve the squirrels’ pain point:

  1. Provide users with a map of the surrounding area using GPS
  2. Allow users to place geotags where they’ve buried acorns using location services
  3. Store the geotags in searchable lists – e.g. “acorns by proximity” or “acorns by date buried”

So, we have our user story; a squirrel buries an acorn, opens Nutsapp, places a geotag on their map, and eventually, searches a list to find it again. Based on that, we can create wireframes to determine how the information will be displayed on the squirrel’s mobile device, and based on those wireframes, we can build the UI of the app itself in a program like Sketch.

Then it’s on to the next step…

Prototyping

During this next phase of development, the designer of Nutsapp would build the prototype in a program like Invision. This is where UX is the main focus – prototyping is used to determine whether or not a design makes sense when actually used to solve the pain point of an app.

The development team should always keep in mind use case scenarios during this step – if the app’s flow doesn’t make sense, it’s time to go back to the design phase.

There’s a lot of back and forth between prototyping and design – and that’s a good thing. This is the first step that designers and programmers work with each other, and together, they can determine the next step of the development phase.

Feasibility

Once the programmers for Nutsapp have looked at the prototype, they can then determine the feasibility of its functionality. The programmers will look into whether the necessary back end integration is achievable or not, and determine what APIs will be used to provide users with the functions Nutsapp needs to work.

If a part of Nutsapp’s design isn’t feasible, the programmers will usually work with the designer to figure out a good way to achieve the necessary UX and functionality while still working within the realm of what’s possible to code.

Programming

Coding

Speaking of code, this is where the magic happens. Programmers will take the designed UI/UX and build based on the prototype provided (which is why it’s so important to nail down look, feel, and feasibility of the prototype before moving to this step).

Usually, devs will:

  1. Build the UI
  2. Connect the UI to the code that makes it actually function
  3. Define the data model (the structure of information in the app)

If the dev team is working within the agile method, after each sprint, the team would meet up, discuss their progress, test the functionality, and determine the goal of the next sprint based on the findings of the testing. This cycle is repeated until the app is completely built.

Testing

While Nutsapp’s dev team has been testing after each sprint, after the app has been fully coded, it’s time to move on to beta testing. This is an important step, because it gives you the chance to see how someone who has no knowledge of the inner workings of Nutsapp interacts with and navigates the functions within the app.

It might feel a little disheartening, but do your best to try to break your app. Push every button you can faster than a squirrel normally would, attempt to complete steps out of order, and see what happens when information is input incorrectly.

When you find bugs – and most likely, you will – go back to the programming phase, and fix them. It’s always better to find and fix bugs before launch, even if this delays the launch of your app. Squirrels, just like users, are skittish, and any hiccup in the UX of an app can cause your target audience to abandon your service.

Publishing

After (throughly) testing and de-bugging your app, it’s time to move on to publishing. Both the App Store and Google Play have different publishing rules, and if you’re searching for a quick rundown, look no further than our How much does it cost to make an app? blog.

ASO & app marketing

We’ve gone over ASO and app marketing before (multiple times, in fact), so if you want to go over both the basics and the nitty gritty, visit all three of those blogs.

Your ASO and app marketing campaign are mostly based off of your findings from the first step of the development process – research, and as such, your ASO and marketing campaign should be developed over the course of the entire process. The reason we’ve listed this step last is because ASO and app marketing never end.

Your competition is constantly changing, along with the needs of your users and the trends they expect to be followed. A few ASO rules to always follow are:

  • Update your app frequently, but not unnecessarily
  • Use A/B testing on your app’s page on the App Store (or Google Play) to determine what works best to capture your audience’s attention
  • Keywords, keywords, keywords – look at what keywords your competitors are using, see what you can do to beat them, and figure out keywords they aren’t using to their full advantage to capture an untapped segment of potential users

Your ASO and app marketing efforts should work in tandem – people generally use the search feature of both the App Store and search engines like Google in the same way. If a squirrel is searching for “acorn finder” in Google, they’re most likely going to search for the same thing on the App Store.

Some sections of your app’s page on the App Store don’t rank for keywords, so consider putting your most important and strategic keywords in your app’s title, after the actual name of your app. In the case of Nutsapp, this would look like: “Nutsapp – Acorn Finder.”

Agile development fits its namesake

It’s called agile, because that’s what app development needs to be – adaptive to the issues every development cycle will face, and quick to respond and fix those problems.

How & when to monetize your app

/0 Comments/in , , /by

When we’re speaking with clients about their app, there’s one question that pops up more than platforms, UX, features, and maybe even development cost: How will my app make money?

For good reason too – it’s an important question to ask – apps need to make money somehow. Fortunately, there’s lots of ways to monetize your app:

  • Advertising
  • Initial install cost
  • Freemium content
  • Subscriptions
  • In-app purchasing
  • In-app currency
  • Sponsorships

We’re going to get into each of these methods in a second, but first, we need to ask another important question: When is the right time to monetize your app? We’ll look into that after we go over the different ways you can monetize your app.

Advertising

If implemented correctly, ads can bring a lot of profit to your mobile app. This is the most common form of monetization within apps, and for those with large user bases, it can be remarkably profitable. There’s a lot more methods to advertising than the classic banner ad:

  • Interstitial – Fullscreen ads that appear during natural transition points, usually between two different screens in an app
  • Video
  • Native – These are ads that appear to be built into (or native content of) the app – like LinkedIn’s in-feed advertising
  • Rewarded ads

The trick to advertising within your app is making sure the ads both demand a user’s attention and mesh with the UX simultaneously. This can be achieved in a number of ways, a classic example being only selling ad space on your app to companies that offer services or goods your users would be interested in.

Possibly one of the most interesting forms of advertising is rewarded ads. With an eCPM of $16 on iOS, these ads have a very low CPC compared to other methods of advertising. Rewarded ads accept that users really don’t want to be bothered or interrupted by ads – and because of this awareness, they reward the user for viewing them with in-app currency, discounts, extra content, and many other digital rewards. Due to their self-aware nature, rewarded ads see the highest engagement and conversions when compared to other forms of advertising.

Initial install cost

For a lot of apps, an up-front install cost is going to stifle your growth. There are a few types of apps users are willing to pay for, however:

  • Health and wellness
  • Fitness
  • Productivity
  • Specialized services

ASO plays a huge role in convincing users to pay to download your app. As we’ve gone over before, keywords are your key to success on the App Store and Google Play. Your in-store efforts should work in tandem with your website’s SEO and Adwords campaign – utilizing the same keywords for both SEO and ASO gives you a better chance at capturing and funneling users into download conversions.

One thing to keep in mind is that if this is the only method of monetization your app utilizes, your user base must continually grow, or your profits will stagnate. Only the top performing apps really see a huge profit from downloads. For example, in Q1 of 2018, almost 20% of apps on Android saw 10-50 downloads total, while the top 0.1% saw over 5 million – a huge discrepancy.

Freemium content & subscriptions

Both of these methods of monetization work using the same general idea; show your users what there is to offer, get them hooked, and then ask them to pay for more. It’s try before you buy with apps.

Free trials that allow users to explore an app for a set amount of days work well for both consumer facing and internal business apps. If your app’s UX is strong and solves your users’ pain point (and they’ve had enough time to associate your app as the solution), getting them to subscribe is easier than you’d think. You can even have different levels of subscriptions, to catch a wider range of users – some may not need a “premium” package, but still want to use other features in your app.

Subscription based apps are great for audiences that might not grow, but engage. If your app has less than a thousand users, but every user is paying $10 a month, that’s a lot better than one thousand 99 cent downloads.

Freemium content can be a little trickier. This is a careful balancing act – your app must have enough free features to draw users in, and show your app’s value in their lives, but leave them wanting more. Just enough to keep them coming back, but with the promise of a better UX if they pay for it. This is a popular way to monetize your app – 64% of users of freemium mobile games make a purchase every month.

This method works very well with consumer facing apps like mobile games – a few levels or missions can be offered as a demo of sorts, which gets your users hooked by the gameplay or storyline, and then (when the app holds perceived value with the user), you offer them more.

In-app purchasing & in-app currency

Both in-app purchases and in-app currency are fantastic ways to monetize consumer-facing apps, especially games. One great aspect of in-app purchases is that they actually rank for keywords in the App Store, which can be a tremendous boost to your ASO efforts.

In-app purchases can be a one-time deal, or last throughout the user’s lifetime of engaging with the app. For example, a user could purchase a new costume or skin for their character that would be available to switch out at any time, or they could purchase actual in-game items that are depleted once used. Both are very tempting options for gamers.

In-app currency works much in the same manner – but these purchases are only consumable – meaning once they’re purchased and then used, they’re gone. Think $10 = 1000 coins, or whatever conversion rate makes sense for your mobile game. Just like tiered subscriptions, offering multiple packages at different price ranges is a great way to catch more conversions.

Sponsorships

If your app has a decent sized user base with high engagement, but is still struggling to turn a profit, you might want to consider sponsorships. Unlike ads – which are constantly changing, utilize different tactics to grab attention, and sometimes interrupt the UX and flow of an app – sponsorships are an unobtrusive way to advertise a company’s brand.

This is what happened with Runkeeper, an app that tracks workouts and rewards runners based on their fitness goals. Asics, seeing the value of the engagement users had with the app, sponsored it, giving them a continuous stream of users associating their brand with an app that was a part of their daily lives, and brought a great method of monetization to Runkeeper.

When to monetize your app

This is the most important question of all when coming up with ways to monetize your app. And, unfortunately, like most important questions, there’s no concrete answer. Users are fickle, and they’re more likely to delete your app than engage with it. Put yourself in your users’ shoes; would the method of monetization you’re considering interrupt the UX? Would it tarnish their relationship with your app? Do the ads bring extra value to the solution your app provides? Is your monetization pertinent to your app? Do you expect to grow rapidly, or slowly, but with high user engagement?

These are all great questions to ask, and one of the best ways to find out is with A/B testing. What happens to user retention when you add a sponsor to your app? Do users exit your app after being presented with an interstitial ad?

Don’t be afraid to test out different methods – but make sure they make sense.

How (not) to build an app with Appy Pie

/0 Comments/in , , /by

There’s something to be said about making something yourself, whether it be a meal or a piece of art. There’s nothing like coming up with an idea and executing it from inception to completion, all on your own.

For the self-driven individual, an app WYSIWYG (What You See Is What You Get) editor sounds like a dream – they can work pretty well for websites, so why not apps? Wouldn’t it be cheaper to make it on your own anyway?

It makes sense that a service like Appy Pie would be tempting for any appreneur with an eye for design and a small budget – or maybe a CTO in the same situation. But – and this is my honest opinion – I think it would be easier to design an app in Sketch, prototype it in Invision, teach yourself Swift, and build in Xcode, than it would be to create a successful app using a service like Appy Pie.

I have come to form this opinion because I tried to make an app using Appy Pie. I originally intended this to be a fairly benign chapter of our How to Build a Mobile App: The Ultimate Guide, detailing the best options to use and a short how-to guide for the appreneur who does not have the funding to hire an app developer; but almost as soon as I started testing the user experience of Appy Pie, I knew that wasn’t going to happen.

Because; skipping (for now – I’m going to get to these later) the un-organized creation system, limited options, and inescapable cookie-cutter feel – it’s not you making your app. It’s Appy Pie.

Now, I feel like I need to put a little disclaimer before we go any further; I don’t hate you, Appy Pie. This isn’t a vendetta against you personally. It’s just WYSIWYG doesn’t work with app creation. This isn’t even really about Appy Pie – it’s about any service that provides a way to make apps without coding them.

Making an app with Appy Pie

Appy Pie

At first, I was intrigued. “Create an app for free in 3 easy steps? That sounds awesome!” I was interested in how it would work; I had built a website that didn’t need to accomplish much using a WYSIWYG creator in my first year of exploring web dev, and it had honestly taught me a few things, and the site really wasn’t half bad (for what it was intended to do). So, I had hope that there would be an equivalent for apps..

What I’m trying to say, is that I went into this with an open mind; I didn’t intend to write a piece touting the benefits of hiring a mobile developer over using a service like Appy Pie. It’s just how it naturally transpired.

Appy Pie

One of the first questions Apps Pie asks is on point: What’s the purpose of your app? As we’ve gone over in the past, knowing the purpose of your app is one of the most important questions to answer before doing anything else. At this point, I was hopeful.

And then came “Step 2.”

Appy Pie

This is where it all starts to fall apart. The above screenshot is what you’re greeted with, and while Appy Pie’s UI is pretty straightforward to navigate, I found it extremely difficult to visualize what I was creating. Now, not every app developer has the same process, but a simplified overview usually looks like this:

  • Designing the UI in Sketch
  • Planning the flow in Invision
  • And then coding based upon the Invision file

Appy Pie seems to take this process and condense it into one step. While this may seem like the service has just streamlined the app building process, they’ve instead muddied the waters. There’s a lot to keep track of when planning and building an app, and one scrollable list isn’t the most efficient way to go about it.

Take, for instance, what an app’s UI design looks like in Sketch:

Sketch

Every rectangle you see above is the design for each screen of a single app. These screens are then put into Invision and linked together to plan out the app’s flow and UX. During the design and prototyping phase, our UI/UX team gets into the nitty gritty details of each screen, working in tandem with our programmers to determine everything from screen transitions to the exact pixel dimensions for each button, field, and image.

Our developers can then take the Invision file, and code based on that – providing them with easy access to all the necessary information, from hex colors and fonts to UX and flow.

Now, imagine doing all of that, but with this UI acting as your tech doc, your design editor, your prototype, and your code:

Appy Pie

Yes, it’s visually simple. But take a look at that Sketch screenshot again. Now imagine bringing that level of detail into a system like Appy Pie’s. This system condenses the intricate and detailed process of creating feature sets, UI/UX design, and app flow into:

  • Choose feature
  • Design feature
  • Choose another feature
  • Design that feature
  • Repeat ad nauseam

This is a great way to produce an unorganized app. It’s akin to not only building a house without a blueprint – but building a fully functional and furnished kitchen with plumbing, appliances, lighting, table and cabinets, and a coat of paint – and then moving on to the living room’s wooden frame. Doing this, it’s unlikely you’ll build a structurally sound home.

This isn’t even mentioning the cookie-cutter feel this system is sure to produce. Take a look at the options given to you for layout and design:

Appy Pie

Appy Pie

With limited options and methods of implementation, your app is bound to feel just like someone else’s.

This muddied method for app creation has another negative compounding factor: You don’t know how anything fits together. Sure, “Step 2” has a live preview of each page on the right side of Appy Pie’s UI:

Appy Pie

But all too often, I would be met with this message:

Appy Pie

Which brings us to development cycles. We’ve covered some dev cycles before, but overall, most developers will use what’s called agile. Basically, the steps to an agile development cycle are as follows:

  1. Identify and set goal for issue
  2. Work on issue
  3. Meet up after a set amount of time to discuss and test process on issue
  4. Iterate until complete

This process can take anywhere from a day to two weeks, and it largely depends on the developer – but (and this is a very important but) – each issue (another word for feature) is tested independently before it’s implemented. This is because (as we’ve covered in our Swift development piece) programmers will build their code in a branch, test that branch independently from the rest of the code, debug, and then merge their branch with the master branch.

This serves two very important functions: compartmentalizing bugs, and reducing the risk to the overall codebase. It’s much simpler to look over 100 lines of code and find the problem with your app than it is to look over 10,000 lines. By testing each feature by itself, developers are able to cut down on overall time spent testing the app – measure twice, cut once.

And this is where things really start to go downhill. I had made a gallery linked to my Flickr account, and I wanted to test it on a phone to see what it would actually be like to use this app on a device. So, I downloaded the app, and this is what I saw:

Appy Pie

Honestly, not bad. All the work I had to do was select the grid layout, and I had played around a bit with some of Appy Pie’s default backgrounds. The scrolling, albeit a little janky, worked, and switching between the “Donate” and “Photo” bottom menu options worked. There were a few problems though – scrolling just stopped loading new images after a certain point, and I wanted to take away the “Sets” tab, along with changing the typeface the gallery used.

So, I set those as goals to fix – much in the same way developers will test, find a bug, and fix it. I went back into Appy Pie to edit the gallery, and I was met with this:

Appy Pie

I couldn’t edit. I had downloaded the app to a device in order to test a feature set, and I couldn’t make changes (not until I paid, at least) based on my findings from testing.

How to make an app with Appy Pie: v1.1

With this newfound information, I present the fool-proof guide on how to make an app in Appy Pie “for free in 3 easy steps”:

  1. Make an Appy Pie account
  2. Design, plan, and implement your entire app all at once (perfectly too, no testing allowed)
  3. Publish your app

It’s just that easy!

When I started researching Appy Pie’s service, I really didn’t expect to end up writing something with as much snark – but my plan was forced to change. I tested an outline against my actual experience, found they didn’t work together, and then edited the outline to make it fit with what actually happened. A process Appy Pie can’t seem to replicate – for free, at least.

There’s so much more to a successful app than just making it too; ASO is a huge factor for your app’s success. For any sort of analytics, you’re paying $50 per month per app, and that app can only be stored on a maximum of 600 MB of space.

There are entire companies dedicated to analytics and building keyword campaigns for apps, and when you build an app with Appy Pie, you’re expected to do all of it yourself, while paying a platform for allowing you to do so.

If you’re a self-driven individual set on making your own app, we think that’s great. Our senior Swift developer is self-taught, and we believe some of the best coders come from the evolution of hobbyist to professional – but keep in mind, if a service’s “Create an app for free in 3 easy steps” claim seems a little too good to be true, that’s because, more than likely, it is.