Case Study: Dashboard
About the Project
My Role: UX and Visual Design
One of the first projects I worked on at StackMob was re-doing the Dashboard (our web app). Among other things, we wanted it to look more like an interactive web app, rather than a series of web pages.
Some other central goals were to accommodate the introduction of the Marketplace, make the app easier to use as well as more visually consistent, and increasing engagement.
StackMob was an SF based startup building mobile backend technology for enterprise and indie developers. We were acquired by PayPal in December 2013.
- Introducing the "Marketplace" model meant seperating a lot of functionality into "modules" that could be added and removed from an app.
- We found that users who made an API call were more likely to return. Likewise, users who deployed to production were more likely to purchase a package. We needed to find a way to increase these metrics.
- The Dashboard was constantly evolving as we built new features, so the design had to be flexible enough to accomodate additions and changes without starting from scratch.
“I worked with Missy and did the technical implementation of her designs for over a year. It was a startup atmosphere where requirements change just as fast as solutions are created. Missy is able to embrace that change and iterate quickly and effectively; at times with many large modifications in the same day.”
— Justin Wyne
Software Developer, StackMob
The Dashboard overhaul started the introduction of the Marketplace. The functionality was sectioned out into "modules" that were installed (and sometimes sold as extras) individually.
Category with Hero
It was important move seamlessly from the Marketplace to the Dashboard. At the same time, the differences between the them needed to be clear. One of the ways we solved this problem was by letting user upgrade and downgrade directly from the dashboard.
More Module Examples
Module: API Versions
Deep Dive: Collaboration
One of StackMob's most complex Modules was "Collaboration", the ability to work with team members on a single app or multiple apps in an Org. The functionality was complex but robust. We wanted to make sure that users without collaborators weren't confused by excess UI, but we also wanted them to know that the functionality was available should they need it in the future.
Outcome and Learnings
- This was a robust project that was ongoing for my entire time at StackMob. Because I didn't always have bandwidth for every small, new feature or change, I really learned to trust our front-end team to make some design decisions. It was so helpful to be able to rely on them and to know that if any major changes were coming, they'd keep me well in the loop.
- This was also a lesson in trade-offs. Because of the way our backend infrastructure was built back when dinosaurs roamed the earth, there were certain changes that we just couldn't make because it would require re-architecturing huge swaths of code. Because of this, some UX had to be sacrificed, most notably in the Collaboration module. However, because of this, we were also challenged to think of sneaky, creative ways to make the experience as easy to use and understand as possible, and I think we did a pretty good job with what we had to work with.