Five mobile app design ideas

/0 Comments/in , /by

Imagine you’re driving down the highway. Ahead of you are two cars, both of the same make and model, traveling down the road side by side – they’re even the same paint color. Despite these shared qualities, they’re easily distinguishable from each other. Why?

The car on the right is ten years older than the car on the left.

Just as the style of cars seems to evolve every five to ten years, so too do popular app design styles and features – albeit in a much tighter timeframe – and app trends tend to expire and evolve every 5 to ten months.

Due to these rapidly changing mobile design styles, maintaining your app’s user retention basically comes down to playing a continuous game of catch-up; whether it’s with newly thought of updates of your own, or as a response to users expecting a newly invented feature or style.

And if only that was all there was to worry about.

There’s a continuous stream of new devices flooding the market – Apple’s iPhone has a regular release cycle, and there are more Android devices than anyone can keep track of. With these new devices come higher screen resolutions, faster processing power, and in general, the ability to do more.

When phones have features, users expect to be able to use those features while engaging with your app. People buy devices because of the functionality they offer – and due to the continual evolution of mobile device design trends as well. If your app doesn’t account for the new features, resolutions, and capabilities of new devices, your users will stop engaging with your app.

No matter what, you’re going to need to update the design of your app during its lifecycle – but coming up with ideas once, twice, or even three (or more) times a year can get tiring. That’s why we’ve decided to write this blog – to give you some jumping-off points when coming up with new design ideas while updating your app.

If you’re looking for ideas on how to design an app from the very beginning, the following blogs are more in-line with what you’re looking for:

1 – Night Mode

If your app doesn’t already have a night mode, it’s time to implement one. The main purpose of night mode is to reduce your user’s eye strain during, well, the night. There are many other tangential benefits to night mode as well, however:

  • Improved legibility
  • Reduced eye fatigue
  • Less screen flicker (this is a very limited-in-scope issue, but can be a huge detractor to your app’s user retention)
  • Less blue light
  • Saves on battery usage

Implementing night mode is a relatively straightforward process – it should begin with your designer, who will play with color combinations for the proposed night mode. It’s not exactly as simple as inverting the colors of your app:

Notice that not all the design elements were perfectly inverted – the background of the night mode isn’t pure black, while the background of the normal mode is pure white. The text of the normal mode is a dark blue – the text in night mode is a very light grey; meanwhile, the button to add another textbox barely changed.

After landing on your color choices, your developers can step in. All that’s left to do is to change the color values already written in the code of your app – a very simple and straightforward process.

There is one more design implementation you need to make in order to ensure the best night mode experience for your users, however; users need an on/off toggle switch they can tap to turn night mode on and off. This is easy for both designers and programmers to implement, so this extra UI improving design feature won’t take too much time to develop.

If your app is for iOS, the code is extremely simple to write. The Swift tag “UISwitch” will provide your app’s users with a ready to use on/off toggle switch – then, it’s just down to placing it in the designer’s desired space.

Perhaps one of the best places to place the on/off toggle switch is in the top right corner of your app – this way, when users engage with your app in a darkened location or time of day, they don’t have to squint at a bright screen in order to find your night mode switch.

You can also consider implementing an auto night mode that enables itself after a certain time of day – this way, users don’t have to worry about pressing an on/off toggle switch.

Night mode is a simple design change that shows your users you care about both their experience using your app, as well as their personal health – implementing is easy and fast, while the improvements to your app’s UX are significant. Due to these factors, night mode is definitely worth the time and money required to implement into your app.

Next, we’re on to…

2 – Bigger, responsive buttons

Much in the same way that website elements (like buttons or image links) became more interactive and graphical as technology advanced (allowing for faster transfer and reading of data), so too are app design elements becoming more visually-oriented as mobile devices (and the introduction of 5G) improve data loading times.

A logical implementation of this is through responsive buttons – just as the header image on this page will respond to you hovering over it, so to are apps beginning to implement this type of responsive design. If you’re an iOS user, the most recognizable implementation of this would be how app icons will shake when you’re in your home screen’s edit mode.

Below, you’ll find a few different options for responsive buttons:

  • Swipe-able buttons
  • Enlarge-on-contact buttons
  • Flippable buttons

Also, why do we recommend making your buttons bigger? Simple – screens are bigger now. Not only do bigger buttons help tie your app’s design together on a bigger screen, they’re also easier for users to tap. If you’re deciding between an intricate and beautiful design, or a simple, easy-to-use and understand design, always go with the latter.

An app that provides easy interaction will beat the beautifully designed app every time – users don’t download apps to marvel at their design (well, we do) – they use your app to help solve a pain point. If a button is easier to tap, you’re helping them solve their pain point faster.

3 – Dynamic functional animation

In the same vein as responsive buttons, you can improve the flow of the entirety of your app by adding dynamic functional animation to its design. The most well-known example of dynamic functional animation would probably be scrolling parallax – which is achievable to implement with newer versions of both iOS and Android.

For an example of scrolling parallax, click here.

Other examples include:

  • Highlighting currently interacted with areas
  • Auto-zoom content
  • Dynamic images

    • Dynamic functional animation is first and foremost subtle. Rather than standing out on its own, dynamic functional animation serves to strengthen the design of an app itself through animations that are logically and strategically implemented.

    Humans are hardwired to acknowledge and respond to movement – it’s what makes it so hard to maintain eye contact during a conversation when something’s moving in the background. Due to this quirk of human nature, design enhanced by animation will usually catch someone’s attention more than a static design.

    In short, dynamic functional animation ensures your users give your app more attention.

    Dynamic functional animation ensures your users feel like they’re interacting with an actual, tangible tool, rather than pixels on a device’s screen. Animations needn’t be hardware intensive, nor utilize 3D graphics – simple motions like a shake, or colors of elements fading as they scroll over the screen add that extra little bit of UX that helps to keep users engaged.

    Even adding a little jiggle when switching between tabs significantly enhances the UX of an app:

    Credit: Behance Gallery

    There are some limitations you should impose upon yourself when implementing dynamic functional design in your app:

    Make sure it’s easy to use

    Your app should first and foremost be easy to use – for the same reason explained above in our section about responsive buttons. It’s named functional design for a reason – its implementation has the purpose of enhancing your user’s experience, not detracting (or distracting) from it.

    Dynamic design should always be able to be described as “simple.”

    Make sure it’s purposeful

    Any animation should fit with the functionality it is enhancing. For example, an image tile in a gallery could flip to reveal the photo’s information on the “back” of the photo – this would fit perfectly, as it gives the impression that the images are 3D and have a physical back that information could be written on. A progress bar that flips as it fills up, unlike our photo gallery, doesn’t make sense – and would probably only serve as a distraction.

    Make sure it’s not annoying

    This is perhaps the most important factor to keep in check – dynamic functional animation can get out of hand very fast.

    Tight, quick animations are fine, and add to the UX of your app. A long, drawn out animation only serves to interrupt the flow of your app, and increase the time it takes users to solve their pain point.

    Keep your animations short, and your users will stay happy. It might be fun to design and code highly detailed animations – your users might even appreciate the animation the first few times. But the purpose behind updating the design of your app is to increase your user retention – and if users are continually using your app, drawn out animations will quickly become stale.

    Make animations that are just as satisfying the thousandth time as the first.

    4 – Simplified UI

    While we’re on the topic of keeping things short and sweet, let’s take a look at the benefits of simplifying your app’s UI.

    We touched on this briefly in the first section of this blog already, but its’ importance warrants a more detailed overview. A simple UI will always be better than a complicated one – no matter how much extra functionality a complicated app’s UI provides its users, the simpler competitor with half the functionality will most likely be more popular.

    This is due to the same reason there’s such thing as a universal remote. There’s nothing more annoying than having to use three different remotes to watch a show on your TV. We tend to get frustrated as we’re presented with barriers such as these; in this example, we want to watch TV. Not play with remotes. For every extra remote we need to use, it’s an extra barrier to watching our show.

    The same goes for apps. For every step a user must take to complete a session in your app, another barrier has essentially been added between where the user is in their session, and the solution to your app’s pain point.

    Designing an app is like creating a sculpture made of marble – it’s a subtractive, rather than additive process. During the ideation stage of any app, it’s important to narrow the scope of your app to its core functionalities – from there, you can add extra features. But remember – for each feature added that’s necessary in the process of using your app, you are creating another barrier between your users and the solution to their pain point.

    Don’t make them use three remotes to finish a session in your app.

    Just as it’s wise to narrow down the scope of an app during its initial ideation, so too is it important to do the same when updating your app. An easy way to ensure practical application of simple UI updates is to treat updating your app as if the update is a MVP.

    The easiest method of implementing simple design updates is to create a list with everything you want your update to include, and then try to connect every bullet on that list to the main pain point of your app. If an item on your app’s update wishlist doesn’t help to solve the pain point, or improve the experience of using your app, it most likely isn’t needed.

    There is something we want to clarify – a simple and concise UI doesn’t always mean simple code, nor quick design. Dynamic functional animation will not be simple to program, just as a simple-to-understand design could take hundreds of hours to achieve.

    A simple implementation of dynamic functional animation is measured by how much (or lack of) interruption it provides in the process of using your app – the more interruption or delay in the flow, the less simple (for the user) it would be.

    5 – Color Palettes

    Circling back to the same vein as night mode, switching up your app’s palette can go a long way toward improving your app’s user retention.

    Picking new color schemes is fun, and the actual implementation of such is fairly easy (and we already covered it in the night mode section of this blog) – but we do want to cover the timing and methods behind putting a fresh coat of paint on your app.

    A/B testing

    A/B testing is switching out one piece of content with another, and then recording the results. In this case, rather than switching out actual content, you’d switch, for example, the color of your header text from blue to red, and then watch and record how your users react.

    In order to successfully run an A/B test, you’ll need to record all of your user data prior to the test for the same duration that the test will run. Then, implement the changes to your app through an update. Record the data that follows, and then compare the two sets of data. If you want to be extra through, you can repeat this process multiple times to ensure your samples aren’t skewed.

    From here, you can permanently implement the color palette that is best for your app’s user retention.

    Situational updates

    When it comes to updates, timing is everything. In order to capitalize on upcoming cultural events or holidays your users celebrate or engage in, you can update your app’s color palette for the duration of that time period.

    For example, a shopping app could update its color scheme to match the next upcoming holiday – changes like these can help put people in the holiday shopping mood. Now, keep in mind that this doesn’t mean this shopping app would change its normal color palette of white, blue, and orange to green, red, and white for Christmas. Rather, small hints of Christmas colors could be interspersed throughout the app.

    There’s an infinite number of app design ideas…

    But that’s all we have for now. We hope you’ve found this blog helpful in serving as a jumping-off point for your app’s new design.

    If you’d like to keep reading about app design, check out our blog on how design impacts the cost of your app.

    We’ll blog about more app design ideas in the future, so stay tuned for more!

