Audience

audienceEverything that man has created has been created with an audience in mind.  We create things for ourselves, for others and sometimes, we create for both ourselves and others.  As application developers, this is just as true.

As we design apps, we need to determine who our core audience is.  This can be tricky enough but when looking at mobile apps, I believe we often miss the mark by including one extra person in the target group who rarely belongs there.  This extra person is ourselves.

Building this for me

As developers, you have likely created tons of little programs or scripts that are just for you.  These work great for you and might even be extremely helpful for someone else but they are not very polished and they rarely seem worth the extra effort to generalize and package them up for general consumption. 

If you ever have taken one of these personal projects and made them available for the public you likely have had to make plenty of changes to make it understandable or even workable. In my experience, if you ever decided to share them with a group of general public (read non-developers), you will wish you had not or at least wish you had started with that in mind to begin with.  The transformation here can be huge.

This app is for people who love ‘x’, just like me

Building something that you will use yourself and will share with others for their use is a lot of fun.  You are excited about what you are building and if you are honest with yourself, you are sure the most everyone else with a similar passion will love it too. 

While these projects are great, they often tend to focus on what you want the app to do.  You love ‘x’ and this is the best way to do/share/collect ‘x’.  (You get the idea here.)  Depending on your true aim for the app, this likely is not ideal.  If you are really just building the app for yourself and will let people use it if it suits them, then keep on truckin’.  There is nothing for you to see here.  However, if you are really building it for the masses (of which you happen to be a passionate member of), then you need to tread carefully.

First off, as a developer, we tend to be tech savvy.  We know how things work, how to find and set options, and are often considered a master of every thing software related by most everyone we know.  What we see clearly, the average users often sees through a fog.  You likely already know this, but when things seem so easy to us, we tend to not see how it might not be clear to others.  This is always a trap for developers.

Our passion for ‘x’ and our desire to see it ‘done right’ tend to lead to complexity. We want to build a better mouse trap so to speak.  It might be called “no feature left behind” syndrome.  More does not equal better.

This kind of thinking tends to make us think of pruning.  We are trimming back the features and the UI to make things easy, light and wonderful.  However, I disagree.  Pruning is not the ideal answer.

I made this for you

When we do a project for someone else, we are not a user and have no idea what they need.  We need to watch, learn, and ask a ton of questions.  It is not uncommon for me to do a client project and build something I think is a bit odd, but my clients love.  Sure, I help them make design decisions.  We work on things together.  I share from my experience the things they should consider (and sometime beg them to reconsider), but in the end, I’m building something for them and they tell me how it should be.

As a mobile developer, we likely don’t have that kind of contractual deal going on and I think we miss out on the give and take with the client.  Often, we are trying to imagine our audience, what they need and what would delight them.  We might have a few perspective customers to bounce things off of, but it often comes back to us and how we envision our audience.

When we are part of that audience, the possibilities tend to get endless.  There are tons of ways to go with the app and things we could do.  The process can be become a pairing down of features and fitting in the things we need to stand out.

When we can keep ourselves out of that audience, I believe we get a different product.  The general audience would tell us to start with the very basics that they need.  Get them done right.  Make them drop dead simple to use.  Make them shiny.  If (and really only if) we get that knocked out, it might be really special if they could do one or two other things.  The number of times my first project meeting with a small business client end up with this basic message is close to 100%.  Yes, I add to the value of the project and design, but it is as a compliment to the client’s vision, not the driving force.

Experience

My first iOS app was another learning experience in audience as I made a simple game for children.  SudokuKids started out as a test app to get my feet wet in the iOS world, but I learned a ton along the way.  My in-house audience for this app start out to be my 3 oldest kids, ages 7, 6, and 4 at the time.  (Note: A app for young kids has an odd audience.  Parents are going to be selecting and buying the app.  Children are going to be my users.  From a design and usage perspective, I was mainly worried about usage by young kids.  Some things were done with the parents in mind though.)

So while I am a parent and could fit into the perspective buyer role, I was not a target user and was easy to keep out of the audience. I decided to spend lots of time watching my kids work on puzzles.  I watched them work on puzzles on paper.  I watched them with different interfaces and a few others puzzles.  I saw how they did things and what things they did.  I also saw many things I would have done they they never did.  I had to learn to hold my tongue as I watch them search for what to do or press next. I know that my kids, who had not spent a lot of time on the iPhone, had to be able to play the game without help or frustration and it should give them a good sense of accomplishment. This was an incredible learning experience (and lots of fun too).

As it turned out, a number of the things I had on my initial brainstorming list for my test app, never made it there.  I don’t feel like they are missing, only that I misunderstood what my audience might have wanted before I got to know them better.

I have heard a number of indie developers make comments to the effect of re-designing their apps so more people could understand them better.  I doubt this process is as effective as starting with that audience firmly in mind. Since we are often left with the job to envision our audience anyway, I'm just saying we should do our best to exclude ourselves from that group.  This is not to say that our design experience and awesome ideas are bad, just that they should not be the driving force of the design.  They are there to compliment it and make it special.