we need a number
management of critical data point

Process: User Interviews, Task Analysis, Lo-Fi Paper Prototypes, High Fidelity Prototypes, Usability Tests, Post Launch Feedback

Solution: New modal, introduction of new design functionality which supported future initiatives (to fanfare from Technology and Product)

Result: Increased automation / efficiency (5%), reduction in overall process time, users enjoyed the process

Let’s start over.

Client: Chase (Internal Servicing Apps team)

Design Space: Actively used web app for onboarding clients with an existing information architecture and design system.

Detailed Solution: Two custom modals that call multiple external services.  The first modal allows entry and modification of various data types, inline error handling, and real time status updates.  The second modal is completely separate from the first and handles attachment of data values to distinct entities and allows greater customization of those entities.

 

To find out how I got here, keep reading.

Est. Reading Time: 12 Minutes

Tell me about the problem.

Suzy sat a couple cubicles down from me and was responsible for setting up clients.  Part of this process required the use and management of a special type of number.  This was done through email, confluence, and luck.  It was well known that in the middle of your work, someone would accidentally use the number you had chosen.  This could derail Suzy’s work and could cause her to miss deadlines which would get her in trouble with her boss.  Of equal importance is the possible delay in the customer’s setup which costs the company money.

Now on top of all those issues and concerns, I had to contend with multiple systems interacting with ours, a smorgasbord of error scenarios, and most worrying a fundamental hole in the current interaction model to support these efforts.

 

Research

Let’s be honest, I didn’t understand the number when first explained to me.  So I went and spoke to Suzy and the other users about this process.  They told me about Nancy who managed a part of the number process, they shared their frustrations with the current process, and how it was a headache.  I would talk with them frequently as I worked through this. Their jobs are tough; I want to make them easier.

I also spoke with the Developers. A lot. We had a lot of systems we had to connect to to manage the number and they were able to help refine the best way (technological and design) to manage all the systems we needed to connect to.  They shot down a lot of my ideas.

 

Solution

While I was having ideas rejected, I was also refining the direction we would go.  One of my first successes came from convincing the Product team that while a new or existing number has completely different behind the scenes processes, none of this meant the user needed to be aware of it.  For them a number is a number.

Trying to lay out 2 different actions for both New and Existing.
Additional attempts to allow 2 different actions. Not Clean.
And more attempts to do 2 actions

This is where it really came together; see we had a pattern we could use to accommodate the number and what kind of number it was.  We had just launched something similar to this.  But there was a problem; the fields were flipped on it like A then B on the original one and B then A on the proposed.  And I was hesitant to put something that didn’t align into production. I explained my concerns to Product and they agreed we could do a fix the original and have both be aligned (B then A).

The requirements for each version of the number. Plus a version of the final solution at the bottom.

It looks like my solution works.  I’ve presented it to Product and Dev but now comes the hard part, how do we address Errors?

 

Errors

When dealing with systems that aren’t your own whether vendors or different Lines of Business, errors are a constant thing to be compensated for.  These are some guidelines we tend to address.

  1. Don’t let the user get into a situation where the project integrity is compromised.
  2. To what lengths do you allow the user to fix an error?

As we walked through possible error scenarios, it became clear that some of them would require a lot of action by the user to recover from.  Generally, if something failed with a vendor, the process was long and arduous.  While anything can be designed, incorporating a user path to recover from this scenario was extremely burdensome.

I convinced Product that in these scenarios we would be better served by having the user start over this aspect of their process.  When you drop a watermelon, you could put it back together but is it worth the effort?  Just get a new one.  This saves the process from being bloated, including functionality which only covers a small percentage of use, and is actually easier for the user.

Error scenarios plus actions needed.
More explorations of error scenarios plus my reminder towards what we should allow re: Fences.

The Finished Product

This has been a long journey, we’re almost done.  I am constantly in awe of the simplicity and beauty of the finished product.

Live version - info redacted. Ability to chose new or existing number. Ability to remove (start over)
A shot of how the Number looks in a read only state.

But there is one last thing to discuss, the biggest success of this project.

Building for the Future – Options.

When this software was conceived, it was pictured as 1 Client = 1 Project in a lot of ways but this proved to be inaccurate.  If a restaurant signed up with multiple locations, they might need custom information for certain steps of the process, not just with The Number.

The number required us to be able to attach it at this individual level.  I proposed a change to one of our list pages, adding an option modal which could store these unique identifiers.  This was in some ways heavy handed for the task at hand but I successfully pointed out how this change would support future additions and changes (and named a few).

This change redefined what we are able to do, it gave us design and programing space to address new features that were on the roadmap.

A bird's eye view of the overall process (ignores a lot of details)
A more fleshed out Options page, this is once we've started to use it more.

What do user’s think?

It’s not about whether I like it or development likes it.  What do my user’s think?  I talked with them throughout this process, ensuring my assumptions were correct. Once it launched, I sat down with three users to get their feedback.

Our users tend to lean towards frustrated for a lot of reasons that would take a long time to get into. Most generally it’s because their workflow has changed and they don’t like/agree with it.

All three users spoke of the ease of use of the new method; none expressed any complaints to the process. One even said, “I’ve even done a Nancy.” That’s not what that step is called but I laughed.  It’s possible you’re reading this and thinking they might just be being nice to me but they have no problems walking over to my desk and letting me know how much they hate a design change to their workflow. They are an honest and vocal bunch, it’s only with their earlier complaints that I knew I needed to design the Options feature.