The Problem

When a team of developers at IBM created the original RedRock prototype at a hack-a-thon, it showed promise in technology capabilities, but wasn't focused on the needs of a specific user and didn't have a compelling or usable interface. It currently resembled a spreadsheet. We knew we could take it further.

The Goal

Take the promise of the technology and give it a viable user experience by applying user-centric design practices and design-thinking methodologies. The catch was that the design work had to be done in 10 days and the app had to run on Spark.

The Team

The team was truly multidisciplinary, made up of designers (Kellyn Carpenter, Raphael Bouchard, and myself), app developers, back end developers, and data scientists. We collaborated remotely and in a week-long working session held in IBM's Silicon Valley Laboratory.


Learn: When learning about RedRock, we began with understanding the existing technology. We learned about Spark and we evaluated the current user interface. We also learned about our users. Bringing these two bases of knowledge together allowed us to identify the areas of opportunity for this project.

Evaluate Existing Technology | Secondary User Research | Persona Creation | Journey Map


Evaluate Existing Technology

RedRock was initially designed as an iPad app, but the paradigm of the spreadsheet didn't really seem to fit the presentation. When every cell is editable, it's hard to use touch to navigate, something that's necessary on an iPad. There were a few other strange interactions, some obvious visual updates to be made, and one overall question: if the user is interested in the content of tweets, why are they looking at them in a spreadsheet that hides the majority of the text?

Clearly, the technology was here, but the experience was not.

Screen Shot 2015-06-03 at 3.51.05 PM.png

Secondary User Research

Because of our short timeframe, we weren't able to conduct the level of extensive generative user research that would normally help a project like this. However, working at IBM proved to be beneficial here. We found many other teams within our studio who had interviewed and researched our target user: a marketing analyst. We leveraged their work and learned as much as we could about this user. We also gathered data from external sources such as job descriptions and articles.


Marketing analysts are results-oriented users who enable others they work with. They live in a fast-paced environment where they sometimes struggle with lack of access to the correct data: "access denied, contact your system administrator." They receive requests from coworkers in the business, gather and shape data, and deliver reports. While data quality isn't their primary concern, they often spend time cleaning and shaping data to fit their needs.

Image is from secondary research and therefore not created by the team.


Persona Creation

Given our new knowledge of our user, we drafted a research-based persona.

Monica is a mid-level Marketing Analyst who focuses on social media analytics as a large part of her work enabling business insight and decisions within her department. With a BA in Marketing, she is not as technical as some of her colleagues, but is a fast learner with a solid base knowledge of standard analytics tools such as CRM systems, Excel, and social media platforms.


Journey Map

We considered the ways in which Monica might interact with RedRock and selected a specific user flow to map on a journey map. 

Monica is searching for tweets containing a specific hashtag. She starts out confident as she is presented with somewhat familiar search paradigm. However, she quickly becomes frustrated with the unintelligible and difficult user interface. She is excited by the machine learning capabilities that Spark provides, but when she finally creates a graph that she likes, there is no real way for her to save it, so her work is lost the second she returns to her spreadsheet.

Journey Map by Raphael Bouchard.


Create: Once we understood where we were coming from, we were able to begin ideating around possible design solutions. We started with sketches, then moved into digital wireframes once we had a solid direction. Visual UI decisions came not long after.

Sketches | Wireframes and Interactions | Visual UI Design



Since sketching is the quickest way to get a variety of ideas out on paper, we started there. we started with a few expansive, blue-sky ideas, but quickly realized that some of the facets of the experience wouldn't be accomplished in the given timeframe. We scoped back our thinking and created a second round of sketches.

Since we were working on a short timeline, much of this work was done in parallel. In this case, Raphael and Kellyn iterated on most of the sketches, with feedback from the team, while I drafted our persona.

Sketch by Raphael Bouchard.



When we were satisfied with the direction, we moved on to mid-fidelity digital wireframes. Given the rapid iteration, we shared this responsibility, creating wireframed user flows with short turnaround times, and presenting them to our development team in remote collaboration sessions.


Visual UI Design

As we moved forward through the wireframing process, we began to work in parallel on visual design elements. We took cues from some of the social media apps whose data we were leveraging. We leveraged the IBM Design Language so that the app would feel like it belonged to a family of other analytics products. It was an exercise on working within an established visual system.

The screens to the right are part of the first round of visual iteration. You can see the final design work implemented in code in the videos below.


Present: Since the project was a high-profile experiment (and a success), we were invited to present our work at a few conferences and other events.

Spark Summit | IBM Insight 2015 Conference


Spark Summit

The first event we presented at was the Spark Summit at the Spark Technology Center and Galvanize in San Francisco. Fresh from the launch of the Alpha version, we were met with positive feedback and general excitement.

This video shows Kellyn Carpenter presenting our design process for RedRock to a room of developers and data scientists at the Spark 2015 Summit.

See the blog post by Katharine Kearnan about RedRock here.


IBM Insight Conference

Our next stop was the IBM Insight Conference in Las Vegas. There, we showed off the demo to attendees in an interactive demo room (I was responsible for presenting it for an entire day), and it was also presented by executive leadership on a main stage.

Overall, we received positive feedback from the event. Since it was a twitter-based app, we took to Twitter to gauge what attendees were saying. Overwhelmingly, people were excited. IBM Sales representatives were curious to know how they could get more information about RedRock in order to sell it to their customers.

This video shows a demo of RedRock Alpha by Steve Beier, Program Director. Steve demoed this live to the same room of developers and data scientists at the Spark 2015 Summit.


Retrospective: A prototype project made for speed, conferences, and collaboration.

Ultimately, this project was a lesson in moving fast and scoping the project to fit our timelines and restrictions. Although we had grand visions for the capabilities of RedRock, we had to scope back to the minimum viable product for the Alpha version. By delivering a solid Alpha MVP capability, we buy ourselves the goodwill to move the offering forward into later releases and extended capabilities. Not long after our alpha release, updates were made, and RedRock moved into a Beta release stage.

Another lesson learned is that when you need to move fast, there is a happy medium for team size. Too few, and you can't get anything done. Too many, and you step on people's toes.