The ClickSnap app was my second iPhone app design project, and a very different and focused process. From day one all team members were involved and we had a clearer mandate. With a limited amount of time to design and build the app, we were able to work backwards to define a minimum usable product which has served us well since.
The shorter development time meant we were able to be more focused around which features were necessary. We also needed to move quickly to wireframe out the initial experience and create a prototype from the high-fidelity designs to communicate to stakeholders what was possible and how the interactions would work.
Design & develop a standalone native ClickSnap mobile app focused on core features for in-store use.
The team consisted of our product owner, project manager, mobile developer and myself the ux/ui designer. I was involved from start to finish working on strategy, research, wireframes, UI design and prototyping, and creating the final design style guide and assets.
We successfully designed and built the app within our original timeframe. While we allowed an average amount of time for the app store submission process, at the time of submission approval was taking more than two weeks. Despite the time pressure the mobile developer built a stable app which has been in the app store for nearly two years.
The process began with a review of competative research and product usage. We listed all the desired outcomes, and the wish list of features proposed by the stakeholders. All current product features were itemised and we sorted them according to need and importance, then put a rough development estimate against each feature. This allowed us to make a wish list of prioritised features, and only eliminate the outliers that would delay the project or posed little value to the member.
After the examination of the research we invested some time questioning the brief to better define the goals, requirements, and core functionality. We had a list of features as requested by the stakeholders, however we needed to examine each feature to identify the intended goal and if it met our mvp criteria.
We sketched out the basic user flows around the two main features of the app: seeing offers and uploading a receipt. At a macro-level we knew from the product on the site there were some selections the user would still need to make, however we saved this granularity to the wireframes stage.
With a clear set of user goals and features, we began mapping out each interaction including the main offers feed, menu, sign in and join journey, and offer redemption and receipt upload feature. Two principles guided the design; the content would be shaped by the web version, and the app’s UI would set the standard for a future main app update. However I had been able to lay a considerable amount of groundwork with the UI. Instead the bulk of time was spent on sketching out the core features and iterating through the wireframes the main interactions.
The majority of interaction and functionality issues arose at this stage. We worked out a number of pathways, mocked up in lo-fi wireframes, and choose the best journeys. One major change at this stage was in the redeem feature where we needed to include an extra step asking for the purchase date. This came about due to the overlap of promotion periods. The extra step may have been an additional task for the user but the benefits were worth it (reduction of offers downloaded and displayed on the phone, and increased speed of redemption) At this point the UI was refined to produce the high-fidelity designs for the prototype.
We had scheduled a little extra time to transform the high-fidelity mockups into a Keynote prototype in order to accommplish two goals: test out the basic interactions and get final stakeholder buy-in before full development began. I was able to use the Keynote presentation to demonstrate the near-final user journey both to the project manager and the developer, and to also use the prototype with a few colleagues who hadn't otherwise been involved. Those final checks allowed for a few adjustments before the final demo.
One drawback that I found when using Keynote for prototypes is the linear journey the presentation takes. In user testing this allowed us to observe and note areas where users expected certain behaviours. For the demo it meant prefacing the presentation that the flow would be one-way and that we'd make one quick pass then return to key areas during a feedback round.
The final design phase was to write a design spec to accompany the user stories and provided assets to the developer. While the developer also had the prototype, the design process hadn't ended. A few final tweaks were made particularly in realising in Xcode many of the interactions shown in the Keynote prototype, and making adjustments to shadowing and colours mostly to support older iPhone models. As the final builds were seeded out over Testflight, I began testing out the app in local grocery stores.