Android or iOS development – which costs more?

/0 Comments/in , /by

This blog was updated on July 3, 2019

Developing an app is never an inexpensive endeavor, which is why it’s always important to cut any unnecessary costs. What’s the most significant variable to the cost of developing your app?

Android, or iOS?

After identifying your targeted pain point, the next question you should always ask yourself is this: which platform do I launch on? Answering this question will dictate your UI, your marketing, your development, your testing – the entire strategy behind building your app, basically.

Quite often, however, the most important aspect of developing an app isn’t which platform to develop for, but which platform costs more. So, which platform does cost more to develop for? Well, by now you’ve probably noticed a pattern – it depends.

For the time-pressed reader, the more affordable option is usually iOS. But there are factors that can alter this answer, and it’s important to know why and how these factors impact the cost of developing an app.

Let’s get into it.

The two wrestling giants

Both Android and iOS boast an almost unprecedented number devices sold, available apps, and total app conversions:

  • In 2017, over 1 billion Android devices were sold, while Apple sold over 200 million iOS devices
  • As of 2018, Google Play has 2.6 million apps available for download, while the App Store comes in a relatively close second with 2 million
  • In 2018, App Annie released a report stating that the total number of app downloads between Google Play and the App Store was 28.4 billion conversions – of that number, Google Play accounted for 20 billion downloads

Android owns significant percentages of the marketplace, while iOS apps see higher user retention:

  • In the U.S., Android owns 54.6% of the market, and iOS owns 44.4% (Android is the top performer globally)
  • More iOS users download purchasable apps than Android users (11.82% vs. 5.76%)
  • iOS apps have a higher retention rate than Android (1% to 3% higher)

Something to keep in mind: While Android does account for a larger share of the mobile market than iOS (at least in terms of devices sold), this figure is likely skewed by the fact that Android comes with many pre-paid phone options, and there are no iPhone counterparts. While this larger presence seems to indicate apps available for both platforms would see more downloads from Android, we have witnessed the opposite from the data of apps we have published.

Out of these three apps, one has an audience centered in the U.S., one is centered internationally, and one has an audience split almost evenly between the U.S. and international markets.

  • For the U.S. centric app, 76% of downloads are from the App Store.
  • For the internationally centric app, 46% of downloads are from the App Store.
  • For the app evenly split between U.S. and international markets, 65% of downloads have come from the App Store.

Purchasing power and user profiles

When you compare the average revenue per user between app categories on Google Play and the App Store, despite iOS accounting for less devices and downloads, iOS apps see higher average earnings than Android.

  • Gaming app average revenue per user: $1.99 (iOS) versus $1.56 (Android)
  • Shopping app average revenue per user: $19.64 (iOS) versus $11.49 (Android)
  • Travel app average revenue per user: $32.29 (iOS) versus $20.47 (Android)

What’s the reason behind these differences? While it’s important to keep in mind that the following findings are generalizations of markets, and not indicative of every user profile, there are noticeable trends that arise when comparing Android and iOS users:

Again, these are generalizations, and should be treated as such.

Some other interesting stats on user profiles:

  • iPhone users are more likely to engage in m-commerce
  • Apple customers are loyal; 80% of iPhone users have perviously owned another iPhone
  • iOS users tend to favor social media and retail apps, while Android users favor utility and productivity apps
  • iPhone users tend to identify as extroverts, and Android users as introverts

The cost of development

Development costs, no matter what platform you’re developing for, come down to three factors: time, hourly rate, and investment in infrastructure (like the computers used for development, or the servers that house your app’s backend).

The time it takes to develop an app can be further broken down into three determining factors: ease of programming, testing, and publishing (specifically the review of your app before it is officially launched).

Swift, the coding language all iOS apps are programmed with, is robust, streamlined, and was written expressly for the purpose of building apps for Apple’s devices. On the other hand, Android apps can be built by JAVA, C++, Kotlin, and Go (among others).

While the latter two of these languages were written with the same purpose as Swift (app development), JAVA and C++ have been around long before the idea of what an app is today had come to fruition. JAVA saw its public release in 1996, and C++ was released over a decade before that.

Since these languages are old enough to order a beer and not get carded, there are more programmers who can code for Android than iOS. While this does usually translate into a cheaper hourly rate when hiring Android developers, it doesn’t always ensure you end up with a smaller bill to pay.

There are conventions that no Android developer will break – but while there might be two, or possibly even three ways to write a feature in Swift, there’s a multitude of ways to code that same feature with JAVA (the most popular Android programming language). Due to this, when comparing the two platforms based on ease of programming, Swift tends to come out on top.

If you’re being incredibly thorough with testing your iOS app, you’re going to need about ten different devices (ranging from the iPhone 5s to the Xr, to the different iPad generations, and possibly Apple Watch). To achieve the same level of quality assurance for Android, you’d need 24,000 different devices (and there were that many in 2015!).

Realistically, a good batch of Android devices to test with are all the popular and currently used devices, plus as many others as you can get your hands on. But even when accounting for ignoring 23,970 devices, those thirty remaining Android devices still add up to at least three times the amount of devices that need to be tested against. Again, when it comes to testing, and the time necessary to properly do so, iOS comes out on top.

With so many devices necessary in order to properly test your app, Android apps can require a significant investment in infrastructure. It is definitely worth noting, however, that iOS app development requires Apple products, which means if you don’t already have iMacs or MacBooks, you’ll need to find a developer that does, or foot the bill yourself.

When comparing the cost of investment in infrastructure for both platforms, it really depends on what infrastructure you already have in place – if you already own Macs, iOS would be the cheaper option. If you already own a bunch of Android devices, Android will be the cheaper option.

What costs more to publish – Android or iOS?

Publishing an app on the App Store or Google Play is a drastically different process – Apple requires a stringent process to be followed before publishing – Android, in comparison to the App Store’s publishing guidelines, offers developers a much simpler route to publishing their app to Google Play.

Let’s go over the publishing process for both, and what these costs mean for you in both the short and long term.

Android publishing costs

Publishing your Android app to Google Play is a straightforward process. Android does review apps – but the approval process is automated, so it is relatively quick. Before officially launching your app on Google Play, you’ll want to create your promotional materials.

These are what make up the content on your Google Play listing, and are comprised of: in-app screenshots, teaser videos, graphics, and promotional text.

Next, you’ll choose your publishing options – this includes setting such as what languages you’d like your app to be listed in, as well as how much you want to charge for your app based on region.

Finally, you’ll confirm your options and promotional materials, and then push the “publish” button. In a few moments, your app will be available in all previously selected regions through Google Play.

In order to publish to Google Play, you must pay a one-time fee of $25, and Android also takes 30% of profits from paid an in-app purchases – updating apps is free, and updates to your app’s code aren’t usually review by a person.

When it comes to publishing an app to the app store, it’s an entirely different ballgame.

iOS publishing costs

