Tale Of A Top-10 App, Part 1: Idea And Design

Advertisement

My name is Jeremy Olson. I’m a senior in college, living in Charlotte, North Carolina, and this is the story of how my little app beat Angry Birds.

I’m writing this because I believe we learn much more from success than from failure. It took Edison thousands of failed attempts to invent the electric light bulb, and it would be foolish for us to reinvent it based on trial and error, now that we have a working model.

We have many shining lights in the app industry. While I would love to claim that my success stems from my own genius, nothing could be further from the truth. By studying independent developers who have succeeded in the App Store again and again, I was able to learn the basic principles that I needed to succeed, and I hope this story will help others do the same.

IMG_0712
Large view.

A Big Idea

My first app, Grades, had everything going for it. The press loved it, users loved it, and Apple loved it. There was only one problem: It didn’t make any money. Sure, it generated a little cash, but despite all of the buzz, Grades was always limited by the tiny niche it served: college students who cared enough about their grades to faithfully track them throughout the semester.

Our first app, Grades, was a success for our reputation but not for our bank account.
Our first app, Grades, was a success for our reputation, not for our bank account. Large view.

If we were to continue making cheap apps, our next one had to be big. It had to appeal to almost anyone.

The solution came when Alex Marktl, founder of Sonico Mobile, approached us about partnering on an offline translation app. It was a proven market. Sonico’s app iTranslate had over 30 million users, and the market had an immense gap for an affordable translation app that worked without an Internet connection.

After seeing some user feedback for Sonico’s popular iTranslate app and researching the competition, we were pretty sure the market opportunity was huge. In addition, my four-person team is really passionate about education and language. The market was there, the opportunity was there, and the passion was there — a perfect fit.

A few Skype calls later, we had hashed out agreements and were ready to roll.

(Spoiler: It turns out that ideas matter a lot. Languages attracted a similar amount of press and buzz as Grades, but it made more money in one day than Grades made in two years!)

Defining The Dictionary

Although I was tempted to jump right into wireframing, we did some research up front to help us define the problems we were trying to solve.

Competitive Landscape

Competitors
Large view.

The App Store is great because it is one of the few markets in the world where you can so easily find valuable information about your potential competitors. They are just a search away. Looking at reviews, sales rankings and marketing materials of competing apps can give you great insight into the market. It is a great way to see the market for your app, how much people are willing to pay for it, what features to include, and a slew of other insights. Websites such as App Annie even enable you to analyze your competitors’ rankings over time.

We took about a dozen of the best competing apps and analyzed their strengths and weaknesses and how we could beat them. We found that, while a number of offline translation apps existed, they were poorly designed and cost a fortune. We knew we could do better.

User Experience Mapping

In defining the app, we focused on solving a few problems that people actually experience in their daily life, rather than just coming up with a list of cool features. To this end, we went through a little exercise that we call user experience mapping. This exercise generally takes a day or three. In it, we did the following:

  • Analyze users’ daily experience without the app — i.e. identify the problems they currently face.
  • Brainstorm ways that an ideal app could solve those problems.
  • Choose which problems to focus on, and decide which features were feasible for the first release.

Step 1: Define Personas

As designers, we need to thoroughly empathize with our users and understand their current experiences and thought processes as much as possible. Going out and talking to people can yield a lot of great insight, but in this case we were were pretty familiar with the translation experience, so we didn’t feel the need to talk to potential users at this stage.

Characteristics
Large view.

Instead, we went ahead and started brainstorming potential characteristics of our users.

We then chose characteristics of users who we really wanted to focus on, and turned them into personas.

Personas

A persona is a fictitious person who embodies the characteristics of the target demographic. While personas aren’t real, they should be based on reality and should make the abstract idea of a “user” much more concrete. Without a human face, mapping out the user’s experience is hard.

So, Emily is a 21-year-old college student studying French at Emory University. She is not naturally gifted in language, but really likes French and tries to read French literature. She is looking forward to doing a study-abroad program in France.

We created three personas that encapsulate most of the key characteristics of our target market: Emily, the student; Johann, the European business traveler (it turns out that we nailed this: 70% of our sales ended up being from outside the US); and Paul, the IT guy who learns new languages as a hobby.

