Summary

Kitewheel Hub is an IDE (Independent development environment) which was developed by engineers for marketing professionals to create and orchestrate customer Journey’s. Hub is a very technical tool that allows users to create simple or complex Graphs (programs) to complete a number of processes such as pixel tracking, channel recognition, API and database connections with the goal of moving users across Journey Steps and Journeys.

Templates can be ‘copies’ of projects, or journey maps and steps, graphs and graph nodes, and collections of all of the above. Their intent was to efficiently create out of the box solutions for clients where they could plug in play API connection details, databases, or edit cookie cutter maps and steps to get started right away. It is also used as a substitute for a copy and paste function and an import/export that does not exist. When importing templates, users had to know exactly what they were importing otherwise it was easy to import the wrong templates.

Managed graphs are graph nodes that perform repeatable functions, The best way to think of them are abstracted functions in Javascript or any other high level programming language.

My Role

• Redesigning Kteiwheel’s template and managed graph solutions user experience
• Visual Design
• Working with our engineering team to slim down the MVP and writing Jira stories

The Problem

Hub has a templates and managed graphs feature which is complex and poorly understood. Users had difficulty finding the source files, organizing templates and managed graphs was difficult, and they were buried in our admin panel. They lack confidence in creating templates because the process is very unintuitive. This process is called ‘Sharing’ within Kitewheel which is the wrong nomenclature for what is actually taking place. Once created, templates and managed graphs cannot be opened and edited. When users eventually find a list of them, it’s difficult to discern what they do.

When creating templates or managed graphs, it is not apparent to users that nodes within graphs are also included. The create template feature is done through a button called Sharing.

To update a managed graph, and push changes to instanes of that graph, users have to know exactly which project the original graph was created from, edit it, and then manually update each instance. When a managed graph is updated, users have to update each instance of that graph which could be in upwards of 100s of instances. Managed graphs also have many edge cases that make it difficult to test and deploy.

Kietwheel has a very complicated database and due to the nature of how each project is stored in our data model, there are innumerable edges cases. For instance, we had to design for renaming or overwriting journey steps, how will users be able to update managed graphs between different hubs and organizations, what happens when you transfer the same managed graph between hubs when it uses an instance from a managed graph by the same name, how will udpates affect versioned projects, etc.

• 
• 
• 

The Challenge

• Reduce confusion by fixing the information architecture to better fit modern paradigms and user mental models.
• Users would like a centralized location to create, import, export, update and transfer templates across projects and hubs.
• Making ‘importing’ templates easier to identify and use imported nodes
  • Weld or recipe creation
  • Data analytics
  • Troubleshooting & diagnostics
  • Weld production
  • Error handling
  • Personas
    • Engineers, technicians, managers/supervisors, operators
  • Unforeseen challenges
    • Client was not familiar with software development and required more upfront product management
    • Loss of a project manager
    • Understaffed project

The Strategy

• Design thinking methodology to redesign Sharing within Kitwheel
  • Research and investigate the problem
  • Create a design brief
  • Design & iterate
  • Test
  • Refine

The Solution

The final design solution was a Library model that was accessed through the Home page of Hub.The information architecture was redesigned so that users could easily view, edit and update templates and managed graphs. We allowed users to create templates and managed graphs from the graph itself which was then automatically stored in the library. We adopted a push/pull model to update managed graphs.

Research Synopsis

I did interviews with our professional services team, which is acts like a professional consultancy for our clients. They often do the technical work of implementing journey steps and journey maps. We have third party resellers that are extremely technical and understood the pain points of our sharing system. I also interviewed less technical folks that most created journey maps.

• Users
  • Configurers
    • Technical users that create the graphs that orchestrate journeys and gather analytics data
  • Services team
    • In house configurers
  • Technical third party resellers
  • Journey managers
    • Users designated in creating and refining journey steps and journeys
• Methodology
  • 1hr user interviews typically done as Q&A sessions
  • Working sessions with our in house team