First off, to get the easy stuff out of the way – if your app is going to be free (as in no revenue from downloads, subscription fees, ads, anything) you’ll only need to worry about: administering your App Store account, gathering your promotional materials, and your app’s review – after that, you can publish.

Publishing a free app to the App Store is largely the same as publishing an app to Google Play, other than without any of the associated publishing and sales costs.

Publishing a revenue-generating app to the App Store is a more involved process.

First, you’ll want to accept Apple’s payment agreements, and your tax and banking information.

Second, you’ll add your users to your App Store account, which can easily be done by entering their email. From here, you can assign privileges and roles – this will help with administering your app’s page on the App Store, which will be essential in order to manage your ASO campaigns down the line.

Third, you’ll add your app to App Store Connect – this doesn’t mean that your app is available for download, nor does it require your app’s code be complete. You can think of this as setting up your app’s profile page for the App Store. After adding a build to App Store Connect, you can upload multiple versions through either Xcode or Application Loader – you can then view these variations through your App Store Connect profile.

Next, it’s on to testing and submitting your app. While Apple does require a more stringent review process for apps submitted to the App Store versus those on Google Play, they do help with the setup of your app’s beta test.

By using Testflight, you can upload a beta version of your app to send to your testers – from here, you’ll want to go through the steps listed in our blog, All about beta testing: When, why, and how. After you have deemed your app ready for review, you’ll submit it to apple for their approval to the App Store. These are the guidelines Apple grades apps by:

  1. Safety – Apple looks for harmful or offensive content, data security risks, and much more. All of these risks are more carefully considered when the app’s main audience are children.
  2. Performance – Apple will be on the lookout for incomplete apps, if beta testing was indeed conducted, if your app’s metadata is correct, and if it meets hardware and device compatibility requirements
  3. Business – Apple will make sure your app follow all of their business, payment, and licensing rules.
  4. Design – Apple looks for copycat designs, functionality, if spam is used, and many other factors.
  5. Legal – Apple will search for any violations of it’s legal agreements, especially those relating to user and data privacy – this is especially stringent when the app’s main audience are children.

After submitting your app, a real human will review your app by these guidelines and more – if you are gearing up to submit your app to the app store, we highly recommend heading over there yourself before you do.

After approval, you can officially upload your app to the App Store! To publish an App on the App Store, you must pay a yearly fee of $99, and Apple takes 30% of profits from downloads (that 30% is only applied to paid app and in-app purchases).

It is also worth noting that for every update you provide for an iOS app, Apple must approve that update before it can go live. This review process is again conducted by an actual human being.

When comparing the two platforms based on time and cost to publish, Android is the winner. These differences do, however, influence other aspects of your app’s lifecycle, which we’ll cover a little bit later in this blog.

The cost of marketing

This is probably the aspect of launching an app that is least influenced by which platform you’re building for – but due to the centralized nature of Apple products and customers, iOS app marketing usually comes out cheaper.

This isn’t due to Android app marketing relying on different marketing channels than iOS, but rather the scale at which Android apps must market themselves. Because Android has such a large presence in international markets (one of the main attractors to the platform), you’ll inevitably spend more time and money marketing to those extra markets than the mainly U.S., Canadian, and western European markets iOS users usually reside in.

This is also influenced by the need to market your app in the native languages of those respective markets.

Longevity

Remember those strict Apple publishing guidelines? When it comes to getting the most out of the lifecycle of your app, those rules and regulations will actually work to your benefit. iOS apps are more secure, therefore they can be used for a longer period of time before being confronted with a vulnerability.

iOS apps are required to notify users of data collection, as well as receive their permission in order to do so. Because every update is reviewed by Apple before it can go live, users can always expect an update to provide meaningful, tangible improvements.

While these rules might seem strict initially, they’re powerful user retention tools. Privacy and data security are at the forefront of your users’ minds all the time, and generally speaking, iOS users can expect a higher degree of security from their apps.

One aspect of app lifecycle management where Android comes out on top is its open source nature. Because the platform itself is based around open source releases, and its core libraries are available to everyone for free, Android does have the benefit of unlimited potential for growth and innovation. In addition to this, because iOS is only available on the iPhone, iPad, or Apple Watch or TV, there is always a potential that Apple products will fall out of favor with the market.

If Samsung fails, Android remains strong. If Apple fails, iOS is gone. There is no indication that this is going to happen anytime soon, but it is worth noting.

There’s a time and place for everything

Generally speaking, if you want to access users in western markets, iOS development will be the cheapest option. If you’re looking towards international markets, Android will take the lead – at least when it comes to lifetime profits. But when accounting for time to develop and test an app, iOS will almost invariably come out on top.

Custom app development costs

/0 Comments/in , , /by

How much does it cost to develop a custom-made app? This is a question we are asked quite frequently – and the answer is so open ended that we felt it warranted its own blog. Regardless of what type of app you’re developing, there’s one factor that rises above the rest when determining the cost of software development – time.

And when it comes to custom app development, time still holds on as the key determining factor of your app’s total cost. There are, however, a few different aspects, features, and feature sets of custom app development that will take up more of your time (and therefore money) than others.

The time it takes to develop these features, however, is balanced by the fact that these features usually add a significant amount of profitability and robustness to your app. And often, the features are necessary to the key functionality and experience of your app.

Let’s get into those features.

Design

There’s a lot the word “design” can refer to when on the topic of app development – especially so when it’s a custom-made app in question.

When developing a custom app, every aspect of its design must be built out. While both Android and iOS have universal design libraries, custom feature sets require custom layout, custom graphics, and custom flow.

You should expect an app to take 100 to 150 hours to properly design – this estimate can change depending on the complexity of your app. Let’s look into what makes up all those hours:

Custom layout

Every custom app’s layout will be unique – while certain features will undoubtably share some implementation styles and guidelines (like the iOS Human Interface Guidelines), a custom-made app will solve its pain point using a uniquely-implemented feature set.

You can think of your app’s design as the interactive guide that leads users through your app’s feature set. It’s the links in the chain of your user flow – just as it’s the process of visual cues that make up your app’s UX.

I’ve used this example before, but I feel it’s a good one; an app is like a choose-your-own-adventure book, and its design is the language that indicates to users what choices are available to them.

When designing your app’s layout, keep a few things in mind:

  • A user’s location, situation, mood, and method of interaction
  • What the overarching purpose of your app is
  • Your main user story

The most important thing you can do when laying out your app is to ask yourself: “How would I want an app to solve this problem?”

Then, when conducting market research, make sure to ask others the same question. Figure out what scenario users will most likely find themselves in when interacting with your app – that is your main user story. Design your app’s layout to this user story.

Custom graphics

In a similar vein as “design,” the word “graphics” can mean a wide variety of things when used in reference to custom app development. An app’s design is compromised of:

  • Your app’s logo
  • Individual icons, e.g. “home,” “map,” etc.
  • “Furniture,” i.e. reoccurring graphical elements like button styles or border styles
  • Fonts and type treatment

Some other categories that fall under graphics, but aren’t as common as those listed above:

  • 3D graphics
  • Augmented Reality (AR)
  • Virtual Reality (VR)
  • Level design (specific to games)

The real craftsmanship of design is knowing how to make an intuitive, interactive visual experience – and doing so takes time. Uniqueness is a strong suit of custom developed apps, and graphics and other visuals are the most effective method for portraying your app’s individual brand.

Don’t be afraid to take the time necessary to develop your custom app’s design. A picture is worth a thousand words – a well made icon is worth one thousand lines of code.

Application Program Interfaces (APIs)

APIs can be thought of as pre-made feature sets – some are customizable (to a point), and others aren’t. Perhaps the most well-known API is Google Maps – it can integrate with custom apps in order to provide that app with GPS, mapping, and navigation functionalities.

Through the Google Maps API, developers can customize elements of the API’s Javascript to control visual elements, such as map colors. Rather than coding for hundreds of hours, developers can use the Google Maps API to provide the same (if not better) functionality, all without users leaving their custom app.

While APIs most definitely save developers time, they do usually come with at least one type of reoccurring cost: either a subscription fee, or a data usage fee – and sometimes, both.

Due to these reoccurring costs, the inclusion of APIs in your custom app can lead to significant costs down the road – and as your app grows, these costs will more often than not scale up as well. Be careful with your selection of APIs too – if a third party API your custom app utilizes is deemed as unsafe, not secure, or predatory by the App Store, your app will be removed from the App Store until the problem is resolved.

Also, keep in mind that if an API provider’s services are down, so to will that portion of your app’s functionality disappear – so, depending on how crucial that API is to your app’s experience, you could lose most of the functionality of your custom app.

It is worth mentioning that despite the inherent risks and costs associated with API backend integration, using APIs will save you an incredible amount of time during your custom app’s development phase; and let’s face it – Google is going to make a better navigation system than most companies.

Don’t be afraid to utilize APIs – but also balance the risks, and do your research before implementation.

