Enrichment Editor Renovation
A process deep-dive into redesigning a difficult-to-use product
Enrichment Editor lets marketing, communications, or fulfillment organizations handle curveballs in their mail channel workflow. This tool enables them to add and edit text, barcodes, and data as well as cleanse addresses in mail campaigns with hundreds of thousands of pieces.
Our product team needed a way to demonstrate the product's function and value. I joined the team to develop a series of simple tutorial walking through a few key use cases. During this, I encountered a number of rough usability spots in the app. I urged the team to consider addressing them, and I put together a number of recommendations you’ll see below. The process took about 4 weeks, and the many of the suggested change are underway.
Tedious task flows reveal mixed conceptual models
Many of Enrichment Editor's usability issues stemmed from an overly faithful interpretation of the software/technical model of its predecessor, a command-line-only PDF transformation engine.
The tool was built for a target persona of Mail Fulfillment Coordinator. From the perspective of this user, functions with overly technical names like "Define Field" and "Add Operation" would not be intuitive. To make the app more familiar, we needed to extend and clarify the canvas/document model, as it is used in common word processor and page layout apps.
I was calling it a renovation because we had a small engineering team that building on top of a finicky PDF engine. "Redesign" evoked an impossible overhaul. It was important to identify the highest value changes and move as little else as possible.
Map regions and identify key concepts
Recording the tutorials turned out to be a great technique for gaining an in depth understanding of the current app. As I mapped the interface into regions, key concepts like canvas, document, and projects emerged. Making theses levels of the app explicit guides how to group them sensibly when it was time to move things around.
Take a functional inventory and group into larger capabilities
Redesigning an app is difficult because it can be hard to see past what is there. Taking a "functional inventory" abstracts the GUI into the things it can do. This is a fast and loose exercise where I list, in the terminology of the domain, all the things our user can do in the app that will complete their ‘job-to-be-done’.
I learned this technique, (and so much else) from Ryan Signer of Basecamp. Go watch his talk on it right now.
These functions are more granular than a use case. These usually are the steps within a use case. By detaching functions from affordances, we can reconsider their implementation. This technique also naturally scopes the app as it should be able to do all these things after the redesign.
Once done, I have a comprehensive list of functions that I then group into larger capabilities. These are akin to use cases. To do this, you’re looking for the "joints" in the app: groups of things that work together without affecting the other groups. Orthogonality is the fancy word for it. I then focus back on our core user and ask: which capability did this user buy? The answer shows me where to start.
Moving from task flows to use cases aligns with the job-to-be done as a user moves through time.
Redesigning around key task flows
I started in on the Add Element & Edit Element capabilities by verbally sketching the tutorial use cases. Describing the process with only words helps me evaluate flows without getting caught up the interface elements. Getting clear flows revealed problem areas in the app. There were a number of isolated usability issues were low-hanging UX fruit.
Recommendation: Clarify view mode controls
Reserve icons for actions/toolbar. Lessen ambiguity with labels. Display sub-view controls (show/hide selections & check syntax) only when in that view mode, (Original and Code respectively)
Recommendation: Unpack Toolbar
The toolbar was a catchall for an assortment of functions. Most had nothing to do with the canvas. I removed tools that did not act directly on the canvas, categorizing them into the key capabilities defined previously.
Recommendation: Move Documents, Resources and CASS settings to the left column
Recommendation: Consolidate & refine canvas tools
Working up to Layout changes
I hadn’t yet attempted any major changes to the app layout, although I sensed it was going to be necessary. I like picking off confined, simpler problems to start and building up to better inform the whole network of the interaction model, rather than the overwhelming top-down approach.
I needed to find places for these displaced toolbar functions. This is when having a well-defined conceptual hierarchy and list of major capabilities helps when finding a home on the screen. I played with new regions, introducing a 3rd column to accommodate.
The 3-column layout made space for an Edits section where users can easily see and work on the modifications they are making to the PDF. Most key regions of the app were retained with Edits and Output sections added.
The recommendations were well-received by the Product Owner and Engineering team. This first round attempted to resolve some acute usability issues at a high level. There are still areas of the app, like tool dialogs, and page management, that will need to be reimagined.