Tag: Lean

Categories
Business

Prototyping: needless effort or driver of perfection?

Mobile apps are becoming more and more sophisticated every day. They evolve together with mobile devices, giving us even more pleasant, intriguing and unique experiences. Design, usability, functionality accompanied by various touch interactions, animations, and transitions are integral components of apps.

Building an app is not easy. It involves various stages in a long development life cycle. Apps require time to build, time to test, and time to iterate for improvements. Iterations are not easy especially when extensive code changes are required and that’s where usually things get messy.

There is one solution to avoid the trap that lies ahead when developing apps: prototyping. A prototype is an early sample or model built to test a concept or process, or to act as an object to be replicated or learned from. The prototyping step is often skipped due to the extra cost and effort it adds to the lifecycle of a project. However, it is widely accepted in the development world today, that undermining this vital part of the design and build process may lead to miscommunication between developers and clients, pitfalls, over budgeting, and bad quality products. Prototyping allows developers to conduct proper user trials, iterate before coding and send the app to production only when it is perfected.

Graphic designers, user experience designers, usability experts, interaction designers, and developers use different ways and tools to create prototypes. The most popular methods used for prototyping apps are paper prototyping, presentation software, mobile apps (usually for tablets) designed to allow people to prototype mobile applications on actual mobile devices, source code and prototyping applications and tools either web (offered as SaaS) or desktop apps.

In the following section I will briefly describe the prototype tools vendor landscape and the main needs that these tools serve.

Vendor landscape

If we ignore for a moment the paper prototyping and source code, where no specific tool is used, then we are down to three main types of prototyping tools: presentation software, mobile apps and mobile prototyping applications.

prototyping-tools-landscape

Presentation software like Keynote or Powerpoint, are in the market for decades and peeple are well trained to use them in different ways. The way people use them for prototyping, is by linking sketches, or design comps together in a presentation since such tools support animations and screen transitions. Some UI libraries like Keynotopia have UI components of popular mobile operating systems like iOS and Android, designed for presentation software. Presentation software are built for an entire different purpose and they are limited in prototyping functionality but are still valid in some user cases. Diagramming software like Omingraffle and Gliffy are sometimes also used for prototyping.

Mobile apps for iPad and Android tablets designed for mobile prototyping allow real device testing which is their main advantage. Some of these apps provide UI libraries of major mobile UI components like App Cooker and Interface HD. Others, like Popapp allow taking photos of sketches and linking them together. Most of these apps are limited to single device prototyping and usually lack sharing and collaboration tools but are very useful when it comes to quickly validating an idea.

Mobile prototyping applications are web or desktop applications designed specifically for mobile prototyping. These applications vary from simple traditional wireframe applications (including mockups) to advanced prototyping tools that are able to provide a varying degree of mobile-specific functionality such as touch events and gestures, interactions, screen transitions. Most importantly these tools provide the ability to preview a prototype on the actual device.

There are three different types of such mobile prototyping applications:

  1. Hotspot apps are usually web apps that allow you to upload your mobile design comps and link them together usually with a single event (click or touch) without (or at best simple) transition effects. These apps are useful especially for collaboration as most of them allow comments and annotations. Although some of these tools make real device preview possible (i.e. preview on the actual device that the app is built for), they are not really eligible for proper user trials as they do not allow multiple interactions such as touch gestures and other important mobile specific features. Applications in this category are Fieldtest app, Invisionapp, Popap and are usually web apps offered as Software As A Service or mobile apps for tablets and Smartphones.
  2. Wireframe or Mockup tools are tools that allow the development of still wireframes or mockups. Usually these tools have a large number of UI components libraries available. Some of these tools have been in the market for years as they were designed for website mockups or wireframes, but many of them have been changed in an attempt to embrace needs specific to mobile apps. Many of these tools are very advanced in functionality and features, offering a range of useful companion tools for collaboration and more. Most of these tools are limited to single tap interaction (or mouse interactions, as they are designed for web sites) and no or limited animations and transitions. Tools that fall under this category include Balsamiq, MockingBird, UXpin, Pidoco and others and they can be found as web apps available on a subscription basis or as desktop apps.
  3. Prototyping tools are web applications or desktop software designed from the ground up and specifically for mobile (or web) prototyping. These applications go beyond traditional wireframe or mockup applications, to provide functionality for mobile touch events and gestures, interactions, screen transitions and most importantly provide the ability to preview a prototype on the actual device. Many of them come with UI libraries for iOS, Android, Windows mobile and Blackberry and offer collaboration tools and functionality. Tools and software in this category include Axure, Indigo Studio, Proto.io and many more.

