Your mission is to design an interface that facilitates personal or social behavior change. That is the brief of the capstone project in Interaction Design offered by UC San Diego through Coursera.
Needfinding: What are people looking for?
The process began by observing and interviewing people. I decided to focus my research on how people work towards their goals. I tried to find answers to the basic questions of how people motivate themselves, do they look outside for motivation, what deters them from achieving their goal and, how do they organize their tasks and track progress.
I realized that not all prefer to be organized with their tasks. While everyone wants their goals achieved, many did not like the idea of having to plan every task. There was a need to motivate people to work towards their goals without the calendar and deadline being the source of motivation.
Some design opportunities identified from the study include helping users focus on a goal, tracking their progress with a database that is not difficult to create, allowing users to prioritize their tasks and focus one at a time and making difficult goals seem simple to achieve. Reviewing my opportunities, I narrowed down to one point of view:
A goal that appears simple and fun to achieve will soon become a goal achieved.
Ideation: How is my app satisfying the user needs?
Based on the opportunities, I came up with 2 different design ideas. The first idea is to breakdown goals into tasks and further sub-tasks. The smaller the goal is broken into, the easier it seems to progress. And these tasks can be viewed as flashcards allowing the user to focus at one task at a time.
The second idea is to connect with people from the community with similar interests. People can challenge each other ultimately achieving the goal with better motivation. They can form private goal groups with friends or it could be just oneself. Or, it can also be a public goal that everyone from the community gets to participate in.
Prototyping: Translating ideas into reality
Based on the 2 storyboard ideas, I arrived at 2 different prototypes. They are low fidelity in nature with changes regularly and immediately made based on user testing.
These prototypes were tested and evaluated, with the help of my peers, according to Nielson’s heuristics and rated the severity of the error. The process helped in identifying many issues that I overlooked because I assumed certain things to be self- explanatory. But it only appears so to me because I have been working with all along. For example, a button with a tick mark was ambiguous. While I had meant it to mark a task as completed, users assumed it to be some kind of confirmation button.
Understandability was a major issue in the first prototype. Some clickable elements were not understood to be so, while it was understood for certain other elements but its function remained ambiguous.
The major issue with prototype 2 was feedback. There was no immediate feedback given on accepting or ignoring a challenge or on clicking on one marked in the calendar. There is no way to undo actions of, for example, if I accept or ignore one by mistake. Also, there was no way to access all the challenges consolidated.
Testing: And again!
The revised prototype based on the changes that developed from the heuristics evaluation is now to be tested again. But this time with the help of high-fidelity prototypes. This helped in better communication of, for example, identification of objects that are clickable and, accurate estimation of variables during testing. I chose to continue from here with prototype 2 as the base while incorporating certain features from my first one.
My paper prototype which had two different pages for personal and public goals the feature to able to alter privacy was not recognized easily. This time, I revised the home page to have the public goals listed horizontally and the listed vertically. But it remained ambiguous with one list getting misidentified as the task list.
Another issue was that horizontally scrollable sub-pages were not frequented. So I decided to do an A/B testing for the same. I performed my test on UserTesting with two versions for the app. In both, the homepage of a goal had a variation- one had chat written as text and placed next to other buttons and the second had a chat icon but was placed in the bottom left corner alone.
The results were unexpected! 3 of the 4 users tested clicked on the required page faster during the first time. The A/B users found the placement better because it was placed closer to the top left and clubbed with other tools. The B/A users, though they took an extra second because it was placed in the bottom left corner, were able to identify it quickly because of the icon. But finding the icon in the first version, they were looking for the same the second time as well.
Final prototype: Fit and finish
While the color palette is mostly shades of grey and blue, the occasional orange gives the energy and enthusiasm to accept challenges. Each cluster in the structure also has a different color format to ease navigation through unconscious learning.
Takeaways: What did I learn?
A major takeaway was to not look for a solution but to look for solutions. Because I was focused on finding the way to solve the issue my problem-solving iteration was linear consuming more time. I would work on a change and test it again only to realize that the revised version is as well not working. The worst part I would have started to work on detailing all of which starts to move during revisions.
A better methodology would have been paper prototyping different possible solutions, testing all of them and choosing the best. That way I could have cut on the number of testings required.