Backend development

Building out the backend of an app will take up (depending on the complexity of your app) a significant portion of your app’s total development time and cost.

Backend development, in a very generalized sense, can be thought of as hooking up the features your app’s users interact with to different programs, servers, or even other apps entirely.

Fun fact: if you’re developing a custom app for both Android and iOS, you’re actually developing two different apps – Android runs on JAVA, and iOS runs on Swift.

For example, in order for an in-app messenger to send messages back-and-forth, it needs to be connected to a server that can take in and send out data.

Let’s get more into some of the most time-consuming aspects of backend architecture and integration:

Backend architecture

We’re not going to go too deep here – this subject could easily be its own blog. In fact, keep a lookout for something about that in the future.

Your backend architecture is, in short, how all of the different systems, infrastructure, and programs that make up your app’s backend fit together. You can think of it as a puzzle – a vast, digital puzzle with pieces made from code, servers, and APIs.

Backend servers

Your backend is hosted on a server – this can either be comprised of a single server, many, or hosted through the Cloud. Servers are used to store and transmit the data that your app needs in order to function – this can range from data tables that keep track of sales numbers in an internal business app to features like interpreting and sending out data through real-time updates for a gaming app.

Your server’s hosting comes with two costs – your costs associated with purchasing or “renting” server space, and the maintenance that comes with along with using a server. Your server’s maintenance will undoubtably be the larger of the two costs, and you should expect it to be a reoccurring one – servers require continual, regular upkeep.

Time, and time again

This is the last time we’ll state it (in this blog, at least) – time is the most significant factor when determining a custom app’s development costs.

The processes and features discussed above are some of the most cost-intensive aspects of app creation – but with every app’s development will come unique situations, and therefore unique budgets.

There’s a lot more to developing a custom app than what we covered here. If you’d like a roadmap to app development, check out our blogs on easy app development and the steps to creating an app.

Meet our newest CBO

/0 Comments/in /by

We’re here with our newest CBO – Flea Van Schaack. We’ve been searching for a Chief Barking Officer for a while now, and we’ve finally found the perfect fit! Ever since we brought on Jacapo Lingenfelter as our CTO (Chief Terrier Officer), we’ve been searching for our next addition to the team.

Flea has been with us for just over a month now, and we thought it was a good time to share what Flea has brought to NS804 in the short time he’s been a leading member here.

First, tell us a little about yourself:

Yeah, sure thing Kate! First, I’d like to thank you for having me here – It’s been a really exciting first month, and I can’t wait to talk about it. I know you’re busy, so I’ll try to keep everything as quick as possible.

Um, thanks Flea – but I’m just doing my job.

Yeah, great! Well – um, sorry, this is a little awkward – I tend to try and stay humble. You know, being a good boy and all that.

So, when I was growing up, I always knew I wanted to help make people’s dreams a reality – I went to school and graduated with a degree in business leadership – I was hoping to start my own chew toy company. I figured, “Hey, I’m always dreaming about chew toys. I should make my own and help make other people’s dreams come true.”

Well, long story short – turns out the market out there is ruff.

And that’s when you decided to start working with NS804?

Yes – I appreciated that our goals aligned so perfectly. I mean – it even says it right there on our conference room sign: “Making dreams a reality!”

How much more perfect of a fit could you ask for?

What’s your favorite part about working for NS804?

I want to say it’s about the chew toys – I really do. But if I were to be honest, it would be the people I get to work with. They say a good manager works for their employees, not the other way around. I always make sure to carry that advice with me – I find the harder I work for my team, the better everyone feels, and the better work we produce.

When you’re working at a company, and you’ve got that capital “C” at the beginning of your title, this is especially important – I could talk all day about the technical and strategic side of what we do here – everything from perfecting new peer-to-peer data sharing techniques to managing the backend for a significant number of apps.

I always make sure to take the time every day to check in with my entire team – keeping up with your employees is hugely important for team cohesion and individual productivity.

What are you most excited about for your future with NS804?

Oh boy – there’s so much I’m excited about! But, if you’re going to make me choose just one thing… It’s a new full package ASO program we’ve been working on. I’m not allowed to say too much about it – but we’re excited about the implications this new project will have on user acquisition and conversion rates.

How to: Build a MVP startup

/0 Comments/in , , /by

Sometimes, the only thing stopping a great idea from seeing the light of day (and consumer’s eyes) is a little know-how. If you’ve had a great idea for a MVP app for a while now, and want to start your own business based around it – but have no idea where to begin – we have the answers for you!

Below, you’ll find your roadmap detailing how to build a MVP startup app.

A strong MVP

The stronger the idea behind your MVP, the better your chances are at achieving success. While there’s no strict formula for coming up with a good idea, there are qualities most good ideas have: stickiness, simplicity, and legs.

If none of those words made sense in context, don’t worry. Their explanations (as well as the definition of a MVP, in case you don’t know) are coming right up:

First of all, a MVP, in regards to an app, is an app that focuses on providing an experience through a set of features that play a direct role in solving a user’s pain point. A MVP app has enough design elements to provide a good UI/UX for the user, and is a viable product unto itself. It is, however, a minimal version of said product, and offers little functionality other than that which helps to solve the main pain point.

Good ideas tell a story

So, what about those qualities mentioned earlier? Urban legends, ghost stories, and memes are all perfect examples of ideas with all three of those qualities: stickiness, simplicity, and legs. Let’s look at the idea behind everyone’s favorite supernatural-bathroom-mirror-murderer: the Candyman.

The idea of a man filled with bees, crawling out of your mirror and attempting to grab you with a hooked hand is a pretty difficult image to get out of your head. It’s a simple idea – tempt fate by saying his name three times in a bathroom mirror, and he’ll come to get you.

It’s got legs as well – the story of the Candyman is highly replicable. This is because it uses a well known setting – the bathroom – and uses concrete, reliable, and common features as details to ground the story in reality. All a story teller needs is a little imagination to truly paint their audience a picture; and because audiences are so familiar with the territory of the bathroom, they can fill in details themselves, and tweak the story to their own tastes.

That audience will then go out and spread the idea again – it’s memorable, simple, and replicable.

Now, you’re not here to sell ghost stories – but good brands share these same qualities. For example, let’s look at Nike’s “Just Do It.”

It sticks in your head – it’s a powerful statement, with no room for interpretation; if you’ve got an obstacle in your path, your determination is all you need to surpass it. Their slogan is simple as well – it’s three words, all single syllable, all easy to understand.

Finally, it has legs; “it” is an incredibly diverse word, and because of this, “it” works for any product Nike sells – whether they’re selling shoes or hats – and whether their customers are skateboarding or playing soccer, “it” is getting done.

Sticky apps

Now, let’s take that urban legend example, and do the same thing with a well known app… let’s go with Uber.

First, Uber is a sticky name – it’s fun to say, fast, and carries the wonderful connotation of “great” with it. The idea behind the app is sticky as well; all a user has to do is hail a cab with their phone, and soon enough, a car will be there for them. Most of the time, they don’t even have to talk to anyone – the task is simply completed with a few button presses.

To put it simply, it’s a simple idea: press a button, get a cab.

Due to the idea behind Uber being so simple, the app itself (in regards to UX) is simple as well – over the course of interacting with only a few different screens, a user can get a ride from one side of town to the other.

The simple experience Uber offers is the reason it (and other services like it) are handily beating out traditional taxi services – pressing a button is much easier than searching for, and then hailing a traditional cab.

Finally, Uber most definitely has legs. The app serves two different user groups in a highly replicable way – one user group gives rides, while the other takes rides – and both user groups are likely to return as Uber customers, as drivers’ economic pain point is solved by riders, and riders’ transportation pain point is solved by drivers.

Perhaps the reason for Uber’s market-shattering effects was due to its market viability – because it was the first app to shake up the taxi industry, it was able to gain users with zero competition until other companies could eventually catch up.

This feature set would create a system for raccoons to share advice with each other, as well as a community based around the app.

An untapped market is the perfect opportunity for a MVP app; and because of this, Uber is the perfect example of how to build a startup around a MVP.

It’s essential, however, to make it clear that being the first doesn’t ensure that you will remain in first place – someone can (and often will) come along and do what you do, but better. App users are fickle, and are more likely to abandon an app than they are to continue using it.

Because of this, if a new app does come along and implement even just a single feature better than your app, users will migrate to the new one – in order to combat this, you must always continuously update your app. This means everything from security updates, UI changes, and sweeping, innovative changes to your app’s UX.

Product Validation

There are two different audiences that must deem your app as viable: the marketplace, and your intended users. The purpose behind receiving validation from these audiences is to ensure your app has a place to live, and value to bring.

Let’s get into what being a viable product really means:

Marketability

There are a few factors that come into play here, but the most important (when it comes to a MVP app’s market viability) is competition.

