Case Study
Sprout Social
Sprout Social’s product requirements were subject to a rapidly evolving technical and social environment. API modifications might abruptly add or remove a feature, and unexpected social trends might suddenly necessitate new content or communication controls.
The challenges were compounded by going through the growing pains of taking the design process from working in Illustrator to Sketch. The beginnings of a design system were floated during my last months at the company as well, with a solid year or so of conversation leading up to this adoption happening.
Every solution had been designed and coded a la carte. There was feature and code sprawl everywhere, the result of a startup company that had to move fast to accommodate demand. My time at Sprout was spent balancing the need for new features against the need to consolidate UI elements and its codebase so that the application could be agile enough to deliver as it evolved.
Universal Search &
Brand Keyword Creator
Sprout Social’s core functionalities had become more complex and more fractured as social networks developed and deployed their own features. I identified the Search experience as a place where we could centralize a number of essential functions, creating unified experiences that educated the user and worked harmoniously with other disparate areas of the app.
Most critically, the redesign of Search allowed the user to have a single, central touchstone that the majority of their daily functions could begin with. It was easy to get several layers deep into a user flow process and be left without a clear starting point. Unifying Search so that it allowed the user to find their way back, or begin a critical process such as Brand Keyword creation, effectively provided a lighthouse for the user to point their way toward.
Platform Agnostic Chat
As social media companies began shifting further toward customer support and service, Sprout had to evolve its communication methods to match. This meant developing a platform-agnostic chat system which accounted for the variation in API call limitations, pre-canned responses, and types of automated bots that each network employed.
Suggested Replies
Google had just started beta testing their own email replies, and Sprout had heard from clients for years that they wanted the ability to use predicted or canned responses to cut down on engagement time. The primary challenge in designing the Suggested Replies solution was working within patchworked legacy code without sacrificing the user’s experience. The solution that was deployed after countless meetings and explored workarounds was simple, unassuming, and most importantly effective for the user.
Trial Education Client Helper
When I first started at Sprout, I wrote note after note detailing how the user was or wasn’t educated on how to interact with the application. I wanted to observe and note as much of the app’s successes and shortcomings as possible while I still had the newcomer mindset.
One of the core features of Sprout is allowing the user to take messages of all kinds and designated them as things to be addressed, often for sales leads or the support team to follow up on. This feature routinely needed to be explained by support as nothing existed within the app to clue the user in to where to begin this process or how to carry it through to completion.
That started the thought process of designing a system that existed passively when the feature allowed for self-discovery and reinforcement, but could pivot to an active instructor when features were processes spread throughout the app.
