In late April, 2014 I was an attendee at the Windows Build conference. Conferences are a great way to “get out” and focus on higher level items rather than fight through the weeds. A number of conference sessions focused on apps, user experience, and data services, and it got me thinking “why don’t we have an app” (we being the company I work for). Simultaneously, our CEO was walking around the home office saying “why don’t we have an app!?” The CEO wanted an app, that’s the ultimate blessing for a project, and away we went.
Late April of this year, and we we’re putting the finishing touches on the app, and it’s amazing to look back and see all the lessons learned throughout the process. As a software developer, there have been so many times I could take an idea and start to make it real, even if only a proof of concept. In the iOS world I can’t do that however, I dont have the toolset to scaffold out an app, it’s just not who I currently am. So, the internal team and I had to start from square 1,which was finding out who could possibly build this thing.. and along the way determine what “this thing” could be! It was a great learning experience, and looking back I think these are some of the key takeaways.
1. Know your customer – This isn’t a recommendation on how to come up with a killer app, this is how an outsourced development firm should treat you. We had a number of mis-fires throughout our development period, mostly due to a simple problem, our offshore team didn’t understand what we do. Our app is to help sell vehicle service contracts, our offshore team wanted to design software and write code, not learn about US manufacturing and warranty periods. The problem was, the “simple” parts of our application – show videos or PDFs – they ran with. The most critical pieces they fumbled along the way because they inherently didn’t understand what data the app needed to handle and disregard.
2. Know how to track issues – Our offshore team used their own custom software to report issues, track feedback and answer questions. The problem was, it was essentially a private discussion board. So, imagine what life was like when we received a new release, tested, and posted feedback to the system as one massive message. There were no “tracking numbers”, instead our tracking system involved referring to items like a Friends episode - “that one issue where the app crashes if you don’t enter any data on the fourth field”. We also lacked any categorization – all issues were just that, issues. What was important and what wasn’t was difficult to follow.
During the final few weeks of development, we took over bug tracking capabilities. We went somewhat old school, just an excel spreadsheet, but it logged each item as an individual task, with priority, examples and dates. This was the decision that helped put our app into the store. We were able to categorically indicate “we have 20 critical\high issues that we need closed” gave the offshore team a focused intensity towards what was important and what wasn’t. It also helped us communicate internally how close we were to launch, and if deadlines were going to be impacted.
3. Know when your partnership changes – Another issue we had was how our development process progressed with our offsite team. The first half of the project was all design – pictures, images, text – how will the app look and feel. What will it do. Forget how data will input and output, what will this thing feel like. Once our design was signed-off, most of the designers moved on to another project. The problem here was, there was a “reason” we designed things a certain way. We talked alot about the emotion and meaning behind our imagery, and our use cases on how a screen would work. When developers were making the app work, they didn’t inherently understand “why” we did certain things certain ways, and the functionality came out clunky and took a lot more time than anticipated to make the app work.
4. Know how to motivate people to test – We had a number of meetings during the past year, and many of them involved conversations that boiled down to “this is THE most important project you are working on.” It really helped understand that nothing short of a production outage should take precedence over working on this project. It was rather aggravating then when it came time to test and we couldn’t find anyone – not a single soul – to help test our app. We would send emails, chat in a hallway, place phone calls and talk to managers. Finally I had had it, I sent a plea for help to the requested testing team – 10 people in total! “Please”, I said, “We desperately need your help! Just one hour of your time!” I even offered to purchase lunch to whomever could find the most defects. 2 out of 10 people tested (and yes, I bought both of them lunch).
The optimist in me tells me that this final plea came at a bad time, that my co-workers aren’t heartless employees who don’t like a free lunch, but that if I gave them a week to test rather than that one day, I would get results. The problem was, we were asking for weeks on end for help, timing never really worked out, and in the end a majority of the testing was done by myself and the 2 people who worked on the project with me, which wasn’t the same amount of hardline testing we were hoping for.
5. Understand Apple Trademarks – So apparently, if you name your app “Company XYZ iPad App” – you’re not only in trademark violation, your app will get rejected. However, if you name your app “Company XYZ App for iPad”, you’re fine! We didn’t know this, and it caused our app to get rejected almost immediately when we published for review. Fortunately, it was a quick turnaround to change our title and get it submitted again.
6. You can request an expedited review of your app, but it still takes some time – We submitted our app, and within hours we were getting it reviewed. Our app had some basic features, and within 24 hours we were approved to go to the app store, solidifying that we would hit our deadline. Then we learned that the waiting is the hardest part. It took another 36 hours since original approval to actually appear in the app store!
All in all, many of the items above aren’t so much “app” lessons learned, they’re more or less general items that relate to any software development project. Still, all’s well that end’s well, and we’re proud to have our first app in the store, and hopefully this is the first of many.