There’s three reasons to go with MVP app development: lack of budget, proof-of-concept, or speed to market. Sometimes, it’s a mixture of these factors, and other times, it’s all three. But while MVP apps do significantly reduce your development costs, and do serve extremely well as a proof-of-concept for potential investors, a MVP app’s real strength, as stated previously, is due to its speed to market.

If there’s an audience of users deeming a product as viable, and no competition for a share of that audience, you can use a MVP model of app development to ensure you beat anyone else to the punch. When you’re the first brand to provide a solution to an audience’s pain point, you’re more likely to build customer loyalty than the third or fourth contender.

If you are the third or fourth contender, however, you’re also in a perfect position to strike – conduct your own competitor analysis of apps that do what you plan to do with yours. Then, come up with better ways to implement the solution to your pain point. When you’re entering an already tapped market, competitor research isn’t just necessary – it’s your ultimate weapon.

Consumer viability

In order to determine who your niche is, you must first determine where your niche is. This is important to keep in mind, as sometimes, a specific audience might invalidate your product – but this doesn’t mean every group will. If your idea is rejected, it doesn’t mean it’s a bad product. You might just be talking to the wrong people.

To better identify your target audience, you need to know your app’s user journey.

The user journey

If Uber had marketed the driver side of their app to professional taxi drivers, and the user side to suburban, middle-age, middle-income mothers, it probably would have flopped. Taxi drivers have no use for the app, as their customer base flags them down visually. Suburban moms usually have their own transportation, and rather than needing rides to places, they are usually giving rides themselves.

Uber made the splash it did because it understood its user’s journey. While there are multiple Uber customer types, their main base is urban, younger, on-the-move, and lacks one crucial thing: private transportation. They have enough money to be able to afford something more expensive than the subway or bus, but don’t have the funds (or lack the space) for their own car.

That’s a very different audience than suburban moms. The timing of the 2008 recession, and Uber’s 2009 launch were extremely beneficial to its success as well – and the gig economy owes a significant debt of gratitude to Uber.

Uber took advantage of a market overflowing with available labor – if you had a car, you could work. You could set your own hours, and work around another part time job. With so many young people in 2009 either un-or-under-employed, Uber was able to grab hold of a significant amount of users for the driver side of their app.

They were able to make all of these smart decisions because they understood the user journey of their app. The best way to determine your user journey is to ask yourself; “What would I want this app to achieve?”

Then, go out and ask people what they think. Let your intuition guide you to the right audience – and then, let your audience guide you to the true pain point.

Understand your success criteria

This might seem pretty obvious, but knowing what makes your app successful is important – knowing your goals will give you the data you need to measure your success.

You define what a successful MVP app looks like – whether it’s number of downloads, user retention, or a workable proof-of-concept for investors.

Keep it simple

If a MVP app were to be compared to a football play, it’d be a Hail Mary. There’s really only one point to all the plays, picks, and blocks that happen in a game of football – to get the ball to the endzone. A Hail Mary, just like a MVP app, achieves that purpose using the simplest method with the least amount of steps possible.

If you’re building a startup around a MVP app, think of it as a Hail Mary – the faster you release your app, the faster it gets to your audience, and the farther it spreads among them.

Easy app development

/0 Comments/in , , /by

How hard can developing an app really be? They’re pretty much just mobile versions of websites anyway – going the route of hybrid or web based apps should save both time and money, right?

On the surface, these assumptions would seem correct – but for many reasons (which we’ll get into below), taking short cuts or going with a route other than native development will actually create more headaches, and ultimately make your app’s development more difficult.

What about going easy on the market research? Surely apps don’t need to include a traditional marketing budget – that’s what the App Store is for.

Things sure would be easier if that were true – apps require fully fledged ASO campaigns in order to survive against their competition.

There’s a lot that goes into developing an app – and we’ve never said it was easy (in fact, we’ve said the opposite in the past), but we’ve put together the info you need to know in order to make sure your app’s development is as easy as possible.

Fish out of water

Who’s the better swimmer – a penguin, or a dolphin? The dolphin will win in the water every time. Now, I’m not trying to take a shot at penguins – they’re way better at swimming than I am – but they exist in a space between land and sea. They’re never truly in their element; they’re clumsy at best on land, and when in the water, they’re hampered by adaptations specific to land animals.

In essence, they’re very similar when compared to both a hybrid or progressive web app. There is no argument that your initial costs will be lower when going the route of hybrid development; but over time, a natively developed app will perform better than a hybrid on many fronts.

When measuring for usability, performance, security, and maintenance, a native app will beat out a hybrid every time – just like, and for the same reasons as, the penguin vs. dolphin match up.

Visit our blog for a more detailed explanation as to the benefits of native over hybrid development.

Before you find a developer

It’s time for the first step in building your app: finding a pain point. Every app helps to solve a problem in someone’s life – mobile games stave off boredom, fitness apps help to solve our issues with laziness, and navigation apps provide the answer to “How do I get around this accident?”

No matter what your app does, when you boil it down to its true essence, it helps people solve pain points they are faced with throughout the day – or if you’re making a sleep tracker app, throughout the night.

But ultimately, your app helps people. If you’re making a mobile game, the formula is pretty simple – build an app that’s entertaining enough to make people want to play it to pass the time during their morning commute on the train.

For more complex concepts (ideas, not apps – mobile games are some of the most technically complex apps out there), the process of ideation becomes much more involved. Unless you’re developing an app based on inspiration that came to you from facing a pain point in your own life, the easiest way to come up with a (good) app idea is to conduct some…

Market Research

Now, in order to know what to research, you’ll need at least some form of an idea of what you want your app to do – but market research will help you narrow down that broad idea into a marketable product.

Let’s pretend we’re making an app for raccoons. We don’t know too much about the raccoon life – but we’re going to go out on a limb, and guess that this app is in some way going to revolve around getting their little paws on some trash.

We honestly don’t know what the raccoons want, however, so we need to go to the source – unfortunately for us, most of the focus groups and field research probably won’t be held in the cleanest venues.

Okay – so, it turns out, according from our totally real research, that raccoons do indeed face a pain point when it comes to trash acquisition – it isn’t, however, the pain point us humans would expect. Finding the trash isn’t the problem – our target audience’s noses are fine tuned for that sort of work.

Raccoons need an app that gives them the ability to leave other raccoons instructions on how to open the dumpsters that hold all that delicious garbage. As our market research shows, finding the trash isn’t the problem – accessing it is.

So now it’s time to figure out the solution to the trash acquisition problem.

Designing your app

There’s two separate times you’ll design your app – the first instance being the step we’re currently on: user stories.

A user story is the step-by-step process a user will take when interacting with an app. In our case, it would be a raccoon currently stumped by a particularly stubborn dumpster lid.

There are a few things you need to think about when coming up with user stories:

  • Location
  • Situation
  • Mood
  • Method of interaction

The location and situation your users will be in when interacting with your app matters – as well as the mood you can expect them to be in. In our case, the location, at least most of the time, will be back alleys, and mostly at night. We can expect our users to be hungry, and therefore impatient.

Now, with a clear picture of the situation, location, and mood our users will be in, we can start designing the flow of our app.

First of all, we need to revisit the pain point; raccoons want the ability to share advice with each other on how to open up dumpsters, in order to get to trash faster.

So, now we need to design a feature set that will help to solve that pain point. Our app must include:

  • GPS and mapping, as well as location services, in order for users to place beacons on a map for other users to select
  • Camera and microphone access so users can take photo and video instructions
  • Back end integration so the app itself can host photo and video media
  • User profiles that can be rated based on the advice they provide

So, add all that up, and you get an app that allows users to pin video and photo instructions to specific dumpsters based on their GPS coordinates. Other users would then be able to vote on the provided advice, which would then be posted to that user’s profile.

This feature set would create a system for raccoons to share advice with each other, as well as a community based around the app.

Time to build

Next, you’ll want to take your research and user story, and bring it to an app developer. From here, they’ll be able to take your idea and run with it. From here, development is pretty much out of your hands – you’re there to give the thumbs up or down.

A full, in-house development shop will usually start by designing the layout of an app with wireframes, and then flesh out the design. Once the design for each screen has been finalized, a prototype will be built – this is for you to look over, so you can make sure their interpretation of your vision is accurate, and to the spirit of what you imagined.

The developers coding your app will reference the prototype as well – and from it, they will build the actual code of your app. After your app is coded, it will move on to testing, and from there, it’s on to…

Launch

Remember when we brought up ASO? This is where you’ll want to implement those efforts. There’s a lot that goes into an ASO campaign, and if you’d like to take a deep dive on the topic, here’s a blog all about it.

ASO, at its core, is keyword research and implementation. It’s just like SEO, but for the App Store and Google Play. We recommend new apps start with five keywords to focus on – and from there start evolving your ASO campaign with strategies ranging from A/B testing to push notifications.

The key to a long-lasting, successful app is frequent updates. Once you’ve launched your app, you’ll want to get right back to developing it – top performing apps update regularly to stay on top of design trends, security issues, and new devices.