Step 2: Map the Personas’ Experience Without the App

UX Map
Large view.

To map out users’ current predicament, we started by picking three key experiences related to translation — in this case, solo translation, social translation, and translation during travel.

We then brainstormed the activities and issues involved in these experiences that each persona might face. For example, in the solo category, Johann writes emails to clients in various languages and looks up the words he is not sure of.

Perform this exercise with people in the room who are similar to your personas. They will validate your insights and add to the brainstorming. If you don’t have that luxury, simply brainstorming and thinking through their possible experience is still a helpful exercise.

Step 3: Brainstorm the Ideal Assistance

After picturing our users’ lives, we brainstormed how the ideal app could solve their problems. We didn’t worry about viability, budget or timeline here; it’s all about coming up with really creative ideas to solve our users’ problems.

Step 4: Kill the Baby

Kill Baby
Large view.

This part is brutal. Having come up with a ton of cool ideas for features, we had to obliterate most of them. Good design is more about subtraction than addition. It’s all about finding the essential problems you want to solve and removing the features that are unrelated, inessential or unrealistic for the first version.

Polishing an app takes a ridiculous amount of time. So, if you start out with too broad a feature set, your app will lack focus and you will have no way to polish those features adequately.

Features
Large view.

Mission accomplished. Now we had a tentative 1.0 definition. Now we knew what this app would be about. You can read more about our user experience mapping exercise on our blog.

The Definition

Based on the last exercise, we crafted a statement that defines the essence of the app:

“An offline translation dictionary that gives instant access to words and definitions at 99¢ for multiple language pairs.”

This statement helped to focus our development process. It became a litmus test for any cool feature idea we came up with during development. If the feature didn’t support this statement, it didn’t belong in 1.0.

Sketching The Interactions

It was time to get down and dirty and start to shape our abstract ideas into a blueprint.

We started by sketching general ideas on how the various screens could flow together. These days, I mostly stick to sketches, and I use tools such as POP to share ideas with remote team members and clients. At the time, however, we were using OmniGraffle to create a rough prototype of the interactions.

Don’t Make Me Think

Our goal at this stage was to solve our users’ problems with an intuitive and easy to use interface. In essence, our job was to free users from having to think about the interface and instead to focus on the content.

This is a huge topic and Steve Krug literally wrote the book on it, so if you haven’t read Don’t Make Me Think, do so now. Seriously, it’s a great book.

Don’t Make Me Work

OmniGraffle
Large view.

People don’t like to work, so I am always looking for ways to save them from unnecessary keystrokes, taps and irrelevant information. The OmniGraffle wireframe above illustrates how we tried to serve that goal. We wanted our word lookup to be the fastest available; so, instead of providing on-the-fly search suggestions like most apps, we provide on-the-fly translations to those suggestions. We also found a way to solve the language-switching problem of most apps by enabling users to type in either language and displaying the results for one language on the left and the other language on the right.

Think Like a Human

Shelf
We wanted our dictionaries to feel physical. Large view.

Because this is an offline translation app, we wanted to give users the strong impression that the dictionaries are on their phones. We wanted the dictionaries to feel not like some abstract database in the cloud, but rather like physical dictionaries that they can access anytime, anywhere. We used the metaphor of a shelf with books to quickly communicate this to users.

While touch interfaces have matured, and users no longer need interfaces to look like physical objects in order to relate to them, sometimes physical metaphors can set expectations and convey feelings that purely digital interfaces cannot.

Relentless Exploration

Note that these wireframes are ugly on purpose. This stage has nothing to do with visual design. We don’t jump right into Photoshop, because the ugly sketches help us to focus on the interaction problems and enable us to quickly explore hundreds of ideas.

Because sketching a rough idea takes only a few seconds, we go really crazy at this stage. The more ideas, the better. Leave no stone unturned to find the ideas worth pursuing.

Sometimes your first idea turns out to be the best, but the only way to prove that is to test all of the other ways of looking at the problem. I’ve gotten to meet the designers of some of my favorite apps, and one of the main commonalities among them is this: The secret to their amazing designs is a lot less about genius than about relentless exploration. They don’t stop once they’ve found a good solution. They keep going until they’ve exhausted the possibilities.

Of Photoshop And Xcode

