← Visual Flow DesignerDesign process & details

Visual Flow Designer Process Details

Low/No code solution for platform users to authorize chat bots

Overview

There are many daunting process details and iterations in this project. If you're ready, feel free to dive into the sea of technical details, user feedback, IAs, and my iterations.

My Contributions

I have been the main UX designer for Visual Flow Designer throughout the process with a lot of support from my manager, engineers, and PMs. Oracle's design system supports me with the VxD of nodes and links. Contribution highlights:

Ideation
Interaction design
Information Architecture
UX Research

Timeline

2019.09 - Present

TOOLS

Sketch, Figma

Design Challenge

How might we help ODA customers design conversations in a modular, simple, intuitive way?

Our goal for this project is to build a new, scalable authoring system that can replace YAML. Meanwhile, I understand tech debts of YAML will bring some impact on the migration experience of existing customers, backend support, and so on. I listed the high level design challenges as below:

YAML is hard to manage as it grows longer and longer.
Current users cannot quickly track conversation branches in YAML editing.
YAML's high learning curve prevents users with less coding knowledge from authoring chatbots.
We need to help current customers migrate existing YAML authored skills to Visual Flow Designer.
We need to leverage the current backend ability (that originally supports YAML) and design a visual authoring UX around that.

Ideation & Early Research

Task Flow

Before delving into the technical constraints, I brainstormed with PMs and my manager to imagine the ideal experience for our users. This stage is dedicated to exploring off-roadmap ideas. I sketched the following to address 3 "Next Gen" scenarios:

Auto Adding Skills
Manually Adding Tasks
Export

While the "Next Gen" scenarios are more blue sky, we came up with 2 concepts: Task and subtask, aiming to create modular conversations that users can reuse throughout the Skill.

Low-fi Design

At the beginning, the PM suggested redesign Conversation Designer with branches, an edit model that simulates messaging. I quickly sketched the lofi as below:

Simulate Messaging

This interaction model better presents liner flows, yet cannot visualize conversation branches that may grow quickly. With this assumption, I scheduled some user sessions with a few conversation designers within Oracle, and got the following insights:

A functional skill has many nested branches depending on variables, parameters, and free marker expressions.

The linearized messaging model may work better as a demo tool or 0-1 tool for users to kick off conversation design, yet it cannot handle more complexity as users progress.

The users currently draw diagrams on a third party tools and then translate them in YAML in ODA later.

Based on these insights, I proposed using diagram as the main edit model, and sketched the following addressing the task flows:

Auto and Manually Adding Skills

Diagram Node Inspector

To inspect each conversation unit of the diagram, we narrowed down to 2 ways: Zoom vs Side Panel.

I suggest not committing to either yet since both have their values:

The Zoom model's guides the user to the properties of conversation unit more naturally (with a zoom-in animation ), yet prevents the user seeing more context (more nodes) around the selected node.
The Side Panel model doesn't create much visual transition, yet it shows more context without moving elements around and is easier to scale.

Midfi Design and Exploration

Node UI Model

At this point, lowfi design can no longer work for more detailed interactions. The design system's is still working on the visual diagraming elements. I communicated with the design system designers for node, and together we confirmed a basic interaction model that I could use as following (my sketch below):

I also proposed a 3-level navigation to the design system designer:

Diagram Interaction Model

My manager and I then brainstormed with our PMs in a meeting room: how might we create a diagram that helps the end users view payslip (a use case that our user provided)?

Based on the input above, I created some midfi design addressing multiple interactions. The following are selected from a wide range of interactions I explored.

Add new blocks and customize blocks

Drag reusable subtask and add nodes

At this point, we made 2 main design decisions:

Use Side Panel as the property inspector as it scales better with versatile needs (after we talked to the design system team).
Allow the user to trigger another task in one task. We debated whether we need to differentiate subtask and task at all, since flattening the list with only one hierarchy is more intuitive.

Stakeholders Review

In the mid 2020, we finally were able to schedule some user interviews with some customers: Intrasee, GE and Razor. I showed the above and got the following feedback:

The visual mode lowers the threshold of authoring chatbots for users. They could see business analysts using it.

Currently, some of them have one giant Skill and other optional small Skills for things like greetings. Some of them have 3 to 6 rather balanced Skills.

They wonder how they could transition to this with their YAML Skills. Can they use both YAML and visual diagraming?

We decided to try what our users suggested, a 1-1 YAML and diagraming system. We were able to get some resources from the engineering team to review and improve our design from implementation perspectives. With the design system team locked down to the visual design of node and links, we were able to ask a developer to build a prototyping tool for us. I used this tool to literally translate an existing giant Skill just to see how huge the diagram is:

The engineering team helped us realize 4 things:

Dialog view and Diagram view cannot coexist. The complex branches within the diagram cannot be translated to a linear flow as in Dialog mode.

The Dialog view is more appropriate for a mockup tool, and can be used to kick off more complexed Skill.

The rendering of a diagram is expensive if there are more than 50 states.

All of the system built-in components and events need to be supported.

MVP Scoping & IA

Migration User Journey

In order to control each diagram's size, PM asked the backend engineers to exemplify how to modularize one big skill into multiple skills, and then modularize a skill into multiple flows in YAML. Based on PM's documentation of our customers, I created a migration user journey map:

Flow Designer IA

In April - June 2021, PMs, engineering team, and designers had regular meetings to scope and plan. As a designer, I visualized what our agreed on each time and facilitated the decision making process. Below is what we finally agreed on:

Component Picker IA

This is a legacy feature that helps users add new states in YAML. Currently, the built-in components are categorized based on scenarios. While I agree that these components should be categorized, I sketched the following IA to remind the team the following:

The velvet-labeled levels add extra layer/complexity for the user to select the desired components.

The velvet-labeled levels are more helpful in the YAML context than the diagram context. For example, Under "Use channel-specific features," they all use the same component System.CommonResponse.

While in the YAML world some of these scenarios provide template YAML code, in the diagraming world we could use UI controls to achieve the same goals.

This component picker is a mix of "pick by template" and "pick by component type." We should these two adding experience.

The stakeholders agreed, yet consider the component pickers still valid to some customers and might be worth exploring after MVP. I proposed doing some user research and phase out the changes.

View current ia

View Phase 1 ia

View Phase 2 ia

Node/State Types

With the node's visual theme finalized, I delved into ODA's existing backend support (built-in components) and categorized them based on design system's theming. The MVP goal is to support all of them so that the current customers won't have hiccups. We also decided to call each node a "State" within ODA's context.

View COMPONENT LIST

Additionally, I proposed building more state types: Diagram Components and Virtual Components.
Diagram components are mainly used to manage diagram and transitioning. Virtual components are simplified versions of existing components.

View vIRTUAL cOMPONENTS list

This is an initial attempt to address the potential pain points of some of our current built-components:

Currently, many of our users use System.CommonResponse for almost every message. This component has many property fields that power users can utilize for complexed needs, yet it might be too confusing for common users that haven't read our documentations carefully.

A lot of our built-in-components were created in the YAML context, but might no longer meet the user goals in the diagram context. We need to revisit them with more use cases.

State Information Architecture

I created the IA of the state property panel as follows:

Originally, I wanted to combine the 3 sections into one page without tabs in order to reduce user clicks. Engineers pushed back:

A lot of our built-in-components have many fields to fill and it will be a long scroll to reach the end. We are also not sure how many transitions the users are going to create now. We should keep them separated for now as it scales better.

I acknowledged the intention to scale across all components, yet insists having one section for virtual components.

Hi-fi Design Process

UI Template

Since we only have 3 engineers and 1 engineer lead to build 30+ built-in components' properties, for MVP we had no choice but to pick the most economic way of building it: using formulaic UI templates. If possible, I would propose more focus on the ease of use in the next release.
This is how it works: the engineers give me a JSON file listing all of the properties and their types in each built-in component, and I summarize repeatable UI patterns that can be reused in these components.
For example, in component "System-Invokeflow," it has a property "inputParameter," and its UI type is "array."

Then in my design file, I specify how it should be rendered in UI. This means if any other component has a property type "array," then it should adopt the same UI pattern.

I created 19 UI templates for all components. Engineers build them once, and then reuse them across all 30+ components' properties panel. Here's an example.

View full ui template

Users Feedback

We showed a deck with hifi design to some internal users and got the following feedback:

View Complete DECK

1. Extra Click

After creating a new state, the user needs an extra click on "Component" to edit the actual content for non-virtual components.

We should make the "Component" selected by default when a state is created.

2. Separated

The variable configuration is separated from the flow design experience. If a user wants to select a variable for a state, and the desired variable doesn't exist yet, the user needs leave the page and go to "Configuration."

We should allow the user to create on-demand variables inside the flow experience.

3. Map Intent

Intent Mapping is hidden in "Main Flow - Events - Intent Events." Mapping an intent to a flow is a very common behavior when a user creates a flow.

We should allow the user to select an intent when they create a flow.

4. Hidden

1. The simplified virtual components are too hidden within the component pickers. The user needs to click the navigation back and forth to find the desired component.
2. The context of where the user is adding the state is also hidden behind the component picker dialog.
‍
For MVP, at least we should surface the 3 virtual components to the top level.

5. Primary and Secondary Text

This is an unanimous feedback in the first round of interview so I changed it on the deck immediately. Originally, we have the state type as primary, and state name as secondary following design system's guidance. However, the same type of state might occur multiple times in a row in the context of ODA's diagraming. Node type as the primary text doesn't inform the user which state it is in a diagram. Therefore, I switched them as following:

Reflections

The whole process is like a marathon with many ups and downs. Some lessons I learned:

Be strategic. I documented and shared a variety of design solutions with stakeholders, helping them making decisions, yet I'm not part of the planning process when some decisions are made by PMs.
Involve engineers early. We spent too much time on the blue-sky design instead of investigating what the legacy backend supports, dreaming that they would let go some of the legacies and build new ones. We should involve them early and see what's feasible within the timeline, and create a long-term and short term goals to kick-off design.
We definitely need more user research data. Currently, most of the users sessions are more like demo/walkthrough instead of structured usability testing. I've only talked to 3 out of 700+ customers. We need to recruit users based on user types, and use user data to inform design decisions. Fortunately, PMs heard me and will release a LA (Limited Availability) release before MVP. I made a user research proposal:

View RESEARCH PROPOSAL