ibm graph

building a graph database

OVERVIEW:
IBM graph is a database-as-a-service that allows users to visualize and see the connection between data. Our design team 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. 
*In December 2017, IBM Graph joined the IBM Compose suite of products and renamed to Janus Graph.
DESIGN TEAM:
Bhavika Shah (Design Lead), Chris Befeld (Visual), Dillon Eversman (UX/Front End Developer), Ben Resnick (Front End Developer), Meghan Corbett (Researcher), Tom Workman (Front End Developer)
DEFINING A GRAPH DATABASE:
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 VS. GRAPH:
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 where database architects can arrange their data the way they would on a whiteboard, both visually and through interconnections.
DOMAIN RESEARCH & MODELING: 
Prior to working on IBM Graph, our 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, we 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. Our design team prioritized an understanding of the ecosystem in order to advocate for design thinking strategies throughout the process.
USER RESEARCH & PERSONA DEVELOPMENT:
Our 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. We created journey maps to describe each persona's product experience from discovery to support and advocacy.
USER FLOWS:
From the personas, our 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. 
DESIGN PROCESS:
Creating a user interface from scratch required relentless communication, iteration, patience, and agility. Our 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. 
Our team began by determining the site architecture for release in July and how it would grow over time. 
WIREFRAMING & PROTOTYPING:
Our design team then began creating wireframes from the journey map and site architecture. We 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, we drew out ideas of how to represent the actions. Below are two examples of the process before jumping into the computer. 
WIREFRAME EVOLUTION:
After iterating on the whiteboard, our team created multiple versions of how the users would interact with the IBM Graph user interface. From January 2016 to March 2016, we 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.
FINAL DESIGN:
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, our 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.  
SINCE LAUNCH:
Our design team is working with development to continually iterate and update the user interface experience through user feedback. We met with the development team and project management for a week-long design thinking workshop in Boston to determine next steps and how to prioritize work.
USER TESTING:
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, we were 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.  
REFLECTION:
Being part of the graph team was one of 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 IBM World of Watson Conference 2016 on how our team works together. The four key principles are:

1.  Build trust - learn the domain
Our 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
Our 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
Our 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 shows how far we have come as a team advocating for the user.
Back to Top