Osito; digital personal assistant
Osito was the future of the digital personal assistant. The implications of that are huge. We tried to push users information right when they needed it. Contextual computing is the future of our interaction with our devices. It is a problem with nuanced implementation concerns. I’ve been thinking about proactive machines since college – it was incredibly fun work.
How it began
I joined the team as Designer when our product was just taking shape. The app had a rough UI and some branding under a different name. I was tasked with designing the app (experience, ui, visual design), the marketing site, and the new brand.
“triggers“ and “actions“. – Wait, huh?
Imagine you have a personal assistant and he can read your email. He’d have lots of info about you since you live together 40+ hours every week. An email from Nancy might be a trigger you to schedule a meeting if her project is over budget. Or there might be a weather event that is going to make you late to your next meeting. You’d expect an assistant to let you know when to leave.
As we added the triggers (events that signal our systemt to act), we started to uncover how much data the average person truly processes on their mobile device. Emails, chats, receipts, weather, traffic, etc. become a large scale operation for even the most tech-averse among us.
Initial UI Designs
After sketching some UI concepts I started to drive the team toward a card-based interface fig 1. It became very clear that each module was independent of the others. Each module needed a distinct hierarchy. To Photoshop!
The text-heavy data needed to be presented quickly. Once you start putting disparate data into the mix, you get some long absorption times (reading, not acting). We quickly decided to build a grid-based card system with standardized button / action placement and a strict typographical hierarchy.
The goal was twofold – give the user a block they could remember and simplify things on the engineering side. This was accomplished by a mix of color, type, and infographics (maps, charts, etc.). We always got great feedback on this side of the app.
People were less happy about with our communication of upcoming events. These half-baked triggers were just that; half-baked as-in we can’t predict traffic. The result is either too many notifications or omitting these notifications entirely.
This started to come together over a few weeks in January/February of 2013. We were targeting an April release which made this visual overhaul a bit harrowing. As a result, I happened to jump in the iOS repo and start hacking away on the welcome flow. This was actually the first time I’d opened Xcode - it was a bit daunting, but really fun.
Making wide-reaching consumer apps is hard. Who do you test with? What is the target user’s interest in an app like this? Where do we go when we only get general feedback?
I think that building Osito taught the entire team about focus in the sphere of a product. We lacked it; we tried to design for very broad uses and it burned us. Once the app was released, we got some really great feedback that made us rethink the entirety of what we were building.
Halfway to a Pivot
We learned that users wanted control - without it they felt adrift in our system. Users had a hard time relying on Osito to get them the data they needed. Users wanted to know *what* was being tracked and that it *was* being tracked at a threshold they thought prudent.
We developed a stop-gap solution that we called Look-Ahead (fig. 2). Look-Ahead was essentially a dashboard that kept our users in the loop as to what was next on Osito’s radar. We tried to compartmentalize the triggers and help the user understand what information Osito was looking for.
Osito was an attempt to simplify interacting with your phone and became an act of reassuring the user that we were paying attention. Osito lacked the feedback loop that users crave. Bolting on a feedback loop ultimately didn’t work. Eventually we did pivot toward our strongest trigger - email. That is a story for a different case study…
While I typically start with wireframes, this project warranted a different approach. Features were sketched on whiteboards and occasionally paper. Those were then put through the photoshop wringer almost immediately. It made for some fast turnarounds, but process is a thing that you need to weigh when moving this fast.
I went looking for comps of the site and I can’t find any; I think this was completely designed in the browser with the exception of the graphic assets. The site was featured on a few inspiration sites as an example of “minimal design”. Launched right before iOS7 was released kicking us all adown the minimal path.
This was my first experience with Jekyll + SASS. Our iOS engineer was a big fan of Jekyll. I had heard of SASS before, but the combo really is amazing. They are still a big part of my workflow for web projects.