top of page

Fuego Tools

Role: DIY User Researcher, Interaction Designer
Size: Scrum team of 1 Dev Manager, 1 Scrum Master, 11 Developers, 1 Interaction Designer, 1 Content Designer
Duration: 1 year, 2 months and on-going
Skills: User Research | Interaction Design | Prototyping | Strategy
Methods: Contextual Inquiry | Usability Testing | Journey Mapping | Retrospectives

Fuego Tools are a set of Intuit's proprietary internal tools used by the Migration Teams to replatform all the experience code and tax calculations from the legacy environment to the new Fuego tech stack. Fuego is a proprietary language and architecture developed by Intuit. These tools were built by software engineers initially for software engineers since they were the only ones with in-depth knowledge of Fuego and the inner workings of the legacy code.

My role as a designer was to simplify these tools to enable designers, tax analysts, business analysts, and front-end engineers to focus on their craft rather than figuring out how to use the tool. Although there are several internal customers, I will focus on the non-technical customers of content designers whose job was to update migrated screen content to our latest design patterns.

Note: Because these tools have not been publicly released, I have omitted and obfuscated confidential information.

Context


TurboTax comprises 50,000+ screens to cover unique and complex taxpayer use cases. In order for the product to be nimble, data-driven, and maintainable, its code base needs to be migrated to a modern and flexible architecture.

Customer Problem

As a content designer trying to migrate a TurboTax topic to Fuego, I cannot easily update content and assets without the constant dependency on a Fuego developer. This leaves me feeling unproductive and unconfident the work I'm doing is accurate.

Goal

Improve the usability of Bonfire and Flint tools to expedite the workflow for a non-technical customer without compromising functionality for a power user

Gaining Customer Empathy & Insights

To best work in the the domain of tools, I needed to first grasp an understanding of the general workflow expected of a migration team.  At a high level, the topic migration workflow is as follows:

TOPIC ANALYSIS

PM uses analytics and customer verbatims from the Care team to identify opportunities in the tax topic 

create "from" spec

Business analyst creates a flow artifact of all the topic screens from the legacy environment and annotates flow logic & field bindings.

create "to" spec

Designers update the flow to reflect the latest Fuego assets, patterns, and improve content without creating significant dev scope. Changes need to be vetted by tax analysts to ensure compliance.

dev scrub pt. 1

Front-end developer migrates the topic using Bonfire and cleans up mis-translated code. Ensures behavior parity with old topic.

design scrub

Designer uses Bonfire/Flint to edit pages to match the spec they created. Publishes changes to codebase via Bonfire.

dev scrub pt. 2

Using Flint JSON editor, developer connects Fuego bindings to the proper fields for any new design added and completes navigation logic.

A

QA/QE VERIFICATION

QE writes tests, creates a QA build, and verifies use cases per spec. Run automation and service tests.

DEPLOY

Developer creates a request to have topic merged into master release.

Highlighted in the above work flow is the key touchpoint that is the root cause of much angst for designers. To best understand the pain points of a content designer using Bonfire and Flint (our topic and page editing tools), I conducted contextual inquiries with designers scrubbing a topic. I then synthesized my observations and their feedback into a journey map that I could share with the Tools dev team to create empathy and understanding of the tools' opportunities.

Key insights:

  • Documenting the "TO" state in another tool (like Omnigraffle) seemed like double work when the new content would be entered in Flint anyway. Could these steps be combined?

  • When given a viewer that displays a coded screen, designers expect to be able to drag and drop and edit assets within the viewer, much like you would in Powerpoint. 

  • The dependency on developers is primarily to provide the proper binding paths to be able to surface specific use cases (e.g., content for someone with a "Married Filing Jointly" status would appear different from that for "Single")

"I expect a tool that is used to edit content and move around assets to work like Word or Powerpoint. That's what we're used to, but this is so much more complicated because I have to understand how a Fuego page is structured and where to go to actually select the text asset to edit it. I'm not even sure where to focus my attention."

Helping One User Without Harming Another

This particular aspect of the project required a delicate balance of enabling a WYSIWYG (What You See is What You Get) interface, yet still allowing access to front-end developers who relied on the JSON code to edit non-visual aspects unsupported by the UI. Much of the design revamp involved understanding what key fields were used most frequently by designers and white-listing these, while hiding all other "advanced fields" under a "Show more fields" toggle.

 

In a similar vein, the workspace for Flint, by default, displayed several panels at once that were unclear as to which panel to focus your attention in. These panels catered to developers, who frequently toggled between the rendered screen, JSON editor, and page structure view. Because the rendered screen was the common panel for both non-technical and technical customers, all other panels were made available through progressive disclosure.

Finally, creating new assets had a high dependency on developers as it required knowledge of how assets related to one another and their respective containers. A significant experience uplift was the introduction of inline editing as well as an inline toolbar when selecting various assets within the rendered screen. The tool required much refactoring to enable contextual awareness of the types of assets that could be added to the selected container, therefore removing this burden from the customer. Naturally, adding assets inline led to the question of whether you could add entire pages with pre-set assets. This became part of the next iteration of the tool where a new template wizard was introduced to support accurate usage of patterns from our design system to ultimately create consistent end-to-end product experiences.

The Impact

Prior to the changes made within Bonfire and Flint, it would take between 4-5 hours of "pair programming" with a developer to make content edits. Now, a content designer is able to scrub a topic in Flint within an hour. Now that's unlocking exponential efficiency!

bottom of page