Photoshop
Large view.

This is when things get really exciting. It’s when ideas start to become reality. This is the point when we design and code the actual elements that our users will touch.

Some people think this stage is just about making pretty graphics, but that mindset leads to mediocrity. This stage is all about polish on all levels: interaction, usability and visual. This is when a good app becomes great.

While we hoped that our sketches and wireframes would provide a good outline, upon seeing things visually and playing with an actual coded prototype, we realized that we sometimes got it all wrong. Also, when we are merely sketching, it is difficult to imagine the creative details that will take our app beyond being usable and into the realm of fun. Once we start working with visual metaphors, colors and textures, dreaming up fun details becomes much easier.

So, this is all about polish, polish, polish, and it is by far the most rewarding and time-consuming stage of app development.

Establishing the Theme

Some people hate skeuomorphism, probably because mimicking elements from the real world in our digital interfaces can easily lead to overdesigned visuals and inconsistent interactions. However, skeuomorphism can be useful, fun and powerful if wielded carefully and deliberately. In fact, every app that contains buttons has skeuomorphism because buttons are borrowed straight from the real world. When used correctly, skeuomorphism provides much needed affordances that help users instantly understand how an app works.

With that in mind, we knew from the outset that we wanted to use the metaphor of physical books to reinforce the concept that these dictionaries are stored on the phone itself.

When working on the theme for the app, we generally iterated like crazy on two or three of the main screens until we were convinced that a certain look would work really well for the whole app.

Book-like theme
Large view.

Given that we were working towards a book-like theme, we explored an elegant earth-toned theme that let the content and typography shine. We continued to refine the theme along the way.

Side note: While the next version of iOS — iOS 7 — will rid itself of Corinthian leather and other such ornamental UI, and the industry is certainly shifting away from realistic interfaces at the moment, the best designers don’t just follow trends. Trends are important, but we should consider all styles and techniques as tools in our toolbox and use them where they make sense. Granted, realistic UIs will probably look quite dated by the time iOS 7 arrives, but within a year or so, diversity in design styles will intensify as the novelty of iOS 7’s minimal aesthetic begins to wear off.

Delight Is in the Details

As we continued to flesh out all of the different screens, we looked for opportunities to delight our users with details that would make the app enjoyable to use. Part of this is just about making the app look nice, but you can also delight users by adding a fun transition, or make them laugh with some quirky copy, or save them work in surprising ways.

Take search:

Swipe to search
Large view.

The user can start searching by tapping the search bar. But reaching for that bar with a thumb can be a hassle, so we added the ability to swipe anywhere on the screen to unfold the search interface.

Search
Large view.

As the user types, the interface populates with suggested results and translations, highlighting the matching letters like a spotlight.

Swipe to clear
Large view.

Folks who translate speech or passages of literature will look up a lot of words in rapid succession. We found that having to clear a search term by tapping the tiny “x” in the search field broke the flow and was physically strenuous, especially on the iPhone 5’s taller screen. So, we decided to let users swipe right to quickly clear a term — thus, allowing them to type a few letters, get the translation, and then swipe to begin typing another word all in a matter of seconds.

These kinds of details made all the difference when we were testing the app in the wild.

Designer and Programmer: Constant Collaboration

Collaboration
Large view.

Please, please, do not hand a programmer your design assets and expect a job well done. Not only do designers need to continually stay involved to ensure that their designs are implemented well, but using coded prototypes and testing them on users will inform the design in ways you can’t imagine. I don’t care what kind of genius designer you are: There is no substitute for testing a design and iterating on it.

Testing coded software exposes blatant weaknesses in the design that you may have never considered and shines light on areas where details could be added to make the experience more enjoyable. Because of this, I ended up doing even more design iterations after we had a coded prototype than I did before.

Changes at this stage are costly but extremely necessary.

Magnify
Large view.

Programmers with a good design sense can also have great ideas. We wanted to make a better index. My mental model was some kind of magnifying glass. But Richard, Sonico’s programmer, had a better idea: Magnify the letters themselves around your finger as you move your finger.

Gesture Experiments

As we started to code our first prototype, Impending and Realmac Software launched an app named Clear. No buttons, just gestures. Love it or hate it, it made a statement. I had never seen such an exercise in minimalism in my life.

