DATA ENGINE PLATFORM

Central management system for Tax Administrators to manage common entities used across multiple applications.

Company
THOMSON REUTERS

Timeline
2017 - 2018

My Role
LEAD & DESIGN

Target Audience
TAX ADMINISTRATORS

Tools
AXURE

Deliverables
RELATIONSHIP DIAGRAM
PROBLEM ANALOGY
PERSONA
EMPATHY MAPPING
USER JOURNEY
PROTOTYPE
USER TESTING

Background

This is the third attempt to come up with a central management system for over 24 applications acquired by Thomson Reuters throughout the years. The first two attempts failed at data consolidation and did not even get to the UI design part.

 

Challenge

  1. Entity names and attached information are different across multiple applications.

  2. It is difficult, time consuming, and error prone for admins to maintain and map accounts across applications periodically.

  3. Have to communicate with over 20 Product Owners with various knowledge of each product, using different naming conventions.

Complexity Example: A single entity in General Ledger Manager (orange) when combined with another entities (yellow) can be known as other entities in Global Tax Provision (purple, green, blue), which belong to other hierarchy structures.

Complexity Example: A single entity in General Ledger Manager (orange) when combined with another entities (yellow) can be known as other entities in Global Tax Provision (purple, green, blue), which belong to other hierarchy structures.

 

Discovery

DEP_UXprocess.png

We went through our standard UX Processes such as Journey Mapping and sketching with stakeholders, and we came up with many iterations and versions of designs, yet we could not move forward with a single design approach.

The Underlining Problem is that everyone in the meeting only focuses on their own piece as each stakeholder is deeply knowledgeable within their own product and not familiar with other products. People in the meeting constantly had to re-clarify their words as everybody else had a different understanding of the project, terminology, and scenarios.

We quickly realized we needed to come up with a common language to bring everyone back on the same page.

We came up with the Social Network Profile Management Analogy.

DEP_socialnetwork.png

The Analogy Approach

  1. Imagine you’re trying to organize all your social network profiles (Entities). Each social network system (each Product) has their own ‘required’ basic information to start the profile, so when you first create a profile, you can select which social network service you want, then the basic info such as your name and email address you entered will apply to each social network you selected.
    Because some products require more basic information to an entity than others before the entity can be used.

  2. You can then customize your profile picture or display name to a certain social network profile, but the system knows these different profiles are still you. For example, you can use a different handle on Twitter while Facebook will display your real name.
    Because entity info from different products could display differently.

  3. Next, imagine you upload photos to a single repository, and then decide which network will see which photos because you don’t necessarily want your LinkedIn profile to display your family pictures.
    Because a single repository of attachments such as Workpapers and Trial Balances is needed, and then the user can decide how this attached information can be used in different products.

  4. Finally, you decide to change your email address at the highest level after you’ve made changes to Instagram, so the system needs to help you decide if you want to update your Instagram account or keep that different from the rest.
    Because entities evolve in time, so even the entity names could change. What happens when the entity name is changed, should it apply to all associated products, or allowing each product to keep the old name?

Results

  • We have a common understanding of the project

  • We are able to explore new scenarios using common language

  • We are able to relate new scenarios to individual product needs

  • We have better understanding to the interactions produced in the design

  • We can better explain our project to other people

 

Design & Prototype

As the team tried to solve the scenarios around Social Network Profile management, we solved many design challenges for Entity Management without getting into technical terminology.

Common Entities Administration

Edit Entity

Entity History

 

User Testing

I worked closely with a researcher throughout 2017-2018 and we tested five different areas of the application with 5-6 users for each test. We reviewed our goal, decided on the test approach, and wrote the script together. The researcher then recruited the actual users based on a list of contacts provided by the product owner, while I refined the prototype for testing.

Clickable Prototypes:
Add Entities Prototype | Edit Jurisdiction Prototype