This is a big reason native apps are more cost effective and easier to develop than hybrid – maintaining and updating a native app is a much simpler process.

The tortoise and the hare

If you’re developing an app the right way, there’s no such thing as easy development. You can, however, save a lot of headaches and backtracking by carefully planning and building your app. Do as much research as you can, and continuously test your app as you build it. Remember – slow and steady wins the race.

How to: Get a low cost app developed

/0 Comments/in , , /by

What’s the key to low cost mobile app development? Preparedness. But how are you supposed to know how to prepare if you’ve never built an app before?

Well, as soon as it began, your search is over – below, you’ll find a step-by-step guide to the quickest and most affordable model of mobile app development: MVP.

Really quick – before we get into it, let’s go over what a Minimum Viable Product is (when it comes to apps, at least). A MVP is an app that focuses on solving its main pain point, and very little else. All features, design, and graphics focus on helping to provide a solution to the main pain point – hence the term “minimum.”

MVPs do one thing, and they do it well.

Now, here’s how you make one:

Step 1: Research

This is all about how to build an app for the lowest cost possible; and the key to all development costs boils down to one singular ingredient – time.

Your app’s design is crafted through a combination of creative thinking, mouse clicks, and keystrokes; your app’s code is built by process-oriented imagination, and a whole lot of keys being pressed in rapid succession on a keyboard. There’s nothing magical about the development of an app.

Now, this isn’t written with the intention of giving the impression that developing an app is easy – quite the opposite, in fact. Building an app is kind of like writing an interactive choose-your-own-adventure novel, but it’s written in a language computers can understand, while also remaining readable for us humans.

And in order to pull that off in a streamlined, cost-effective manner, you need to complete all of your research before going to a developer with your app.

Find out why we recommend against using services like Appy Pie or app design templates to build your app.

The first step to research is…

Determining your pain point

All apps are beholden to one goal: solving their pain point. For a MVP to be a MVP, however, it must only provide the solution to its pain point. Any feature included in a MVP app must play a role in helping to solve this problem – this is to ensure no time is wasted spent developing out features that aren’t truly needed for users to receive enjoyment and benefit from your app.

The reason this is your first step taken on the road of app development is because everything that you do during the development process will be determined by the pain point of your app – from the market research you conduct to the features your developers implement.

A good pain point is both marketable and actionable – meaning there’s an audience or group of people who want a solution to this particular problem, and are willing to do something about said problem.

Let’s say you’re making an app like BrewTrader – just for some context, it’s an app that gives craft beer enthusiasts a platform to find and trade beers with other users.

Take a second to analyze that sentence. You know you’ve come up with a good pain point when you can explain the whole idea of your app in one sentence. Think of it like a thesis statement; if you can’t construct a grammatically correct sentence that covers the entirety of your app’s functionality, your MVP isn’t focused enough. It should be succinct, but meaty.

After knowing the problem you want to solve, and how you want to help solve it, you can move on to the next step of research:

Competitive analysis

This step serves two purposes – it gives you an idea of what your competitors are currently doing (obviously) – but more importantly, it will serve as a roadmap for ideating your app’s feature set.

If you want your app’s development to be quick, (and therefore low cost), you’ll need to know every feature your app will utilize; this includes knowing details like where in the user flow a feature will exist, how it will interact with the user, and if you’ll need supplemental features or APIs in order to properly implement the original feature.

Download the top three competitors and use their apps for at least one session from start to finish. Get an understanding of what they do correctly, and make a note for later. Then, go find the lowest rated app (be careful about security risks) in the same category, and pay attention to what they did wrong.

Knowing what’s incorrect is just as important as knowing proper UI/UX design. It helps to prevent you from making a decision that might seem like the makings of a previously-unimagined and creative UI/UX solution – but there is more than likely a reason the top performers use the UI/UX flow they already have.

Also, begin your ASO research now – pay attention to keywords the top competitors are using. When starting out with a new app on the App Store or Google Play, pick five keywords, and focus in on those.

Market research and marketing

There’s a million different options for conducting your market research, but some key data to be aware of are:

  • Target age range (different age groups respond to different mobile marketing strategies)
  • Target preferred platform (we recommend iOS if you’re starting with a MVP)
  • Target interests

As soon as you know what your app will be called, you have a logo, and you have a description of what your app will do, build a website. Even if you only have content for one landing page, make it, and make it live.

SEO takes a while to take hold, and having something to link back to within your social campaigns will help to build a solid SEO foundation. Apps on the App Store and Google Play require both SEO and ASO to thrive – so don’t neglect either.

Speaking of social media, you’ll want to make sure you’re putting out as much content as possible. Speak to the voice of your app’s brand, of course, but don’t be afraid to open up a little. Everyone understands that when they’re interacting with a brand’s social media account, they’re talking to an actual human being.

Be open and honest and genuine – know your target audience’s interests, and speak to them. To steal advice from Gary V, if they like the Red Sox, talk about the most recent Sox game. Engage with your followers more than you advertise to them. Then, every once in a while, sprinkle in some native content that speaks about your app’s brand, or the features it will provide, or where you are in development.

People love documentation. You can easily create content for social media by documenting the journey you’re on through the development of your MVP app – take one long-form piece of content, and build a few pieces from it each day. Then cater those pieces to each social platform your brand is on. All of a sudden, you’ll be running a fully-fledged social campaign based on a single piece of content (that you didn’t even have to take time out of your day to make).

MVP development

Whether you’re developing an MVP app or a fully-kitted-out enterprise level app, the actual process of coding remains largely the same – the only difference is the time table, which is shorter with a MVP, due to the limited feature set that needs to be built and implemented.

The importance placed on knowing your feature set in and out comes into play here – the most effective and efficient way to ensure easy, low cost app development is to make sure there’s no unanswered questions between your vision, what you want, and how you want it to work.

The clearer of a picture you can give, the more information, and the more concrete of a user flow you can produce for a developer, the better. It’s always important to take your developer’s advice, but relying on your own research and business acumen can help speed up the process.

One thing to keep in mind with (and this is specific to) MVP development is that everything doesn’t necessarily have to be perfect. Don’t confuse this with the idea that it’s okay to make a sloppy app – but understand that as long as your users know that your app is in a semi-beta stage, they’ll be more forgiving.

This is why a strong, personal, and open social media presence is so crucial to a MVP app’s success; in order to properly distribute the message that your app is starting with humbler-than-most beginnings (but improvements will be coming), you need to be able to have frank, honest, transparent conversations with your followers. And, they need to be willing to listen.

The purpose of a MVP app is fast, efficient development – the efficiency truly begins to shine after a MVP app’s initial development.

The second word in the acronym MVP is viable. It might be the most barebones version of a product, but it’s still viable. What this means for you is that you can charge for it. Whether your app goes with a pay-to-play model, or subscription to a service, or with sales from ad revenue, you can begin to make a profit from your MVP as soon as it takes hold on the App Store or Google Play.

Post MVP development

As soon as your app is launched on the App Store or Google Play, make sure:

  1. Your ASO is in place and ready to go
  2. Your website reflects the launch of your app
  3. Your social media has (and will continue to) promote your app’s launch

Take the revenue you’re making from your live MVP app, and start implementing updates. Make sure updates focus on fixing bugs, fixing security risks, and providing quality of life improvements to the UI and UX flow.

Be vocal and transparent about what your updates will accomplish and feature – use both social media and push notifications to advertise these updates.

Be aware that when you’re advertising, you need to be extremely aware of just who you’re engaging with. Older generations, like generation X, prefer value-based advertising. As your target market gets younger, they will expect more personalized advertising – in order to properly do this, it’s necessary to use an app analytics platform. Our favorite is Kumulos.

Be prepared, but be ready to adapt

Knowing what you’re getting into is the most important step you can take to ensuring low cost development – but, always be ready for something unexpected to pop up.

To learn more about the in’s-and-out’s of MVP app development, check out our blogs on:

And, for more about planning out an ASO campaign, check out our ASO: 101 blog post.

With carefully planned feature sets, a concrete layout and vision, and some well-planned and executed social media, SEO, and ASO, you can both shorten your app’s development schedule, and lessen your need for monetary investment; giving you the ability to make an app now, and capitalize on an untapped market – rather than waiting for outside investment and finding a highly competitive and saturated playing field.

Improving your employee training process with an internal business app

/0 Comments/in , , /by

An enterprise level, internal business app is the perfect solution for innovating your company’s employee training. More accessible and less resource intensive than traditional employee training programs, internal business apps are, most importantly, much more cost and time efficient than their traditional predecessors.

Internal business apps provide a platform that empowers the growth of your employees – as individuals, professionals, and team members – all scalable, and all within an affordable budget.

Before we get into the how of this topic, I want to cover the why:

The psychology of self-fulfillment apps

Just what is a self-fulfillment app? It’s any app that helps an individual better themselves – while they exist in different spaces, fitness trackers and internal business apps would both fall into this classification.

