STAGE : THINK

Opportunity

IDM (Custom) “Program builder” is a main feature that would allow the product to become client-facing and allow an end user to combine various data points, various functionalities, ML recommendations, API responses, and rules to create self-running applications targeting a particular browser or native app event such as “abandoned shopping cart”. 

Up until now, the product featured a limited but growing list of pre-configured “Packaged” Programs with limited modifications that would need to be edited by the dev team to be customized. 

Product Challenge

• Packaged programs are not very useful and provide limited customization options 

• Customization means a lot of manual effort by a dev team that takes time away from product development

• Very expensive and often impossible to work on more than one client at a time

• Hard to find users as this product creates a new flow not currently covered by anyone in the company 

• Is not easy to check competition unless one can subscribe to i.e. Salesforce product suite.

Approach

1. Kick-off workshop with all stakeholders and teams on overall priorities, scope, details, and a rough timeline.

2. Work with the Product on initial functional specifications and scenarios.

3. Interview multiple other teams to understand their software choices for similar UI solutions to see if we can use existing software or internally created solution.   

4. Start looking for users to test with.

5. Create conceptual wireframes to communicate rough hypotheses to stakeholders and the team. (Show early wires)

6. Create storyboards outlining details of interactions and Work with Product to fill the gaps like business case scenarios, Personas.  

7. Review with the Product managers and decide on the pros and cons. Decided to create our own code. (which meant more detailed UI specifications and rules for developers down the road)

Process Methods

• Problem Statement

• Assumptions: The big four

• Hypotheses Statements

• Persona creation

• User survey

• Users interviews

Problem Statement

As two products merge, we have to rethink the current Program creation within IDM to allow importing a lot more data points - in a flexible and non-linear fashion. Because of the expected technical complexity of the future program, the end state of the program should be an editable flow diagram providing the user with the ability to edit any part of the flow instantly.  

Assumptions

The main four are:

• Business outcomes: The program builder allows internal teams on behalf of the clients to create and manage a Program with multiple data inputs such as ML that is easily editable through an intuitive UI.

• Users: A Marketing Analyst and Data Scientist are our two main users.

• User outcomes:
  - As a Marketing Analyst I can create a complex end-to-end program with ML models only with support from a Data Scientist.
  - As a Data Scientist I’m able to create various models based on data provided by the marketing team I’m working with.

• Solutions: The program is a non-linear editable flow with built-in data sources that are edited by the user without leaving the UI.

Personas

Maria – Marketing analyst on the Epsilon Client team.
A business user who understands how data can be used, but likely doesn’t have strong technical or data skills and would need help with creating and importing ML models. Has created programs together with her teammates, client team, and support of engineering team for technical implementation.

Nataraj – Data Scientist on the Epsilon Client team.
Expert with data analytics, statistics, machine learning, data setup, etc. Works with Marketing users, and will build models for IQ(ML) functions or “Recommendations”.

Sub-Feature Hypotheses

STAGE : MAKE + CHECK

Learning Loop 0

Initially, after we considered a couple of patterns for this epic, I created the first pass at abstract flow to show how we can utilize a pattern from another internal product which I believed is a better fit. 

Goal: 
Get some initial feedback without an existing journey yet to gauge their reactions to the concept.

Progress:
Built few conceptual screens to demonstrate the pattern flow.

Feedback:
Stakeholders:
Provided tons of small feedback in regards details of various setup screens to be built.

Users:
Mixed feedback. Many overwhelmed by complexity of the Nodes, not completely understanding the intended end state of a program, how to start, what they need.

Learning Loops 1-2

Goals:

• Build the flow of a medium-complexity program, and get feedback from users and stakeholders. 

Progress: 

• Created a flow based on a simple journey we created with Product. Still assuming we will be utilizing the Camunda Platform for UI interactions as it is used in the other product and provides a solution to connect draggable objects to functionality.

• Product decided against Comunda and that meant designing builder interactions from scratch going forward.

Feedback:
Stakeholders: 

• Raised questions about limitations of current Nodes or Functions. Need to rethink the functionality of the Nodes. Provided tons of various feedback on the needs and wants.

Users: 

• All understand the conceptual pattern but 3/5 had trouble fully grasping what they’re building end state. 

• 2/5 users came back to certain functions to see if something indicates that they had actually finished setup certain “Nodes”.

Rethinking Nodes (to be renamed to: Functions )

The team has realized that we need to rethink certain functionality and revise the list of “nodes” (later to be renamed to “functions”) as we explored a couple of more complex journeys. 

Work supplied by one of the Product managers

Learning Loops 3 - 5

Goals: 

• Build new user flow using new “Nodes”.  

• Work on creating UI logic for Nodes builder interactions. 

• Explore how to add educational and/or support features to help users onboard easier. 

• Evolve Nodes setup screens. 

• Create some new builder logic interactions.    

Progress:

• Created Demo mode to support users

• Added educational tooltips

• Created a “bookends” approach to starting flow.

• Incorporated “status” indicators throughout the UI for error handling as well as feedback users about the completion of the setup and overall Program. 

• Incorporated more changes and updates

• Lastly we incorporated some of the UI from our design system.

Feedback:
Stakeholders: 

• Perceive it as too technical for our main persona - “How do we do more with less?”

• Need to simplify functions and language and automate more complex options, providing users a way to override it after the setup to simplify the initial steps. 

Users:

• 2/5 users did have trouble translating the sample journey to a Program. 

• 3/5 users were confused by Filter, Persist and Transform functionality

• We found the new components were too complex and we needed to make them more user-friendly and work on language to make them less technical. 

Example of detail work on the setup screen for “Filters”

Filter logic and options explorations

Learning Loop 6 - 8

Goals:

• Rework the Functions logic (previously “Nodes”) and figure out ways “to do more with less”.

• Simplify UI language used to be less technical

• Review overall usability to simplify UI where possible

• Update prototype to reflect new journey based on FallRiver Demo  

Progress:

• Simplefied top navigation

• Incorporated improved Setup screens based on a condensed toolkit

• Explored multiple setup screen options such as Filter In & Out (above)

• Iterated on a few existing setup screens like Branches

• Improved UI pattern of saving a program

• Explored adaptive designs with focus on larger desktop resolutions

Feedback:
Stakeholders:

• Let’s start on dev

Users: 

• Were able to find Demo and familiarize themselves with what they will be building

• Were able to save and start the program 

• Were able to understand the flow, and were able to complete a simple pre-conceived program based on provided problem within a prototype

Program builder MVP, most major screens and few selected states.

Project Outcomes

• 80% Implemented to staging 

• Implementation was put on temporary hold as the dev brought to light some arising issues we needed to work around.

• I was offered a position elsewhere and decided to leave the company at this point.