In the pre-design phase I worked with a designer from TCS's Mobility Lab to come up with solutions for user complaints. This was especially challenging because we were not allowed to change the service API layer. Design solutions had to be found that would not change the underlying logic.
We defined the primary purpose of the app. Our aim was to optimize the app for what 90% of the users do 90% of the time.
Next, we identified problem-areas using data that we had from our app analytics (we use Omniture), user comments in the App Store, our Business Intelligence team, and from our Customer Support team. With this list of problems we had to define our scope for this project and put the rest in our future wishlist.
With the scope defined, we started the design phase. In the first week our motive was to define a feel for the new design - colour, typography and basic elements. We created about ten screens and met with members from business, marketing, branding, and legal teams so that everyone liked the general "feel" of the design.
Over the next three weeks the rest of the screens were created in batches, reviewed in working meetings, and presented again after incorporating feedback.
When 70% of the screens had been designed, we identified scenarios for user testing. This included the navigation, a few of the more complicated flows, and our primary focus - the payment process. We set specific time-goals for how long it takes for the user to make their monthly payment for the most common scenario.
We started coding the prototype to be used for user-testing, with an aim to write code such that the prototype won't be a throwaway once the testing was over. We replaced service calls with local JSON files, but the choice of framework (we were using Cordova with Backbone JS for integration) were going to stay on in the actual app.
For the prototype we did not bother to optimize for older phones - instead focusing on speed by targeting the devices that most of our users use.
We created the test plan on usertesting.com, writing and rewriting the copy to make it easier for the users to follow. We settled on a combination of demographics of our testers (age and gender) based on the data we have on our app usage from our BI team. We tested the test plan internally in the office before running a test with a single user on usertesting.com. When we saw the results come in for one tester, we reviewed it, and then we ran the test for the rest of our target numbers of testers.
Based on the feedback from our testers we made changes to our screens and ran our tests again. It is shocking to see how little changes can vastly improve the usability of an app!
With this we are continuing on the construction of our app, tidying up the CSS with SASS, creating the rest of the screens, replacing hard-coded values with API calls, handling errors, and so on. Once we are done with our functional testing, we plan to go back for a final round of user testing just before the launch to test out a few more scenarios on the finished product.