In fact, when implemented correctly, the structure and UX of the training portion of an internal business app should closely resemble that of a fitness app.

They’re very similar to each other, especially when the internal business app is used to provide or enhance your employees’ training – and just like a fitness app, your internal business app’s training program should focus on rewarding your employees for reaching action or comprehension milestones while on their path of growth.

Why is this? Just as fitness apps use this milestone method to increase user engagement and retention, so too can your internal business app. While employee training might be a virtually mandatory step in the hiring process, this doesn’t mean employees are highly – or sometimes, even moderately – engaged with the process.

With many new positions, employees going through training can find themselves inundated with excess amounts of new information – this can lead to overload, or even to your new employees tuning out for the rest of their training.

By implementing a rewarding, individually-trackable training experience for new employees, you can rid your company of these systemic issues. The best part is, this process doesn’t have to come to a close – internal business apps can empower your employees’ growth throughout their entire career at your company.

Let’s get into some concrete examples:

On-boarding

Imagine being able to start new employee orientation as soon as they’ve signed their offer letter. Along with the email you’ve sent, you can also include a link to your enterprise app. From here, the new employee can complete paperwork that usually takes up a significant portion of their first day.

During this first touch your new employee has with your business’ internal culture and processes, you can adjust the amount of guidance to whatever fits your needs – from live chat features to video calls. Or, you can go the fully automated route, if this portion of your on-boarding needs to be streamlined.

As your new employees progress through orientation, your app can act as their own guide, keeping them appraised of what’s coming next in the training process. This helps them prepare before hand, lessening the time spent introducing the topic that is about to be taught, or from scrambling for necessary resources at the last minute.

Your internal app can also act as a reference point during any step in the new employee training process, allowing new employees to find answers without interrupting training sessions.

When new employees have the power to look back and see the entirety of what they’ve learned (as well as the ability to reference the details of your business’ processes), they’re less likely to feel overwhelmed, and more likely to feel in control – and therefore, are more likely to fully engage with their training.

New employee on-the-job training

While nothing beats human interaction when being taught a new subject or process, an internal app can enhance the efficiency of your new employees’ on-the-job training. Very rarely does a co-worker or manager have carte blanche access to their schedule for a day; so when that new employee is inevitably faced with a situation where they don’t know how to proceed, and the employee training them isn’t around, they can reference the provided guides to handle the problem themselves.

This improves efficiency twofold; your veteran employees can spend more time doing what they do best – producing product, and bringing in new customers – and your new employees can solidify their knowledge retention by having the ability to answer their own questions.

This is very similar to an already tried-and-true method of information dissemination tech companies have used for over a decade – Stack Overflow. Tech companies are extremely process oriented – both when it comes to budgeting for labor, and the structure of code. In order to improve efficiency, developers will upload coding solutions to Stack Overflow for other developers on their team to utilize and learn from. This helps ensure stronger code, as well as increases efficiency for new employees and their team alike.

When new employees have the power to find the solution to a problem they face on their own, they’re much more likely to ask the question in the first place, rather than ignore the issue until it becomes an endemic problem.

Even better, you can cater these reference materials to different learning styles and situations – everything from pre-recorded video to simple presentations, or even tech documents and spreadsheets – these are all viable forms of information dissemination through an internal business app.

New employee on-site, real-time training

While it might not be realistic for every businesses’ budget to implement AR headsets for every on-site worker (like BMW and their mechanics), it is within the realm of possibility for a company to implement a few for new employee training purposes.

In a blog we wrote earlier this year about MxR and its implications for labor-based jobs, we touched on the experience Cnet’s Ian Sherr and Scott Stein had with Microsoft’s HoloLens2, which they reported to feel like “practical magic.”

Why did it feel like magic, and what does an AR headset have to do with new employee training?

MxR headsets now have the ability to interact – in real time – with the environment around the wearer. Both Sherr and Stein – neither of whom claim to be auto mechanics – were able to complete a set of repairs on an ATV engine with live guidance from a HoloLens2.

What this means for your business is a more efficient use of labor hours when bringing a new employee into the field. Your veteran employees can, again, spend their time doing their jobs while the new employee is guided by a real-time, accurate system that provides step-by-step, visual directions.

Continuous learning and growth

Perhaps the most exciting aspect of an internal business app’s training capacity is its ability to be included with the other processes your enterprise level app provides – like inventory management or culture and communication.

When something new is added to your business processes that everyone needs to know, you can send out a push notification with a link that brings all of your employees to the new information – or, you can segment targeted information to the team that needs to be in the know, in order to maximize the efficiency of your other employees.

Employees, at any moment necessary, can reference all of your training materials at any point in their careers – which keeps bad habits from forming, and helps re-align inefficiency.

As your employees foster a culture of continuous learning, new employees will be more readily brought up to speed, as information given to them is guaranteed to be uniform, and standards are always expressly laid out, in plain view for everyone in your company to view at any time.

Scalability

Most impressive is an internal business app’s scalability and reach – when all of your employees have access to everything they’d ever need (no matter where they are or what they’re doing), you can ensure every employee receives the same standard of training.

This is especially beneficial for offices that work remotely from each other, as it can save countless hours of deciphering one another’s work. Process uniformity can have a positive impact in localized offices as well – but when working remotely, this issue is more profound – and therefore, the solution is more noticeable.

An internal business app’s training capabilities are also scalable on a sense of time – it’s incredibly easy to enhance your training methods, as well as the information provided to new and old employees alike.

A personalized, yet uniform employee training experience

That’s what your new employees get when your business uses an internal business app to enhance or provide new employee training. Not only does this benefit employees at the beginning of their tenure at your company, it helps to ensure a uniform continued growth path for new and old employees alike – whether or not their orientation was through your enterprise level app or via a more traditional route.

Internal business apps give your company the ability to cater to different learning styles, without holding separate training sessions – new employees can watch a video explaining your data management system all while reading along with the provided tech doc, or reference slides instead – whatever works best for them.

With an internal business app’s gamification of the usually (let’s face it) less-than-exciting process of learning a company’s operations – as well as the ability to track and reference past accomplishments and knowledge, and easy scalability for any business model – improving your business’ new employee training with an internal business app is achievable for any company’s budget.

How design impacts mobile cost

/0 Comments/in , /by

Did you know a full service development shop will put, on average, 100 to 120 hours into designing an app’s UI/UX? That’s a significant amount time – and when dealing with large scale apps, such as social media platforms – or even larger design projects, like mobile games, design hours can skyrocket into the thousands of hours.

Let’s look into why this is.

The process of designing an app

There’s a step-by-step process most mobile design teams will follow, starting from even before rough sketches. This process dictates the workflow from the first hours of working on a project all the way to building the UI/US itself in the actual code of the app.

Let’s go over those steps:

Doing your homework

First things first, do your research. Designers will usually spend at least a few hours looking at apps that exist in the same space as the one they’re about to design. This is done for a couple reasons; there’s no point in reinventing the wheel, and it gives designers a good grasp of what app users have already come to expect from apps in the same category.

With this information, designers are able to take what works from those competitors, and after critical analysis, determine what they can improve upon, or what can be changed to fit the brand of the app in order to provide a more meaningful experience. There’s another added benefit to performing a competitor analysis before starting design – it helps the design team avoid stepping on the toes of any IPs.

Logo Design

Unless the design team is working on an enterprise level app for an already existing company, you app is most likely going to need a logo for the App Store or Google Play. A good development shop will have the capability to design you app’s logo – and it’s a good idea to keep this part of the design process in-house.

Designers are specialized, just like any profession – there’s a reason the tech industry distinguishes between web dev and mobile. A print designer will make a good looking magazine, a t-shirt designer will make a cool graphic tee, and a UI/UX designer will design a logo optimized for ASO, user acquisition, and your app’s brand.

Depending on your app’s brand, designing a logo can take anywhere from 5 to 50 hours.

There’s a lot we could talk about when it comes to properly designing a logo for an app. Maybe we’ll cover it, down the road.

Wireframes and layout

If you’re not familiar with the term wireframes, this step starts out as the “sketching on the back of a napkin phase,” and ends with a fully structured (at least visually) app. This step in the design process can take from 20 to 50 hours, and if it’s a large, complex app, even longer than that. While this is a significant amount of time, it’s absolutely necessary, and critical to the success of your app.

I’d go as far as to argue this is the most important step of visually designing an app – building out the wireframes and overall layout of an app is, essentially, deciding the entirety of the app’s UX in a single step of the development process. Sure, during other steps in the design process, you can make topical changes to an app’s UX (such as color schemes to influence certain moods), but changes such as these don’t carry nearly as much weight as the actual flow of the app itself.

A proper wireframe layout will include all the information someone would need to understand how the app will work – while boxes will lack graphics, they will include language that denotes what information will be held within those visual boundaries, as well as how it will interact with the elements around it (aspects such as movement, scrolling, fading, or other interactions).