It was a beautiful thing, and it inspired me to find ways to use gestures to improve Languages.

My first experiment was extreme: to create a fully gesture-based interface.

Gestures
Large view.

We replaced buttons with gestures. Swipe one way to search, and the other way to view the index.

As much as we loved the minimalism, we realized that we needed to teach our users about the gestures.

Gestures
Large view.

We tried a number of approaches. But after doing a lot of usability testing, we realized that all of them had one major problem: Search, our most important feature, just wasn’t blatantly obvious.

Dictionary
Large view.

So, we bit the bullet and used buttons and affordances where they make sense, but we retained a lot of the gestures and minimalism that we had gained through the experiments. The result was an app that is super-intuitive and simple for beginners, but full of gestures that make life easier for power users.

Testing

We made sure to get input on all aspects: usability, beauty, robustness. This included carrying out the following tasks:

  • We observed friends, family and various strangers use the app. The key thing here is to propose tasks and ask questions about what they are thinking, but never to answer their questions. Probe into why they are confused about something, and let them figure it out for themselves. Watch for body language that indicates confusion or frustration, and note not only whether they were able to accomplish a task, but how effortless and enjoyable their experience was.
  • We sought expert design reviews from top Apple designers, leading usability experts and fellow developers at conferences such as SxSW and WWDC.
  • We posted screenshots to Dribbble to get feedback on visuals from leading designers around the world.
  • We tested the app ourselves in real-world contexts using TestFlight.
  • Finally, we thoroughly tested functionality and searched hundreds of words to catch bugs and ensure robustness and accuracy.

Icon

We tried a lot of ideas before settling on the icon to the far right
We tried a lot of ideas before settling on the icon on the far right. Large view.

An app’s icon means a lot. It is the first impression most users will get of an app, and we hope users will want to have it on their precious home screen.

The first iteration of the Languages icon (the royal “L”) was simple but didn’t communicate much.

After a lot of brainstorming, we incorporated the idea of physical dictionaries on a shelf, since that was a major theme of the app. The icon was beautiful, but we couldn’t make it work well enough at small sizes. Additionally, a top designer at Apple recommended that we not use books because the app isn’t about reading.

Nuts. We really liked that icon, but we had to go back to the drawing board to find an instantly recognizable symbol that communicated the idea of translation and that wasn’t overused. A globe works pretty well, but we ultimately chose the “a” with an accent mark because it is unique and definitely communicates the idea of a foreign language. We lived with it on our home screens for a while, and it grew on us. Having aced the test of time, the icon proved to be the winner.

Next Step: Launch

Languages on iPhone
Large view.

We’ve come along way and learned a few things.

After a year of blood, sweat and tears, the product was finally where we wanted it to be. It didn’t have every feature that we intended to put in 1.0, but the features it did have were super-polished and ready for primetime. It was time to launch. I’ll cover our marketing and launch in my next post, so stay tuned.

(al)

↑ Back to top