[sectors slugs=’prototyping-mockup’]

Current challenges with prototyping tools

Prototyping tools are still in their infancy. They have been around for two years or less must be in sync with the ever changing mobile industry. New mobile devices become available on a daily basis, new versions of mobile operating systems and new functionality that needs to be supported makes the chase even more difficult. The main challenge is the ability to test the prototypes on the real device. In order to achieve this more tools render their prototypes in HTML5 so that they can run on a native mobile browser without the need of installing and maintaining various mobile apps.

Another major challenge is performance and by using HTML5 features such as animations render much slower on a mobile browser than they would on a native app, making the experience a bit far from real and as such defeating the purpose of doing a full prototype in the first place. Nevertheless, some of these tools have reached a maturity level that allow professionals to create fully functional, interactive mobile app prototypes of their apps that look and behave exactly as their app would. This allows the teams to conduct user trials, gather feedback, and iterate for improvements. Furthermore, a proper prototype narrows the communication gap between designers and developers (coders) as well as with the app team and the stakeholders.

Future opportunities with prototyping tools

Prototyping tools gain larger audiences as mobile technologies progress. As mobile apps become more sophisticated, more detailed prototyping is required. The mobile market grows and the prototyping tools market will continue to grow with it as more Operating Systems and newer more capable devices are released. New devices come to life every day, from car navigation systems to refrigerator panels, all having in common touch and interactive interfaces.

Categories
Business

Why Measurement Matters – the case for analytics

Measurement Matters

Creating a successful app business takes a lot more than a good idea and the skills to develop an app and upload it to a store. As we’ve discussed before, developers who promote their apps are almost 3 times as likely to break-even as those who don’t. This is the simplest difference with a massive effect on success. It seems obvious, no marketing means a good chance almost no-one discovers the app and thus no revenue, yet some developers still don’t do it. Picking the most lucrative platforms seems like another obvious candidate; considering only those developers who are interested in making money, those that develop for iOS are a little less than twice as likely to be above the “app poverty line” (38% earn over $500 per app per month) than those developing for BlackBerry (20%). Getting your revenue model right can also make a significant difference; according to our survey, developers using a subscription model earn nearly 2.5 times as much as those using other revenue models on average. Not all apps can use a subscription model, however, there is something that almost every developer can do which is correlated with more than double the chance of being above the app poverty line and earning more than 2.5 times the average revenue compared to those that don’t…

Measuring user activity and crashes

You managed to build an app and get people to download it but how many of them still use it? When do they use it and how often? What devices do they have and which firmware versions? What features do they use the most? Which parts of the app should you focus on improving? Do your changes to the app make users interact with it more or less? All of these questions require measuring the user interaction with the app by recording data and analysing it. Unless your app regularly interacts with your own backend service which you can collect relevant statistics from then this would be an expensive capability to build. Fortunately there are a number of third party usage analytics services to do it for you and the two most popular, Google Analytics and Flurry, are free to use.

Similarly, no app is perfect when it is launched and it’s almost impossible to test on every device and firmware combination out there in the market. If some of your users are getting crashes that you can’t reproduce and fix quickly then you’re likely to get a lot of poor reviews, which will reduce the chances that other users download your app in the future. Unless you have tooling in place to capture details of crashes and report them to you then it’s very hard fix them. Although there are libraries that can report crashes to you directly, unless you want to analyse every single one manually, you’ll want tools that do that for you and categorise them such that the ones with common causes are grouped. Without this there’s no good way of prioritising what to fix. Again, crash analytics & bug tracking service providers can handle this for you and one of them, Crashlytics, was recently acquired by Twitter and now provides all of its features for free. Other providers also have free tiers.

