Resolver

Think of it like this: in Resolver’s old Incident Management software there was one data model, and customers would have to first create a case in order to log evidence, and that evidence would be tied only to that particular case. It was rigid but very easy to understand and configure.

In Core, you have the ability to create a case and a piece of evidence independently, so that you could tie that piece of evidence to multiple cases, but you’d have to create that relationship in the system that says “hey, these things go together, and evidence should a child of case”, and we needed a UI to say that… fun right 🙃?

I should mention that this was all going down in my first weeks on the job, and so I was just barely understanding this data model and how it should be built myself, so my early stabs were not great. A lot of my understanding of the problem space and user needs came from, what I would learn, was a lot of assumed internal knowledge of the customer, so I definitely still had a lot to learn there.

My first instinct was to create a wizard based around a series of dropdowns that would allow the user to multi-select Objects to build relationships, then I thought about letting the user type in Objets themselves — both fell down because they assumed the user came with an understanding of what data was available to them, which they wouldn’t have (and was sort of the root of the problem).

What struck me was the way our head’s of product and development would illustrate this model to people within the company to help explain it: they drew these circles on a whiteboard to represent different “objects” like cases, evidence, suspects, etc., and then drew lines out to them to create these starburst patterns that helped visualize both the data and how it needed to be connected. My new thought was that if this was the best way we’d come up with to explain the model to ourselves, we should leverage that as the UI we use to explain it to our users.

From there I started sketching something graphic, something that better represented a map of the data model we’d use on the wall. So, you need to anchor your data at a starting point, which might be a case, and from there you might want to pull in related data like, evidence, locations, and witnesses (and their related witness statements). You click to add new nodes and then configure directionality of each.

This idea at least gave us a starting point to begin building requirements around because we needed to get moving on this feature so that we could start showing the whole app to customers.

To move forward, I needed a sense of what the final output would be once all of this data work had been completed, and we had a Fortune 100 company that was willing to partner with us to show us what they needed, and that helped tremendously. Resolver did not have a history of user research or testing, and so I used this as an opportunity to show my colleagues the rudimentary benefits of targeted user inquiry.

Having zero risk or incident management background, I relied heavily on this customer for the context of how this software would be used — it was a revelation for me, for instance, to learn that almost no end-users would ever see the data model; that they’d probably only ever encounter a single form or report as a part of their day-to-day working life. That meant the only time this UI would be used was by the teams that configured this software. So while that meant lay-people didn’t need to use this UI, if a configuration was off it could torpedo a customer’s implementation. So the design needed to prioritize user accuracy above else.

Since I was Resolver’s first-ever designer, no one was quite used to taking ambitious interfaces and turning them into real code. It turned out we may have all been a little too optimistic about this idea — while our research identified the right problems and this design seemed to solve for people understanding and configuring their data model, it did not solve the problem of being a design that could be built in the amount of time we had allocated for this feature. So, our first pivot.

The good thing is that I’d learned what was key about the last UI (at least for those that had the opportunity to weigh in on it), and that was having a visual map of the data and how it related. That’s because these strings of connected pieces of data would ultimately be used to drive a specific report, and being able to a) see the data that you knew you needed and b) ensure that the right pieces were connected to each other is what allowed us to bridge the comprehension gap from our old hierarchical model to our new relational model — you basically create a new ad hoc hierarchy to drive each report.

With that in mind, I worked with our lead front end developer to find a d3.js interactive tree component to get us close enough to what we wanted by tweaking a pre-existing component and moving on.

Or so we thought. It turns out the number of configuration elements that needed to be represented at each node on the tree simply overwhelmed the simple UI that we had found, and there wasn’t really anything else off of the shelf that we could find that would work any better.

At this point, we really were against the clock, and we stripped the tree idea down to the studs so that we could build something. At this point we all knew that this solution was very unfriendly for users (including those within Resolver) but we also knew that “finished” was starting to outweigh “good” in the eyes of the teams waiting for this work, and so we got a severely compromised solution which none of us felt that good about.

While we were unable to build the specific solution we wanted, the issues we had integrating design into a long-established working culture stood as a terrific reason to reassess how design would function within Resolver. I was hired to make the app look pretty, but I used this feature story as an opportunity to generate buy-in for some more traditional design processes — including more extensive user research, a more collaborative ideation phase, and a ship-evaluate-iterate-ship cadence to our feature releases.

Being given the authority to tweak how we worked led to much more success on features to come, it allowed me to bring a design thinking methodology to other departments like Marketing and Services, and ultimately earned me the trust to build out a little design team as the company grew.

So, while the feature may not have been a success, the road to building it was rocky enough that it laid bare all the cracks and crevices that would need to be filled in if we were going to make design a functional entity at Resolver. To everyone’s credit, there was a shared eagerness to learn from and improve because of this feature, and I am thankful that I was given the space to investigate how we could improve, because there would have been justifiable reasons for everyone to shrug this off and continue with business as usual. Instead, we came together as a group to make change happen, making the ‘design of the design function’ at Resolver one of my proudest successes at the company.