Flow: A Prototype to Manage Time and Nudge Positive Behaviour
Sometimes I just need to be told what to do.
Met with the shifting demands of each day and that never-ending pursuit of a balanced lifestyle I, and others that I spoke with, could do with some help with the additional task of actually managing it all, of “keeping it all together” so to speak, and help with not only ensuring we keep up with healthy habits, but also to engage in events we find happiness in.
On top of that, after some research it became clear that dealing with entering our usual tasks and events in calendars and checking with conflicts with our contacts, the weather, or “wait that night’s the GOT premiere” could do with a bit of an overhaul.
Flow is an app prototype to help with that. It’s the culmination of a course I took on Coursera, taught by Scott Klemmer out of The Design Lab of UCSD, and here’s some background on the ideation, research, and prototype process.
Exploratory Research and Needfinding
We were given three broad areas to work in, time, change, and glance. I chose to work in the area of time, to see how people managed it, but eventually change (due to the idea of nudging people) and glance (the app design itself) were part of the mix.
I interviewed three people and asked them to show me how they went about organizing and managing their time.
As I watched them handle phones and notes I also asked them open-ended questions about what they found easy, hard, wishes, shortcuts and workarounds, and really about how they just ran a day or month
After the user observations and interviews, I brainstormed and looked at other applications or processes that were relevant for inspiration, and came up with a point view and some foundational points to start from.
First, paper is going nowhere. Paper and notes just have some inherent advantages to them, plus I suspect it’s partly the aesthetic experience and familiarity we have handling paper, pen and pencil. The advantages are clear even in this very interaction design process in the form of rapid paper prototyping. This is paralleled in any discussion of Ebooks and paper books, and I think the conclusion is the same: The former have done a good job of mimicking, and have some advantages of their own, but the later will always have a place. For me, this meant I chose not to try and replace this method that some users had partly relied on, not consciously at least.
Second, making it easier and quicker to add events and tasks was not going to be easy because there are just a number of levels and decisions to be addressed. Voice is always an option to use, and this could be added to the app, but for now I chose to focus on the interaction design. I decided to take a gamble on using a radial marking menu for the design, having a timeline that a user could glance at change events easily, and some shortcuts for common tasks or events.
Third, nudging people to do things would need to be quite seamless. I decided to take two main avenues, notifications and being available to suggest something when the user had free time on their hands and just asked for a suggestion. For on-demand, the user could enter a custom suggestion on what to do, just ask for an auto-generated one, or ask for one based on location.
This last part requires a lot going on behind the background in all likelihood, so just some comments on that.
I had planned for the app to show things like Meetups, Facebook groups, or local events (via sites like guidelive for DFW) on a calendar window above the daily timeline, and to also incorporate that information in notifications and for suggestions. This means extensive API access etc, and I’m not sure what is all possible given any restrictions, and memory or cell data usage, in an actual development cycle this would up front need to be run by the dev. team.
Also, I had imagined some functionality of the suggestion/notification feature that nudges (I’m just going to call this the Flow feature from now on) learning from the users’ behaviour, possibly using a Likert scale at some points after certain activities (pronounced Lick-urt). Something else that in reality would need to be run by a dev. team. And actually, for the current purposes, I largely dropped that feature although some user input is required, like make sure I stretch and meditate three times a week. This is partly because we in fact pretty much already know what makes most of us happy assuming good current health, and have a decent grasp on what promotes all-around well-being and healthy ageing.
My final point of view was that there is an opportunity to fill a need void by providing an intuitive, easy to use interface to manage time, nudge people to stay on track if needed and suggest ways to use open time, and that any solution must be flexible to people’s different needs.
Ideation and Rapid Prototyping
The first stage of prototyping was some pen to paper. I came up with some storyboards to help set the stage with some stories. Then, I turned to mapping out the user journey, information architecture and some layout thoughts, and turned these into some paper prototypes, then tested the paper prototypes with people from class.
After testing with the paper prototype, it became clear it would be tricky to separate the notions of adding an event, task, including a to-do list, and being able to ask for suggestions because of the similarity both conceptually and label wise (i.e. to do vs. task). Another issue was cluing people in to the timeline and what it actually was, a quick way to see the days events and change them if needed.
Hi-Fidelity Prototyping with A/B Testing and Design Changes
I used Figma for the design and InVision for the interaction and user testing, testing first with classmates, then after some revisions ran two different versions in a small UserTesting session.
I decided to use the same flyout menu as the paper prototyping, but to move it to the middle of the screen with one on each side. The idea behind this was to give maximum space for the menus that would radiate out from the side. This, and the design of the menu itself, was a bad idea.
It became clear that it was a bad idea because the menu broke at least a couple of rules. The position of the menu button broke expectations but didn’t gain enough to warrant it. In an effort to make as many options possible with as few touches as possible, I had made all of them inaccessible in a way because the eye can’t move down the menu well, and it was noisy and just cognitively heavy — if everyone wins no one does.
I come from an academic background of neuro and cognitive science, so it was time to step back and just reassess what I should be doing from that and a UX perspective.
Ultimately I changed the location and menu design to something more similar to action buttons from material design because they were more familiar, but took the liberty of using two of them as opposed to one. stuck with a radial menu because I’m a bit keen on Fitt’s and Hick’s law (I changed the number of options that needed to be scanned initially), and also wanted the user to be able to just swipe in the relevant direction with muscle memory after a while.
What I learnt…
as I changed designs and had to reconsider my options is the value of letting things settle for a while to dwell on some of the principles of good UX then approach the app again, as well as User Testing to check my blindsides and gather data. I assume that with more practice, those principles are applied more efficiently.
Overall, my design decisions were based on trying to reduce cognitive load and present things in an intuitive format where functions were categorized sensibly. The challenge for an app like this, and many others that have deep functionality, is to have the foremost functions easily accessible and understandable, while at the same time providing access to more advanced users and users who want to get more out of the app.
I’ll likely have one more iteration of this app because it needs prototyping again in Axure, and I’ve come to firmly believe that apps with any in-depth function really need an on-boarding tour. Another feature to help with UX, that I touched upon before and I think is just as much about UX as it is modern apps is gleaning as much information about the user as needed so the user doesn’t have to input all kinds of preferences, as well as sharing information between apps.
It remains to be seen how far a user is willing to go in that regard — or given current tech how much info we actually need to paint an accurate portrait — but even given privacy concerns, judging by how much many now share with social media, I’m willing to bet many of us are willing to go quite some way if the benefits are robust enough.