This is not to suggest that the free options are the best for every app, just that there’s very little excuse for not using these tools because there are free ones. If you need convincing, take a look at this infographic, which uses our survey data for just the respondents that were interested in making money and earning less than $50k per app per month (we exclude the very small number of top earners as they can distort the stats, although in this case they would only make the argument stronger).

Correlation is not causation

It’s really important that we note a strong correlation between usage of analytics tools and increased success for developers only. Correlation is not causation. It’s clear that simply integrating these tools and doing nothing with the data is not going to make the slightest difference to anyone’s results. They are trivial to integrate but provide no direct end user benefit at all and no additional revenue stream. It could be argued that most providers only make these services available for the leading platforms and the extra success is primarily due to that. This is not the case – restricting the data set to those developers whose primary platform is Android or iOS produces an almost identical pattern of results. Another argument is that crash analytics services are typically focussed on native stack traces, which don’t often provide much diagnostic value for non-native apps. However, anyone tempted to blame a poorer non-native user experience produced by development tools that are also less likely to support these analytics tools should note that cross-platform tool users make more revenue.

One valid argument is that until you have a successful app with a fairly large and diverse user base, collecting crash data and analysing it is not the biggest problem you need to solve, those who use the services may simply be the ones already big enough to have the problem. There are two arguments against this. First, integrating crash analytics after you’ve acquired a large user base is too late; how many users will give you a second chance installing at least 2 updates to a crashy app (you can’t fix it until the update after you integrate the analytics)? Second, this doesn’t explain why those integrating both types of analytics tool have a significantly greater chance of being above the poverty line than those that only integrate one or the other. Similarly, whilst there is almost certainly an experience factor at work here it is clearly not the whole answer.

The most plausible explanation for these results is that those with a more scientific approach to their app business tend to collect as much data as they can and use it to drive decisions about their development. This produces more successful apps than intuition and guesswork. So, sign up for analytics services, integrate them with your apps and act on the data they provide. This process can’t magically turn a bad idea or unwanted app into a success but it can help make a decent app into a much better one. If you apply some of this data-based reasoning and scientific methodology to deciding what to build and how you market it too then that’s likely to further increase your chances of success.

Got an alternative explanation for this data? Let us know in the comments below.

Categories
Platforms Tips

A/B Testing on the Amazon Appstore

App Store

In December Amazon launched a new A/B testing service for Android apps on the Amazon Appstore. Integrating A/B testing, particularly for in-app purchase related events, in the store portal is a welcome addition. Slightly disappointing considering this comes from a store provider is that the A/B testing service does not support testing different copy or icons on the storefront itself, purely in-app A/B tests, for which there are already third-party alternatives.

Not a “leaner” alternative store

When we looked at the developer platform “lean factor” for Android previously, we were only considering Google Play. Android came out on top due to the ability to publish new versions to the store almost immediately, enabling much faster iteration. However, the Amazon Appstore does have a review process which introduces significant publishing delay. As such even with the convenient addition of A/B testing baked into Amazon’s store, Google Play still offers a better environment for implementing lean development.

Testing in a smaller market

That said, there is at least one interesting use of this new service. Amazon’s Appstore has historically had a much higher proportion of users paying for downloads and in-app purchases than on Google Play – so much so that in early 2012 many developers made more money on Amazon’s store despite the much smaller audience. A smaller market with a high proportion of paying users is ideal for A/B testing improvements with the most important user group, particularly improvements to in-app purchase flows. Testing new variations on Amazon’s store and then rolling the successful ones out to a Google Play version might be a useful strategy for increasing revenues.

But how much smaller?

