201 – Managing expectations

User Expectations:

We are into the second decade of the 21st century. People don’t want a program that just runs on their desktop PC and expects the user to have 50 hours of training to do one thing. In today’s fast paced, on the go, order-a-Frappuccino-from-your-cell-phone-while-walking-up-to-the-coffee-shop-door-because-we-just-don’t-have-time-to-stand-in-line world, what do people just automatically expect, etc.?

  • Cross-platform. Everything we do has to work on iOS, Android and UWP.
    • More than just work, it has to work intuitively and consistently. Nobody reads manuals. Heck nobody even provides manuals anymore. People expect to open an app and just know how it works and trust that it will keep them from hurting themselves (like not losing 2 hours of work because they didn’t explicitly hit ‘save’ before shutting down).
    • If they’ve used the app on their own iPhone then they expect to be able to grab the boss’s Android phone and be able to show them how it works, with all the same features in the same place. Yet at the same time it should feel like an iPhone app or an Android app to users familiar with the nuances of their devices.
  • Value added features such as social media, mapping, photos. More and more this is just expected. It’s not enough for your app to do its job. The user wants to post about themselves doing whatever it is your app facilitates. If it’s a recipe book program it can’t just show a recipe. It also has to have a built-in cooking timer, camera access (to photo the finished cookie) and Facebook access (to post the recipe along with the photo of the cookie). If it’s an on-line ordering app for a restaurant it also has to have a map/directions feature to guide the user to the restaurant and be the loyalty rewards tracker such as the Starbucks ‘Stars’ rewards or Burger-21 “punches” towards free food. If it’s an app to make labels, then it should also be able to order more label supplies directly from your client’s eStore.
  • Multi-cultural. It should work equally well in English or Klingon or whatever.
  • Multi-user. Mostly for the point of just doing it in our app, but we want to implement some sort of user-based operation and permissions system. If it’s a checkbook app the wife should see her files, the husband his, and the kids their allowance accounts but kids don’t have administrator permissions. If it’s a Point Of Sale app like the Ziosk tablets at TGIFriday etc. then the customer can pay their bill, but not have permission to alter the bill or change prices of dishes.
  • Bug reporting. It’s really nice for the developer if they can get direct reports from the user. It also helps the user feel like their experience and feedback is important. You may have done it with Visual Studio itself; using their bug/feedback reporting system to report a bug and include a screenshot from within the reporting system.
  • Instructions. Don’t laugh, lots of programs get released every day that either have no instructions because the developer just expected everyone would be able to intuitively figure it out, or they have a quickly written text document. I know I just said that nobody reads manuals and I stand by that statement. People do however sometimes need little examples or guides. They won’t take two hours to read a manual cover-to-cover. But they will take 30 seconds to read the single-screen guide on how to use the “make me skinny filter” of a selfie app. Nowadays people expect a nice slide show, or walk-through wizard showing them the overview of where everything is, what that funny squiggly icon means and so on. Maybe your app just needs a semi-transparent overlay pointing out where each button is and what it does, that pops up the first time the app is launched.
    • Proof read. Let your app and instructions sit for a couple days. Then proof read again. Then have someone else read them when you give them your app for testing. It makes you look really sloppy when you can’t even write the instructions for your own app without a bunch of typo’s and wrong words (to/too/two or than/then etc.).

Client Expectations:

You always have a client and stake holders when it comes to your programs. Sometimes the client is yourself, and the stake holders are you and maybe your friends and family if they are also going to receive copies of the app. If you have a full-time job developing, then your client is your employer and the stake holders are the end-users. If you are a freelance developer, then the client is the client that hired you. In the end, the client is the person signing the front of the paycheck and you are just the code monkey signing the back of the check. Meaning, they get whatever they want so you better manage what they want.

Depending on your client you may be granted a lot of latitude, or none at all. They may be reasonable about limitations, or not. But one thing is for sure: They will answer ‘yes’ to everything if you ask “Do you want blahblah?” So don’t offer what you don’t want to code. Clients often expect certain things as just automatically included and you get labeled as a bad developer if you don’t deliver even if it’s never been discussed and not in the contract. For example: Settings. Everyone just assumes there should be a Settings dialog somewhere for the user to pick folder locations and color schemes and who-knows-what-else. Nowadays people seem to just automatically expect social media integration. It’s just sort of “Well, yeah duh… Of course, I thought users would be able to post a Facebook review of our service from the app. Isn’t that just included in every app these days?” So, it’s incumbent on you to ask questions smartly, educate your client, and well define the project. You have to actively managing client expectations.