This step also lays the groundwork for an incredibly important, but often under-appreciated element of your app’s design – its negative space. The space surrounding the individual elements of your app like text, or boxes are called gutters. While their name might not be pretty, if your apps gutters aren’t uniform, users will notice, and be extremely thrown off – and worst of all, they won’t know why – they’ll just have a subconscious feeling that something is off about your app.

Design is a language everyone can implicitly understand, and when there’s a change in the uniformity of a product, especially an interactive one, our brains are wired to pick up on it. We are built to recognize patters, and when those patterns are broken, our brain sends off a warning light that’s incredibly difficult to get rid of.

When there’s a difference in the spacing of your app, even just a few lines of text, users will notice immediately notice.

UI Design

Designers will then take those wireframe layouts and turn them into the finalized interface for the app. This is the step where designers will make your app’s icons, decide and implement font styles, finalize the motion of the UI (the way the app responds to users interactions), and implement the feature set (in the form of interactive visual elements).

Something I believe is important to impart is that designers don’t just make things look pretty – just like there’s a backend to development, so to is there a backend to design. The previous step, building out wireframes, is akin to determining your APIs – and this step, UI design, is the equivalent to connecting the endpoints.

It’s a designers job to translate a tech doc into a visually interactive and stimulating experience that fits on a (relatively) small screen, is compelling, cohesive, and helps them solve a pain point they face in their lives by the most efficient path possible. There’s a lot more to UI design than selecting colors.

A designer’s day is basically one continuously reoccurring A/B test. Questions like “Does the placement of this button add to the overall UX, or detract from it?,” plague a designer’s day.

UI design can take anywhere from 30 to 100 hours, depending on the complexity of your app.

Prototyping

This step in the design process serves as the bridge between designing an app, and actually coding it. While it does add an extra step to the process, it does help to cut down on time spent revising your app after it’s already been coded however.

Development shops use this step as what I like to refer to as an “island of stability.” It serves as the benchmark for all development moving forward, because the prototype is the, after the wireframes, the first real interactive product shown to you, the client.

A prototype is designed to be as close to the imagined finalized app as possible – from UI movement to font sizes. Prototyping tools are used to demo the feature set of the app, and should demonstrate the entirety of the app’s functionality.

This is as such so you, the client, are able to determine what works, and what doesn’t. Once a design and feature set have been agreed upon by everyone, it’s time to move onto the final step of the design process.

You can expect prototyping to take anywhere from 5 to 15 hours, or more for complex apps.

Build out the UI/UX in actual code

This is where developers will take a backseat in the design process, and your developers will step in. While the designers might not be as involved with your app’s development from this point onwards, they aren’t out of the picture entirely.

In order to build out and code the actual app, developers must translate the visual elements of your app’s design into code. In order to do this, they need to develop their own structure to keep everything in its place.

To code the design of an app, programmers must hook up features that need to access servers or other outside data to the backend, as well as create the app’s individual design elements in code. In order to maintain your app’s quality and brand, programmers will make sure your app looks the same, no matter what screen resolution it’s being displayed on.

If your app is being developed for both Android and iOS, this means your developers will need to make sure it looks and works the same, whether it’s on an iPhone or a Samsung. This will, at the very least, double your app’s development time, and why most dev shops will caution appreneures to start out with a single platform.

Designing an app with a template: Should you?

/0 Comments/in /by

Starting from scratch can be a very daunting prospect. Whether you’re making pie crust, or designing an app, beginning with no foundation can lead to a lot of second guessing down the road. Of course, any professional chef (just like any professional developer) won’t be phased by starting with basic ingredients that are paired with the intention to build something cohesive from them.

So, when designing an app, should you use a template?

By now, you’ve probably guessed the answer – it depends. First of all, we’ve got to nail down what we’re talking about when we use the word “template.” In the context of designing an app, there’s a few different types of templates.

While doing my research, I asked our director of marketing strategy what he meant by “templates.” He sent me a link to a gallery of fully-built, pre-made, slightly customizable, ready-to-implement platforms.

I asked our senior Swift developer the same question. She promptly showed me an example of a Master-Detail template in Xcode. Basically, it auto-generated the code for a view controller which held a table that came along with some limited functionality – the ability to add, delete, and edit data entries in the table rows.

I caught our CEO as he was leaving a meeting with a client that had run late (because their idea is so cool!), right before he had to leave for another meeting. I asked him the previously posed question. He quickly (I am not jealous of the busy CEO life) went over details as to why using a codebase template is a bad idea for many reasons – the main one being that if you want to make almost any change to functionality or the style, you’re pretty much out of luck.

Finally, I sat back down at my desk, swung my chair to the left, and popped the question to our senior UI/UX designer: “What’s your opinion on app design templates?”

By this point, I was purposely asking this in as vague a manner as possible – I wanted to see if I’d yet again have a different example given to me.

“Oh, you mean like standard UI elements?” For those of us who don’t design for a living, she was speaking about the generic icons (like arrows, menu icons, and other generic buttons and fields) that Apple has available for download for free. These templates can be used with different design programs, like Sketch and Adobe XD.

So, out of those four types of templates, should you use any of them?

And the answer, yet again, is it depends.

Do you have a designer?

If you do, the only templates they’d use would be the Apple Design Resources our own designer brought up a little bit earlier in this blog. These are very practical resources, and help to keep Apple apps looking “Appley,” like iOS users are accustomed to. Rather than entire screens, or rigid, unchanging guides, Apple Design Resources are small, customizable, separate UI elements.

Most iOS apps have a top bar that takes up the same amount of real estate on the screen, no matter what app it is. This is largely due to the library of available templates on Apple Design Resources. These templates ensure consistency throughout an iOS user’s experience, and help save time during an app’s visual designing phase; and unlike the other types of templates listed above, don’t hinder your app’s ability to stand out by presenting a unique layout, experience, and brand.

Other than those generic UI elements, a professional development team will most likely never touch a template. It would be the equivalent of a professional chef buying their pie crust from the grocery store rather than folding it over and over again on their own.

Why? It just doesn’t taste the same.

When I asked our senior Swift developer if she had ever used a template and then built off of it, she emphatically told me “No.” This is because when you’re a professional at something, you know the intricacies of every step you take when building a product – whether that product is a pie or an app.

And when you have your own way of doing things, generic building blocks can get in the way pretty quickly – you spend more time going back and tweaking boilerplate code in order to make the product you envisioned than if you had started from scratch.

As for those fully-fledged codebase templates our CEO was talking about – they’re never used at dev shops, for all of the previously listed reasons, and many more.

Are you the designer?

If you are, and you don’t have any experience designing anything that exists in an interactive medium, and you don’t have the budget to bring your idea to a dev shop, you’ve found yourself in the one situation where using a visual app design template (the kind our director of strategy brought up) is probably the right decision.

Unless you get lucky, or you discover nascent design talent that has resided within you this whole time, the template will most likely look better than what you make. And no offense meant; these templates are designed by professional designers themselves, so they do follow standard conventions, and tend to look good when they’re doing what they’re meant to do.

While they exist in a space near WYSIWYG app builders like Appy Pie (I promise, I don’t hate you Appy Pie), app templates lie directly adjacent from app building tools. Rather than selecting from a list of functionalities, putting them together, and then trying to make them both work properly and look good at the same time – with app design templates, you select the template based on two parameters: its visual style, and the functionalities it offers.

Store-bought vs. Homemade, Cookie cutter vs. Custom

When comparing an app built using a template, versus an app built natively, there are four categories of comparison:

  1. Cost
  2. Time
  3. Robustness
  4. Brand

Cost

When it comes to upfront costs, the template-made app will win every time. There are some templates available for as little as $14. You can spend more than that on a sandwich. There are apps that users pay more than $14 to download from the App Store.

But that’s upfront cost. Over time, that can (and most likely will) change.

Time

Again, if you’re comparing just the initial time that goes into designing an app, the template app will beat out the natively built one. Development, however, has no end – only a beginning. If your app is available for download, whether it’s today, tomorrow, or next year, your app will eventually need to be updated.

Updates (at least the significant ones) are either visual, provide extra functionality, or increase security. None of these are possible with a template-built app – other than very, very minute tweaks.

Robustness

This is where the innate differences between a natively built app compared to a template-made app really being to show. Native apps, for many reasons, are the most responsive, the quickest, and the all-around best feeling apps on the App Store.

Not only are native apps built to provide the most streamlined user experience, they also provide the most functionality – this is because every implementation is tailor-made to that specific app

Brand

Finally, it’s down to branding – which, just like robustness, native wins easily. Branding is more than just your app’s logo – it’s the color scheme, the amount of space the gutters between UI elements take up, the feel it produces when a user pushes their thumb up on their phone’s screen. Brands must be personal – and the only way to make your brand truly personal is to build it from scratch – not slap a layer of paint over someone else’s product.