A final question is how much smaller is Amazon’s store in terms of downloads? They are notoriously silent when it comes to absolute numbers and even the relative numbers they give are ambiguous. In the press release for the A/B testing service linked above they say that app downloads have grown 500% over the previous year. This was in a release at the beginning of December with no fixed reference point given for the comparison. As can be seen from the relative growth chart produced by Distimo at the same time last year below, the launch of the original Kindle Fire at that time produced similarly massive growth.
Distimo_Amazon_AppStore
Dependending on where the comparison is made, a 500% increase could be anywhere from slightly behind January’s download level to 6 times the December 2011 peak. Until they provide some concrete numbers the best advice is to try it and see what your own results are like. The only major difference we’re certain of between the app buying users on the two stores is a higher proportion of tablet users at Amazon’s.

Categories
Business Community Tips

Developer Story: Lyft

developer story: Lyft

Sebastian Brannstrom, Lead Engineer for Lyft at Zimride, talked to us about their app and the business that the technology enables. Sebastian has been working in mobile software since 2006, initially on Symbian and then transitioning to iOS, Android & Web by way of a side project, created in collaboration with designer and product manager Anna Alfut. In 2011 he joined VC-funded startup Zimride, who at the time only had a handful engineers, to create social ride-sharing services. Zimride’s initial service was an online marketplace for people to sell seats in their car on longer journeys. It was (and still is) growing but relatively slowly by Silicon Valley startup standards.

App Background

The company decided to create a new real-time marketplace for shorter trips and hence Lyft was born in 2012. Lyft has iOS & Android apps with two modes, driver and passenger. Lyft drivers are thoroughly screened, background checked, trained and insured with a $1M excess liability policy. Passengers can use the app to request rides that are tracked by the service, which suggests a minimum donation to the driver at the end. The driver mode notifies drivers of a nearby pickup request and gives them a short time window to accept it before it’s passed to another driver. The whole system enforces use of Facebook for identification to provide some additional security.

 

Track Record

The concept caught on and quickly became the main focus of the company. The engineering team has roughly tripled in size and the growth of the service is only being limited by how quickly they can recruit, screen and train drivers. Whilst they advertise for drivers on services like Pandora, Spotify and Craigslist, they have never marketed to passengers at all, apart from their signature giant pink mustaches on participating cars. Word-of-mouth marketing at its best, straight out of Seth Godin’s Purple Cow playbook. They have hundreds of registered drivers and tens of thousands of passengers in their first city, San Francisco. The company was nominated for three Crunchie awards and named runner-up in the “Best New Startup of 2012” category. According to TechCrunch, they very recently closed a $15M series B round of venture capital funding and have also just launched their service in a second city – Los Angeles. Open job vacancies make it clear they’re planning significant further expansion.

Competition

The disruption of transportation enabled by near ubiquitous smartphone adoption is an opportunity several startups are attempting to exploit. Lyft faces direct competition locally in San Francisco from SideCar, whilst Uber provide a high end alternative and have stated an intention to create a direct competitor in the lower cost segment. Fairly high-profile competitors with similar technology but not yet competing in the same geographical markets are Heyride, HAILO and Taxibeat, although the latter are enabling existing taxis with similar technology rather than encouraging peer-to-peer ride sharing. There is also indirect competition from existing taxi services.

Business Model

Lyft do not monetize their apps directly, it’s free to download and there are no in-app purchases for new features. Like almost all online marketplaces, Lyft make money by taking a cut of the transactions on the market. In this case the transactions are donations from the passenger to the driver. These are entirely voluntary (which gets around legal issues with drivers using their vehicles for commercial purposes) but the app provides a suggested donation and drivers can set a minimum average donation – passengers that don’t pay much/anything are likely to find no-one will accept their requests very quickly.

Lessons Learned

A successful service is much more than an app. The technology only enables the business at Lyft. Sebastian was quick to point out that the key to the success of the company is the operations team, building a community of drivers and passengers. If they’d simply built the technology and put it out there to see who wanted to use it, it’s very unlikely they’d be enjoying the growth they see now.

