Daily Dash — Design Journey
Daily Dash — An app that frees you from your notifications and updates every morning, and lets you make the most of your day.
In the Interaction Design Specialisation on Coursera, the last course in a series of 8 courses was the Capstone* Project. In this post, I will talk about the various tasks we covered as part of the project with the hope that it will enable you to understand the design journey in creating of a rudimentary mobile application.
*Capstone: the final stone placed at the top of a building or a monument.
This post is a summary of all that was taught over the 7 different courses as part of the specialisation. I hope this helps explain the various aspects of a design journey to achieve a full-fledged running application. Although due to time and technical constraints the final outcome of this project was just a hi-level prototype of the application mentioned.
The Capstone project started with a choice from three design briefs:
- Time — Redesign the way we experience or interact with time
- Change — Design an interface that facilitates personal or social behaviour change
- Glance — Find people and design a personal dashboard to their needs
From the above mentioned design briefs, I picked Glance. As part of the course’s capstone project, there were a few tasks we had to complete over the period of 10 weeks. These tasks are the essential steps in process of designing a product:
Needfinding, Storyboarding and Prototyping
Having decided on the brief, I knew my task was to find people and design a personal dashboard to their needs. To start with, i started with observing a few colleagues and relatives in their daily activities. I spoke to them trying to find one common annoyance in their daily activity. One thing that stood out was the amount of time each of them wasted on the phone every morning.
Followed by a round of brainstorming and ideation around how to solve that problem, I created a high level strategy for the solution and tried to look around for existing solutions around the same set of ideas.
With that in place, I worked on creating sketches of prototypes and storyboard to properly understand and convey the use-case of the product. The paper prototype was the first interactable interface to help understand if i was heading in the right direction.
A quick prototype helps to fail early and learn quickly.
Heuristic Evaluation and Wireframes
With the first level of prototype ready, I was ready to do some basic heuristic evaluation of the application. I used the Nielsen’s Heuristics Guidelines to evaluate the walkthroughs I had created. I conducted an in-person evaluation where I asked the user to do certain tasks and talk aloud while attempting each task. I also created a tappable prototype for an online evaluation by a peer of the same sketch-level paper prototype.
Collating the information from both the evaluations, I decided on what changes needed to be made and came up with a low-fidelity wireframes for the application. I tried to capture most of the details of the app layout in this without delving into the visual aspects of the application.
Wireframes are a barebone look of an application.
Development Plan, Visual Design and User Testing
Once the wireframes were ready and I was done with one round of heuristic evaluation on those — I set out to create a Development plan for the remaining weeks. The plan would contain a detailed list of tasks that needed to be completed each week before the final week to get a final interactive prototype ready.
With the limited vision about the final state of the application, I started creating all the screens with proper visual design. And connect each screen with the next with the proper desired animation.
Once that was set, I started with testing the interactive prototype with the peers. Based on feedback received in the week’s testing, I made updates to the development plan, visual design and interactions of the app wherever necessary.
Final Thoughts
In conclusion, I know there were places I could have done better — maybe better visual designs or creating a better development plan. But with the limited time of a week, and with the constant worry of losing timeline it is usually a rush to finish assignments in which a few processes are usually ignored.
The course has definitely been a trove of immense learning. I started this course in October 2018 and I am writing this post in late May 2019 — which goes to say a lot about missed timelines. But in that duration, I have implemented the lessons from this course at several places on my current job and I am really glad to finally finish this assignment.