• Insights
  • Sharing has an information architecture problem
  • Templates & managed graphs are poorly stored, difficult to find, and once they’ve been created they cannot be opened or edited
  • Templates are not always used for their original intent
    • Copy & paste work around
    • Import & export
  • Managed graphs are poorly understood
    • Difficult to edit because it’s hard to find them once they’ve been created. Original files are not marked as such. Power users tend to create separate projects to keep them in a centralized location.
    • They are difficult to update
    • Sharing is a poor paradigm for what is happening. Users’ mental model is closer to a library, Github and importing and exporting

Requirements

• 

• Requirements
  • Intuitive process for creating templates and managed graphs that makes users more confident in what they’re doing
    • Improve understanding in potential conflicts with schema, public variables, and duplicate node names
  • Unify templates and managed graph creation
  • Importing and exporting parts of projects, journeys, or graphs
    • Nodes
    • Journeys and journey steps
    • Profile Metadata
    • Metrics
    • Connections
    • Graphs with managed graphs
    • Schema
  • Knowing which nodes require updating after importing a template (Such as Connections)
  • Undo import
    • Rollback to previous version
  • Organize imported nodes, graphs, journeys and steps either with tags or a separate section
  • Efficient updating of templates and managed graphs
  • Efficient way to transfer templates and managed graphs between organizations and projects
  • Management area for templates and managed graphs
    • Transferring between organizations and hubs, parent to child, and hub to hub
  • Reduce debugging effort required of managed graphs
  • Managed graphs within managed graphs
  • Make version control easier to understand as it relates to manage graphs
  • Copy & paste

Sketching & Iteration

When I first start to generate ideas, I prefer to sketch then on paper or whiteboards. Creating paper prototypes and thinking through your ideas on paper is faster and more effective. It allows you to rapidly visualize the solution and get in front of people for feedback immediately.

• 
• 

Prototyping & Testing

• The entire prototype was created in Axure. It was a fully working system that was tested multiple user archetypes
  • The Library
  • Creating & editing within the library
  • Creating from a graph within a project
  • Importing
  • Push/Pull update Managed graphs
  • Library Settings

• 
• 

• Testing was done with the same users from the research phase
  • Users understood how to create, edit and import templates
    • They really liked the ability to create them within the context of a graph
    • With the addition of tagging templates, users could easily organize their original project and imported nodes.
    • Users easily located the Library section and immediately understood that this was a new location for all templates and managed Graphs
    • They were thrilled they could see the contents of a template such as nodes, graphs and sub graphs were included in a template when importing one
  • Technical users really liked the new push/pull paradigm we created for managed graphs. It allowed them to push all changes to 100s of instances with the click of a button. Instead of manually updating each instance
• Refinement
  • Refinements were minimal as users felt the new design was a superior improvement
  • We included a Library Settings to account for Database connections

Result

The final design solution was a Library model that was accessed through the Home view of Hub. This fixed the information architecture problem because Templates and Managed Graphs are shared throughout an organization.

Within the Library, users could create, open, edit and transfer Templates and Managed Graphs. Simultaneously users can created Templates and Managed Graphs within a project itself. This approach lends itself to natural behavior of creating ‘code’ that they would like to reuse in the future in the form of a Template or Managed Graph. When importing templates to a project, we gave users the ability to tag all nodes within the Template so that they could easily organize their projects.

The new design tested really well. Users immediately understood where to find templates, how to create them and how to edit them. The ability to create them within the library of the context of a graph was extremely helpful.

The redesign of managed graphs was even better received because they had many complexities and the original design was not well thought through.

• 
• 
• 
• 
• 

Engineering

We have a very limited number of engineering resources. The redesign was a massive undertaking that required a lot of planning and refinement in order to meet deadlines. I worked very closely with the engineering team to create MVPs and refine those MVPs over the course of 8 months to build a product that stayed true to its original design goal and could be delivered to meet business goals.