Projects will expand or contract to fill the time available to them. The initial concept for Lyft was originally scoped out as an 8-week development for a team of 5 (3 engineers, a designer and a product manager). One of the founders, playing devil’s advocate, said “what if you’ve only got 2 weeks to do it”. This forced them to really cut the concept down to a true Minimum Viable Product. They eventually got the first version built in 3 weeks (server and iOS app) – even today there are still several of their original requirements sitting at the bottom of their backlog unimplemented. The things you think will be essential parts of a service can often turn out to be unimportant for real users.

Team chemistry is essential. It would have been impossible to build such a complex service so quickly without fantastic collaboration. The relationships and collaborative working mode are more important than physical location – Lyft has been hiring top talent from around the world and sorting out visas and relocation to San Francisco afterwards. Sebastian was based in London when he was hired, their iOS lead was in Uruguay and the Android lead in Russia (the extreme time difference was sometimes an issue in the latter case).

What’s in the Lyft toolbox?

Like many successful development teams, Lyft use a lot of third party tools to help build their product:

Also, although they have built their own backend service, creating a highly responsive notification system was a challenge they solved with a combination of polling for updates when sending driver location, the Apple Push Notification Service, Google Cloud Messaging and a paid service from Pusher. However, the latter was initially a source of many crashes due to immature client libraries (Pusher only provide official support for a JavaScript client library, other platforms are community supported).

Sebastian’s desire for the tools space was very much in-line with our outlook in the latest developer economics report – consolidation. Fewer SDKs to integrate and fewer monitoring consoles to log into.

King for a day

Finally, if Sebastian could change just one thing about the platforms he works with, what would it be?

Better support for web/native hybrid app development (Lyft explored and abandoned that approach), with the Android WebView particularly in need of improvement, was a close contender but the top of the list for fixing was the Apple App Store review process.  5-10 days of waiting and they can see from their server logs that the reviewer doesn’t even login to the app with Facebook Connect before approving it. There must be a better way.

Categories
Platforms

How Much Time Could You Save With Backend-as-a-Service?

Backend-as-a-Service (Baas) provider Kinvey published an interesting infographic on the average time taken to build an iOS or Android app (with a backend service) this week. The data comes from a survey of 100 developers with their estimates averaged. Before interpreting the data, it’s worth bearing in mind the following:

  • This is only to build a Minimum Viable Product (MVP) – it’s nowhere near the total that would be spent on a successful app.
  • The features included create an app with a relatively rich backend service and a fairly basic client.
  • This is only building a client app for one platform rather than several.
  • Building a robust API versioning system would not normally be part of an MVP.
  • This survey has been created specifically to promote the benefits of BaaS.

Even so, the the items included in the infographic would be common to a wide range of applications.

Continue reading “How Much Time Could You Save With Backend-as-a-Service?”
Categories
Business

The “Onboarding” Problem

With some types of mobile app, getting a user to download it is just the beginning of the problem. If the application is going to be personalised to a user’s preferences, or allow them to interact with others via some online service, then they’ll need to provide some data before they can start using it. Typically the more information a user provides about themselves, the better job an app or service can do of tailoring the experience to them. Unfortunately, the more steps a user has to go through before they can start using an app, the less likely they are to complete the signup process. Getting this wrong can catastrophically alter the economics of user acquisition.

Continue reading “The “Onboarding” Problem”
Categories
Business Tips

Crowdfunding: Leanest Way to Launch?

crowdfunding

One question that divides opinion among developers is when to start marketing your app. Some say if you start marketing too soon, the early interest you create will dissipate before you actually have something to sell. Others argue that you can’t start talking about your app soon enough, build a following of early adopters and you have great word of mouth marketing and an initial sales boost to climb the store charts. What if you can have the benefits without any of the downside? It might just be possible with crowdfunding.

Continue reading “Crowdfunding: Leanest Way to Launch?”
Categories
Business Platforms Tips

The Developer Platform “Lean Factor” and Why It Matters

lean framework

There’s a lot of buzz about Lean Startups in the software community in general and amongst mobile developers in particular. How lean a startup can be is strongly influenced by the tools and processes available on their chosen platform. Which platforms enable the leanest product development processes? How and why does lean framework matter?

Continue reading “The Developer Platform “Lean Factor” and Why It Matters”