IBM graph is a database-as-a-service that allows users to visualize and see the connection between data. Design joined the development team in November 2015 to design a new user interface to teach and explore how to use the graph database. The product went to GA in July 2016. 

Graph Database technology is becoming paramount in the next century of applications, systems and organizations. The power to model the world's data structures in an organic, traversable fashion will change the way data & analytics are used to solve real world problems. IBM Graph unleashes the power of data connections by letting users store, query, and visualize data points, connections, and properties in a property graph. It is designed to answer questions about large or complex networks of inter-related data. Social networks, recommendation engines, cyber security, geospatial analysis, or any application that uses highly connected data are some examples of industry use cases.

Relational Databases such as PostGres & mySQL, arrange data in a tables (think Microsoft Excel) using rows and columns to organize an applications’ information. NoSQL Databases can use programming languages like JSON to model data in non-tabular means, giving way to enhanced analytic & data application capabilities.

Graph Databases put simply, are a platform with which database architects can arrange their data the way they would on a whiteboard, both visually and interconnected.

Prior to working on IBM Graph, the design team had little experience with databases or cloud based services, so the team spent about two months familiarizing with the structure of cloud offerings, how database services integrate into an application stack, and understanding the difference between graph and other database services. 

Through stakeholder and subject matter expert interviews, secondary research, testing and working with various database services, the design team established a grasp on the cloud data industry, competitors, and relevant technology. 

A data flow chart, seen below, maps out the inter-connected and overlapping journey of data from infrastructure to refinement. At an enterprise scale, its easy for design to be only considered at the end of the process, away from back end development and infrastructure. The graph design team prioritized an understanding of the ecosystem in order to advocate for design thinking strategies throughout the process.

The design team conducted  interviews with internal front-end developers and developers outside of IBM to determine the target user, what kind of apps they were building, what tools they already used. A large challenge was finding app dev’s that had already used a graphDB and had some opinions on how they worked, what visualization and analytic tools they wanted associated, and what they would like to see from a next generation of graph services. Graph is a fairly new technology to be widely available, and is usually used as an analytics layer on top of a production grade SQL system, instead of a widely adopted core piece of infrastructure.

After aggregating a research base of metrics & insights on target users, we created personas for entry level graph users and experienced graph users. Insights were derived and helped inform the initial concept for the UI as well as some service decisions. The design team created journey maps to describe each persona's product experience from discovery to support and advocacy.

From the personas, the design team created user flows to determine exactly what the users would be doing from a service perspective. After they were presented to the development team, it became clear that the service needed some heavy API work before the user interface could be created. These flows helped align the team and created a list of priorities for improving the service for both the API and the user interface. 

Creating a user interface from scratch required relentless communication, iteration, patience, and agility. The six-person design team created a minimal viable experience that launched in July 2016 that included four base tutorials that explain the service, a sample dataset and sample queries for users to get started immediately, and a sandbox query section to test out and learn the new query language for IBM Graph. 

The team began by determining the site architecture for release in July and how it would grow over time. 

The design team then began creating wireframes from the journey map and site architecture. The team would map out the journey on a whiteboard and ask questions based upon user decisions and actions. After figuring out the flow and how pages would relate, the team drew out ideas of how to represent the actions. Below are two examples of the process before jumping into the computer. 

After iterating on the whiteboard, the team created multiple versions of how the users would interact with the IBM Graph user interface. From January 2016 to March 2016, the team created about 3 major concept iterations that included all the corresponding functionality. The evolution of the wireframe changed based on technical requirements (what could be built) and user feedback. The main function was to create a streaming model that allowed for a user to learn, iterate, and build.

It was incredibly rewarding to ship an end-to-end experience in a matter of months, especially working within the confines of corporate structure. The final product was an entire team effort, from design and development to offering management, developer advocacy, and marketing team. By working with a start-up mentality, our entire team was able to shift and adapt to curveballs to get the product out the door. 

For design, the team created a learning system that was accentuated through a card streaming layout. While the main goal was to get users up and running in a graph database as quickly as possible, an unforeseen consequence of the design was that it starting becoming a sandbox for users to test out their queries to make sure they were correct before they put it in production. This shift of how users starting using the UI productively instead of just for learning was interesting to witness.  

The design team is working with development to continually iterate and update the user interface experience through user feedback. The design team met with the development team and project management for a week-long design thinking workshop to determine next steps and how to prioritize work.

After launch, the researcher on the design team was able to conduct multiple user testing sessions to determine how users were using the product. Since it was such a short timeline from Beta to launch, many assumptions were made in the designs. After user testing, the team was able to create a prioritized backlog based off what was and wasn't working in the user interface. The feedback was incredibly helpful but also humbling to see what might have made sense to us (since we knew the product) was completely lost upon the user.  

Being part of the graph team was probably the best learning experience for designing software or digital experiences. The tight deadline forced design, development, and offering management to stop working in silos and start communicating with each other. While the road started off pretty rocky, today the team works in complete sync with each other. A panel of four (design, development, and marketing), including myself, presented at World of Watson 2016 on how our team works together. The four key principles are:

1.  Build trust - learn the domain

The design team took a couple months to ramp up on our domain, and even today we are constantly learning. This helped us more intelligently speak to our development team, and learn the constraints of the product (instead of designing in the blind). We started asking the development team questions about the product, which was a bit awkward and intimidating at the beginning. Once they realized that we were trying, they started to explain things in greater detail to make sure that we understood what things meant, and how they worked. Having a better handle on our product helped the design team design the experience for those working with the product. 

2. Over communicate – with everyone

The team started communicating everyday through slack. This helped alignment, but more so, created relationships across the multiple disciplines – development, design, offering management, marketing, and content. We also started conducting our daily scrum over Zoom, which allowed us to see each other instead of just hearing a voice. That also helped create stronger relationships since we could now put a face to a voice. A big effort design, marketing, and content made was to learn Git. Now we all constantly communicate and track conversations about specific issues for the service. Finally, design showed the rest of the team how to use Murally for sharing ideas and prioritization of next steps remotely. 

3. Ask forgiveness, not permission

The design team started taking the initiative to do get what we needed done, even though we ruffled some feathers along the way. We strategized all the ways to reach our goal, and then try to accomplish all of them. For example, the design team created the sample data, wrote tutorials, designed a marketing page, etc. While not everything was implemented, it solidified our presence at “the table.” Our opinion is not only valued, but asked for, because we constantly fought for the user and creating a holistic experience. 

4. Inclusive design

This was probably the most humbling lesson the design team had to learn: design isn't just the role of the designer. While we were the design team, we didn't have all the answers. By allowing everyone on the team to give feedback about the experience, the rest of the team gave their unique perspectives that provided valuable feedback on the features and experience the design team was creating. Our final UI design was a truly collaborative effort. Even the product architect and the distinguished engineer gave feedback on the user experience (which is huge and amazing).