Jeremy Olson (@jerols) is founder and lead designer at Tapity, a tiny Apple Design Award winning app company. His latest app, Languages, launched to much acclaim from Apple and the press, and peaked as the fifth top paid app on the App Store.

  1. 1

    I thought skeuomorphism was dead`?

    1
    • 2

      Not dead, out of style right now. I’ve posted my thoughts on Apple’s new design language on my blog: http://tapity.com/iphone-app-design/responding-to-ios-7/

      And for some context, we designed this app a year ago when heavier interfaces were still very much in vogue.

      1
    • 3

      I think saying that skeuromorphism is dead is like saying that typography is dead. Apple just replaced one type of skeuromorphism with another. With the new physics engine (which, by definition, is very skeuromorphic since it imitates real-world physics), parallax effect and “cards”, blurred bars (that look like frosty glass panels), and certain new transitions, it’s arguable that the phone feels just as skeuromorphic as before – but now instead of heavily-embelished, heavy objects it consists of stacks of slim, lightweight cards and windows.

      What _is_ gone is any sort of emphasis on chrome and textures. In fact, there are barely any textures left in Apple’s stock apps. That said, the Notes app uses a textured background, and you can find the same texture on high-quality resume paper. Frankly, I find the lack of textures very lacking in places. For example, the Newstand app just looks forced, bare, and unfinished/unpolished.

      7
      • 4

        Good point, skeuomorphism has definitely morphed in popular use and in it’s truest sense is still very much alive in iOS 7.

        1
  2. 5

    How many people total did this take to make this app?
    How much time did it take?
    How much money did it cost?

    This blog or for people that care about these topics. Please shed some light so we can understand how much of an investment it takes to build something like this…

    Cheers!

    3
    • 6

      We had three designers actively involved (but all of them were also working on other projects), two more business and management and idea types involved, and one main developer. At any given time there was usually about two or three people active on the project.

      But you don’t necessarily need that kind of team. For example, I built the first version of Grades all by myself.

      Since we weren’t paying anyone, the cost was just opportunity cost. Given our rates for clients, this project probably would have cost $70k-$120k or so. Mostly because we, unlike many of our clients, are willing to do so much iteration and experimentation with our own apps.

      9
  3. 7

    Great article.

    3
  4. 8

    Congratulations for an article so interesting. Three things among the many you’ve said with which I totally agree. First, to apply Krug’s philosophy, ‘do not make me think’ added to ‘do not make me work.’ The second one, to study the body language in user tests. I’ve been working with this for two years and I am amazed with the results. Not only should we analyze what people say, also things they don’t say. Percibe the uncomfortableness to avoid future use problems. The last one, to make an experience map before personas. This practice helps us to get into the skin of users and their everyday problems which we try to minimize with our applications.

    7
  5. 10

    Impressive, dear Olson. Inspiring for many amateurs, generating ideas and implementation of the same, ‘Be Human’ methods and so much so.

    Loved the Shelf (Much Human …)

    2
  6. 11

    I love this article, its like project management in a nutshell, and the section on ‘Kill the baby’ perfectly summarised probably the hardest part of the whole process!

    3
  7. 12

    Impressive read from a highly impressive chap about no doubt a highly impressive product!

    1
  8. 13

    Sylvain Gauchet

    July 4, 2013 9:38 am

    Great article Jeremy, thanks for sharing. Looking forward to reading the next step!

    1
  9. 14

    Great Article Jerermy, as always.

    0
  10. 15

    Amazing article.. rarely do I find myself copying passages from an article to a separate document. I will READ and re-read the over any time when my faith in the perfectionist approacah is tested;)

    6
  11. 17

    Nice article, this’ll be my quote from now on ” Good design is more about subtraction than addition”

    6
  12. 18

    Great read with lessons for all projects not just apps. And I love that you cited “Don’t Make Me Think”, a book so relevant that even its title sums up the entire book.

    0
  13. 19

    Amazing article:)

    0
  14. 20

    How about Android version?

    0
    • 21

      We don’t do Android apps at the moment.

      0
      • 22

        Hey Jeremy,
        This is a fantastic article, and had something in it for all the different people involved – idea generators, market research folk, product managers, design folk, developers, everyone! Thank you for sharing this! Our CEO sent it to a bunch of us, recommending we read it!

        On a different note – your app sounds like a great idea, and we (Extentia Information Technology – http://www.extentia.com) would love to be associated with it. We do Android apps, and have experience in the translation domain. Do let us know if you’d like to explore the opportunity to work together.
        Cheers!
        Farah

        0
      • 23

        I look really forward to the next phase ;-) But so sad to hear no Android version (and/or Windows (phone) 8?)… Are there specific reasons for this choice? I often feel the real design challenge is in creating a responsive, lo-to-hi DPI smartphone to TV sized version in both landscape or portrait. With an icon that’s beautiful on all home screens ;-). The iPhone is pretty much what you see is what you get, and on iPad x2. Unless you choose to develop a specific iPad version of course.

        But in Android, I feel you could do so much more, like a quick translate widget in the homescreen, the notification drawer, or even on the lockscreen (Android 4.2) which would make the whole deal of translating even faster (no need for pin / unlock or even open the app.)

        I would seriously reconsider this choice for soon the booming markets in India and even Africa are massively buying Android devices. More users = more money… You leave out 50% and soon more of your possible audience. I like the iPhone and iPad, but I also like Android, and I feel Windows 8 is a fantastic experience on both phones, tablets and PC’s… They’ve come a long way too since the introduction of the iPhone 6 years ago ;-) And in some ways I even feel they’ve surpassed the iPhone user interface/experience. Instagram, Facebook, twitter, Angry Birds… they all open up for the other 50%…

        For the next steps, I really hope to read about the Database and engine choices and compression etc. How you keep the app small and effciciënt.

        Good luck and a big congratulations on this awesome article!

        0
      • 24

        Apple holds less than 20% of the global smartphone market, with Android accounting for over 70% of the market.

        You need to jump on the Android wagon…

        0
  15. 25

    Juan González

    July 5, 2013 3:43 am

    Whenever I see someone write plenty and carefully about their work I know that’s someone who loves what they do and feel pride on the results of the effort.

    This is a great read, as others mentioned on their comments I’m looking forward to the next article describing the “after launch” phase and if you could at some point give a hint on crew and budget it’d also be great. I know sometimes this cannot be disclose but it’s always worth the try.

    Keep the good work Jeremy!

    0
  16. 27

    Great article Jeremy, thanks for sharing. :)

    0
  17. 28

    What an awesome post, really got my brain flowing for a second.

    0
  18. 29

    Wow, such a great article! It has many helpful aspects and it was really fun to read! I really loved reading it!

    2
  19. 30

    Anthon Jackman

    July 5, 2013 5:51 am

    Great article guys, I’m thinking about joining the app making community and that gave me great insight into what to expect.

    0
  20. 31

    So how did your “little app beat angry birds” or was the first paragraph referring to articles that have yet to be published?

    0
  21. 33

    Awesome article, and helpful too for timelines.

    1
  22. 34

    By any chance, could you post the PSD files for those icons and let others use it freely please … Unless you’ve a use for them.

    0
  23. 35

    Very good article, thanks!

    Thought, I would only like to point out that Thomas Edison didn’t invent the light bulb. He improved it, based on work done by others before him.

    0
  24. 36

    Your blog is really awesome, I am planning to build a new app. I have really searched the android store and found only crappy apps for my idea. I just want to ask how much does a professional app cost. I know the basics of android programming but do you recommend hiring a professional to help me?

    Thanks

    0
    • 37

      If you can learn to do it yourself, I think it’s always a good experience to at least try to build it yourself first. You’ll learn a lot!

      1
  25. 38

    Hi Jeremy, this is a wonderful post. I’m looking forward to reading your next piece of launch and the marketing aspects of the app, which is something I personally haven’t fully grasp. Having launched a couple of apps, one of which I think looks amazing (called 60Hz) I am still falling over with the marketing aspects and what it takes.

    Quick question for you:
    How did you start having a relationship with Apple designers / other app makers? Living in Brisbane, AU, it’s been hard to form any kind of relationship with “known” people.

    Thanks for the article.

    0
  26. 40

    Thanks for this great and informative article Jeremy!

    0
  27. 41

    Absolutely fantastic article! Bookmarked and shared. “Good design is more about subtraction than addition”: absolutely true.

    There’s a similar quote that I often say: “You don’t achieve perfection when there is nothing left to add, but rather when there is nothing left to take away.”

    Congratulations on the app. :)

    1
  28. 43

    First and most importantly of all: great article. Agree with all of the other comments praising this post. Can’t wait for Part 2!

    One minor bug though, “it turns out that we nailed this: 70% of our sales ended up being from outside the US” – what percentage of iOS installs are you assuming to be outside of the U.S? I would assume that it’s around (or more than) 70%.

    -2
    • 44

      It was nothing like that for our previous apps. In my experience you generally make by far the most sales in the US.

      1
  29. 45

    I enjoyed your article. Thank you for sharing.

    0
  30. 46

    Fantastic breakdown! I love to see behind the scenes, especially what went wrong and how it was dealt with, never compromising on quality or functionality.

    Very well written Jeremy, Top Notch!

    0
  31. 48

    I really enjoyed reading this article. I loved how your process was clearly defined.

    Bravo!

    0
  32. 49

    This is now bookmarked. I’m so glad I was in a developing slump and decided to whip over to SmashingMag for some inspiration! Our core product is an online website builder, and I’m currently working on mobile browser support. While some of the features and concerns you listed in your article don’t apply to a mobile browser app, many such as simplistic interface and a streamlined feature-set are critical.

    I’m a big fan of Ian Cooper’s “About Face” books, and the workflow you describe is very similar to his set of concepts. Can’t wait to read Part 2 of your article!

    Mike

    1
    • 50

      Thanks Mike! I’m really glad you found it helpful.

      I’m also a fan of Alan Cooper’s books.

      0
  33. 51

    Great article and a pleasant read. Looking forward to your next post.

    0
  34. 52

    This article speaks to me from the aspect of discovery, and product ownership. Thanks for sharing!

    0
  35. 53

    Jeremy, yet another of your articles blows my mind. This is a great guide to building a kick ass app. Quite a bit of this process has been paramount in our app development as well. I will try to incorporate these ideas in our current and future apps. I wish you the best of success with your business.

    0
  36. 54

    What dictionaries do you use in your app?

    0
  37. 55

    Great article Jeremy,
    You and your blog become my number #1 resources for app marketing.
    I read lots of books about the topic and developed dozens of apps – some more successful than others.

    I really like the process you describe here and this is the first time in my life that I really took care of reading all the comments and your responses to them. They add a lot more into the whole content you serve here.

    I’m in the process of developing my new game and I’m sure to take 110% of things you point here. It gives me energy and motivation to do so, not only to finish the app. I could have written the same post about my best successful app long time ago but I didn’t. Because of that I lost a lot of skills I had then and while I developed new apps I didn’t know why they aren’t successful. You got me back on the good track.

    Keep up the good work!

    0
  38. 56

    Jeremy, this was unbelievably helpful. My team and I also started creating our social application senior year of college less than a year ago and are in the stage of Alpha testing right now. We are currently redesigning our interface because we aren’t happy with the UI or most of the graphics themselves, so I completely understand the frustration and pain.

    It was great to see most of these steps we have implemented in the same sequential order, however my team and I have no one specializing in graphic design. I have two Architecture majors who are extremely helpful with implementing our ideas graphically (capable of using all CS6 products and currently using Omnigraffle), but we are looking for someone who can take our re-designed wire frames and give graphic design renovations. Do you have any advice on the most efficient way to look for someone who could be contracted for this position, or perhaps full time? If you have any recommendations on specific websites for job postings or anyone interested it would be greatly appreciated!

    I will be sure to keep up with your postings! Thank you for the great advice!

    0
  39. 57

    Super!
    I’m just starting in this, and this article is amazing!
    is just what you really want to know, and it really
    confirms a lot of what I’m doing right now!

    thanks for the tips and the great ideas to make it better!

    0
  40. 58

    “It took Edison thousands of failed attempts to invent the electric light bulb, and it would be foolish for us to reinvent it based on trial and error, now that we have a working model.”

    Unless you happen to be developing an entirely new form of bulb… Otherwise, all you’d get is an Edison bulb over and over again. Fluorescent tubes would never exist and you can forget LEDs.

    0
  41. 59

    This article was a lot of help. A question here… how feasible was it to have ur programmers based in Austria? I am looking for programmers to build an app, whose design, frankly is nt covered by my programming skill. So i wd like to ask if it is a good option to have ur programmers based somewhere else in the world… not being able to brainstorm design with them for a good time? Doesn’t the process get a bit tardy?

    0
  42. 60

    Seems like I’m a bit late to the party but wanted to congratulate you on this article. It has been really useful and the details of your process seem to have been the kick up the ass that I needed to get my app idea up and on the App store.
    Thanks

    0
  43. 61

    Stephanie Hughes

    March 6, 2014 2:52 pm

    Jeremy,

    Wonderful and insightful article. As a multi language learner myself, I love the way you approached making this language conversion app so much more than all or the majority that are currently out there all of which suffer the same issues you had identified in your user testing scenarios. You have solved the problems many of which most others have not solved and therefore their use is down.

    You have offered up an app that makes available for millions of people the beauty of more easily learning a new language. For many this becomes available for many people who only know one language and can now learn another – more easily and efficiently.

    Thanks,

    Stephanie Hughes
    Los Angeles, CA March 2014.

    0
  44. 62

    This is a superb article, thank you for sharing your experiences!

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top