In Spike, there is a very complex search and filter tool to allow users to find the most relevant content. It offers a lot of freedom to the experienced but neglects the novice. ​​​​​​​
It’s an intimidating place to land, and, we hypothesized, a key reason engagement falters after a few months.
We attempted to address this by creating an MVP of a new search feature.
It failed to create a simpler experience for several reasons, one of which was that the big intimidating search page still existed. We'd only layered complexity! 
In a workshop with stakeholders we re-examined the biggest pain points in Spike and determined that before we tackled the search again, we needed to give users more incentive to invest time in our product.
We needed to increase the reward, which for Spike users means finding relevant stories quickly. For an app that literally has all the world’s media as its variable reward, we were sure displaying it in a weak and limited way.
Users landing in Spike and, every day, regardless of how many saved searches they had, would see 2.5 to 3 of the top stories in the world, often completely irrelevant to them.​​​​​​​
Myself and the Product Manager turned to our past persona research in order to examine our users' common needs and behaviors around sifting through content.
Ultimately we combined them into a single broad persona as this functionality is a main tenant of our product: all of our personas need to view the content they have searched for.
In fact, we decided to lean heavily on a Job Story we knew applied to every persona who had hired Spike:
I interviewed users and pulled from research to create several as-is scenarios in the form of storyboards to help myself and the team understand how this fit into our users’ workflow. 
We also wanted to see the full range of their needs, because while we knew the initial idea would need to be Minimum Value, we also wanted to see that blue sky we could aim for.
We used our research and the Jobs To Be Done framework to get our multi-disciplinary team on the same page and in the right mindset to solve the problem for our users.
The workshop consisted of techniques I’d gleaned from Google Design Sprints and Nielson Norman Group’s methods. We planned to test and validate the resulting concept within the week.
These workshops are a wonderful way to not only get the devs excited and engaged with what they will be building, but to mine their brains for great ideas. The chosen concept turned out to come from our Front End Dev.
This method helps us continue collaborating throughout the lifecycle of the project. Even the most reticent devs will now call out suggestions to improve the UX at every stage.
The concept we moved forward with was a Modular Dashboard approach, which allowed our users to customize with the content and data they needed.
We chose to test the basic concept of a customizable dash with engaged clients before we went any further. I mocked up a dashboard in a day, with some small amount of polish (even though it wasn’t close to the final) so that users would not be thrown by a basic wireframe. 
The following week we had the first in-app prototype running with real data. It was a bare bones development; widgets could be hard coded but not saved. 
I knew testing with the actual content was really important and would effect our clients’ immersion. A stale news story could distract them from the test’s intent.
During the next two tests, with new clients, we got more and more specific with their use cases and workflow. In the final test we even set up dashboards based on each client’s saved searches to get the truest reaction. 
While we focused mostly on validating the concept, we of course came across interaction issues. For instance, we realized a vertical scrolling page can’t contain only smaller vertically scrolling elements! We decided going forward a horizontal scroll with columns of feeds would be simplest.
During testing, I refined the design by creating user flows that would help the user achieve their end goal (a fully kitted out dashboard) quickly and with ease.
The interface began to take clearer form, though I didn’t stray far from those first polished prototypes until recently. We were focused on validating our concept, and would invest more time developing the visual design once it had proven valuable.
For more rigorous usability testing, and to see how new users would handle the Dash, we turned to
On the whole the testers did very well, successfully navigating the feature and scenario, and making correct assumptions about the dashboard’s use. 
I provided recommendations to the team where I saw patterns of confusion or error, and we made adjustments for the beta release.
We invited all Spike users to join a beta program, where we would give them early access to features and would reach out to them for feedback.
The Dashboard beta was released to 100+ users, including those who had tested early prototypes.
After they had used the feature for two weeks, and then again after a month, we reached out to certain beta users for interviews.
I posted up their responses in order to find patterns and prioritize next steps for the Dashboard.
Soon after it’s release to all users, we were able to go live with new widgets that featured Facebook and Twitter trends. Previously, the content in Spike was focused around feeds of stories, trapped in a UI that catered exclusively for that. 
The Dashboards’ flexibility means we can experiment with new ways to deliver data to our users.
NewsWhip users now land in their custom Dashboard every time they open Spike in the morning. The news stories and social posts that they have previously created intricate search queries to find are displayed cleanly in a horizontal scroll. Several streams of content can be viewed at once to keep track of the many topics and current events of interest. Instead of being distracted by superfluous features and irrelevant stories, our users can get right to the work at hand.
While changes in overall user engagement have been statistically insignificant, we have seen encouraging user adoption of the feature and the reception has been positive. More than a third of our users have created a Dashboard, and 68% have populated it with 3 or more columns of content. We’ve also seen two interesting parallel trends: users that previously had very low engagement now are seeing an uptick, and while the middle ground is holding firm, some of our power users have shot up in their usage.
We’ve picked up on many ways we can improve the Dashboard from here, including adding often-needed features users miss from the full view (which is still available, one level deeper) like sharing and bookmarking, and giving users the option to see article images. We’re also excited to begin catering dashboards to more specific jobs stories, such as tracking earned and owned media, and competitors, for both PR Agencies and Publications.
Back to Top