For the last six months I’ve been making apps on mobile phone platforms and I’m seeing some early successes that push me to keep on going with it.
Following the MVP (Minimum Viable Product) approach, test minimum ideas and pivoting on feedback when necessary. The approach is mentioned in the Lean Startup book, by Eric Ries. Definitely worth a read, even if you aren’t working on your own stuff. Its got some really interesting ways of looking at feedback which is invaluable.
The aim is to develop a successful product that are useable to other people and make sure that your efforts are as efficient and profitable as possible. I don’t just mean earning as much money as possible, but also to be useful to many people. Usually making money and usefulness to others goes hand in hand. If a product is useful to a lot of people, theres more chance a lot of people would pay for it.
The MVP and feedback approach went against my entire career of software development so far. Usually what happens in software creation is a more linear approach. Various design meetings come up with a blueprint for the new game or app. If I was lucky (or unlucky) enough I would be present at these meetings to hear what people wanted, and mock-ups some designers had made already. After the features and design was finalized, we went to work to create the app and it was released to the client or the public. If we did it right, the company was paid, or we saw the download counter increase. There the cycle ended and I was put on to a new project to begin the path again until enough projects failed that the company went bust, or I got bored enough to move on to a new company.
This is almost the exact opposite of MVP and Iterative development cycles. Instead of finalizing a design and creating the product, only the bare minimum is created to convey the core feature and is released to the public. Feedback is obtained to prove or disprove assumptions and a new version of the app is pushed out based on this feedback. This loop is an ever continuing cycle of feedback and improvements. At the start I found this a difficult process, but now I find this method a much more natural way of application development and I can see success and failure very quickly so I can capitalize or fix the problems as soon as possible.
Study’N’Walk, The road to my own language learning apps.
During my year in Taiwan, I used the flashcard app ANKI to learn Chinese which led to creating my own decks to tie in with my own Chinese books.
I realised early on that my listening skills were terrible, and reading text wasn’t helping. So I integrated voices into the anki cards, producing a spreadsheet and scripting process to help me do this more efficiently. I ended up documenting the process for others to see and try themselves.
From these posts, I got 3 major pieces of information,
1. Traffic to my website jumped quickly, it looked like lots of people were searching how to make their own ANKI cards.
2. I got a couple of comments asking how they could use this process to study a language other than Chinese.
3. I got a more than a few comments online about how the people who wanted to make their own ANKI decks were not technical enough to follow the process. Spreadsheets seemed to be OK, but scripting was a bit too much to ask for.
Next step was to simplify the process of creating decks by making an PC app to replace the difficult steps of scripting, and also add some flexibility to the languages.
I ended up with a C#/GTK+/MONO app that was much more flexible and convenient and after a few iterations I then had a system that could take in any language and output any language, with voices in a range of languages.
The feedback was not particularly good, because of the particular development environment I used, MONO, users had to download an additional component to make it work, similar to Flash for web browsers. MONO had allowed me to develop cross platform on Mac and Windows which I thought would be useful, however users of ANKI were not really prepared to get technical to install this software. A particular point of confusion was created in what I thought was a useful flexibility, the ability to create your own structure for each card type. Testers I showed this to were confused as they weren’t used to this level of control.
In one particular Test I made voices in both English and Chinese and then tried the deck in ANKI. This gave me the idea that I could study using my phone without looking at the screen and instead use only voice prompts. After a few trials using ANKI with this particular combination of text and voice in both English and Chinese, I found I could use my time while walking outside to study Chinese effectively.
The next problem was the interface for ANKI was not quite appropriate.While functional, the button positions were a little awkward to press if not looking at the screen (at the very bottom of the screen) and the button positions occasionally changed. This was no good if you wanted to press the buttons without looking at them.
I decided to address this problem by making my own flashcard client on Android, called Study’N’Walk. The concept was to show the flashcards on screen, similar to ANKI, but have a much more consistent and easy to use interface that could literally be used with your eyes closed. This then opened the possibility of integrating monetization features such as IAP and adverts. Most importantly, it opened the reach of my app across the Android app store and gave feedback about numbers of downloads, current installs, daily use of the app, what language people opted to study. It also provided a very flexible platform in which I could release different apps and perform A/B tests and have different languages.
I began to realise that this app was now becoming available to people who wanted to study a language but had never heard of ANKI or a flashcard learning system. This was unexpected as I always thought of this as an addition to ANKI. These users had no problem getting the app into their phones, but they were unfamiliar with the ‘question’,’answer’ format of flashcards as a means to study vocabulary. I added some tutorial pages, but I found that users just seemed to click past them all without reading and then they found themselves stuck. I then added some interactive help bubbles which seemed to help.
I have since produced a variety of versions of the app (the first one being a 9 language demo pack) to Chinese and Japanese versions, and branching out to ‘Dictionary’ versions that have a slightly different UI, but present the data as a Dictionary primarily, with an option to learn the words in a training mode.
These A/B Tests let to an unexpected win when I was asked to about the possibility of a Plants Dictionary. The app lists many plant names with their Botanic equivalents. This has now become my most downloaded and profitable app, and it is used most in South-East Asia, a previously unconsidered market.
I also discovered that people do not care for the ability to make their own content. Users would typically search for a language they want to study rather than search for the ability to create their own content. Considering this was a core feature I was trying to push at the beginning, I was very surprised to hear this. Following this, I decided not to include the feature in the iOS builds, and I have found no negative feedback about the lack of this feature. This saves development time and the risk of anything going wrong.
The next lines of focus are now to look into Windows Mobile, whilst considering different content such as different languages and dictionary content. The design of software has allowed me to switch between content fairly easily whilst still using the same ‘engine’. I can make changes to the core learning experience and it is instantly reflected in builds for all the apps.
Major Points
The major points I have learned from this approach to application development are:
- The traditional model of product development is not applicable here. You must be flexible to change the direction of the app in order to achieve the success you are aiming for.
- Spontaneity is vital. For example I was impressed at how the swiping actions were used in one app, so as a quick test I added the swipe functions in the app to act in the same way as the buttons I had on screen. It was an immediate hit, because swiping a screen can be done without looking at the screen far more easily than pressing a button, even if it is big and in a set place. In the end, I removed the buttons altogether in favor of the swiping motions.
- Get feedback as quickly as possible. Get the systems in place to give feedback and see what
- Listen to suggestions, even if you think its stupid, see what can be done to accommodate. It might be a very simple change, and it might get a whole load of new users.
- In my opinion, Dog Fooding (using the product yourself) is a major factor in getting it right. You’d have to use the product yourself in order to know whether you like it or not. Its one of the best feedback models.
- Push something out to users as quickly as possible. It doesn’t matter if it doesn’t look very nice or breaks a lot. The important thing is to get the feedback loop started as soon as possible so you know how to improve it.
It was a big deal for me to put in monetization elements into the app, even from the beginning (who likes to see ads in your app?) but I see now that the money part is still a huge driver in making me want to make great apps. If I started this without any way of making money, I’d be missing one of the most important parts of making this business work.
