Making Adjustments—Moving From One World to Another
When Charles first came to Instec, they were in the middle of building out a new configuration tool for their flagship application, Quicksolver. Charles describes it as, “Take everything you know about your auto or homeowners policy and put it on steroids. These applications dealt with issuing quotes and policies in the commercial insurance arena, so your quotes were handling not one vehicle, but fleets of vehicles; not just a home, but restaurants and multiple buildings. So not only did I have to quickly get caught up on the industry basics and what problems this application was trying to solve, but I also had to figure out all the terminology. Meeting after meeting, I would be cutting people off mid-sentence with, ‘Wait…what does that term mean?”
Charles got into the trenches quickly, attaching himself to two insurance analysts were working on the project. Initially, he says, it felt as if he were working on an application that was in a different language. With a translator (i.e., insurance analyst) next to him, he started fixing the low-hanging fruit and solving problems, bringing modern design ideas to the application.
This meant he had to separate out the problems he was having trying to learn the industry from what the user was trying to do and what patterns Instec could implement to make an immediate impact. “Bad experience is bad experience, whether you know the terminology or the industry or not,” says Charles. “I started there.”
Charles, insurance analysts, and a product manager would lock themselves up for days at a time, drawing out solutions. At first, Charles focused the others on simple templates to would deal with primary user actions. If the user was searching for something — say a company or an agent — they would be presented with one thing. If they were looking to create something new, they would get another. This helped the analysts and product manager to think in terms of a handful of screen templates, instead of dozens of screens.
“They taught me about different lines of insurance,” says Charles, “and I taught them about prioritizing actions for the users. They taught me about coverages; I taught them about minimizing distractions in complex forms and how they could speed up completion.”
He concludes, “It was a knowledge exchange program.”
Charles realized they needed a tool that could be picked up quickly, allowing them to test those concepts. After evaluating several products and approaches, they landed on one that not only had a minimal learning curve but would create powerful, interactive prototypes that would bring their concepts to life, allowing the whole team and potential clients to understand what was being built.
That product was Indigo Studio.
They taught me about coverages; I taught them about minimizing distractions in complex forms and how they could speed up completion. It was a knowledge exchange program.
When doing new product development, Charles and his team spend a lot of time talking about who will be using it, what problems the product solves, and so on. A lot of this comes from customers saying “Hey, we can’t do X, Y, and Z. If we could, we’d generate so much more revenue.”
Once Charles and his team know all of that, they draw...and draw...and draw. “We’re burning through markers left and right, leaving conference room marker boards all scribbled up and the people after us mumbling as they erase,” Charles jokes. “The drawers of my desk have become the graveyard of unused ideas, overflowing with newsprint paper holding discarded concepts and sketches.”
Go Interactive with Indigo
Once they have some good concepts, Charles’ team executes those concepts as interactive prototypes, built with Indigo Studio. Indigo Studio has been vital for Instec because it allows the team to stand up prototypes very quickly. They build screens around a user journey (or multiple journeys), and can quickly see what’s working and what’s clunky — constantly revising along the way.
As soon the team feels it’s in a good place, they get the prototypes in front of the product managers and development team, walking them through the journey and showing them the new features. This is extremely valuable, because the developers can see the whole picture and talk about how they’ll solve something, or where else a feature could work. “We always come away from those meetings with pages of notes, and we start making revisions, posting the new prototypes for review, and iterating till we get the green light,” says Charles.
From here, one of the analysts puts detailed specs together, not only including access to the working prototype but also exports of all the screens from Indigo Studio. There is no ambiguity. Nothing is blurry or unclear. “Through the concept and prototype phase, we’ve solved most of the major issues upfront, way before we’ve had to spend hundreds and hundreds of hours in development. The cost savings is immeasurable,” Charles notes.
Working on All Fronts
In addition to new product development, Instec uses Indigo Studio in their sales process. Customers aren’t buying programs from an app store or an ecommerce page with the click of a checkout button. This industry can have long sales cycles and it’s not uncommon for a deal to take as much as a year to close: almost every customers needs customizations to handle their requirements.
To accommodate this high level of customization, experienced insurance people meet with the potential customer and get a detailed understanding of their insurance products and what Instec needs to do in order to work for them. Charles’ team then meets, distilling their needs down to customizations in the software.
They then prototype a few variations over the course of a couple weeks, the prototypes ping-ponging between Charles and the analysts. “By the time the potential client has their next meeting with the engagement team,” Charles says, “they’re not just given a slick speech or documents on what Instec can do, they’re actually seeing what it will do, based on their users’ needs. This not only demonstrates well to their users, but to decision makers — the stakeholders at the table — who now know exactly how the system will operate, with no ambiguity.
“Every time we do something new, we’re making bets in the marketplace,” Charles says. “Getting feedback early, allowing us to make necessary changes, really helps us feel good about those bets. Our developers love Indigo Studio, too, because we can export code directly from our prototypes and stand stuff up even faster. The tool has been indispensable across the board.”
There Are Always Challenges
Charles isn’t naïve about the challenges — and the work — ahead of UX designers. “You get hit a lot with ‘it’s good enough’ or someone will play the change for change’s sake’ card,” says Charles. “And then there’s my favorite: ‘no one complained about it.’”
“But just because someone is used to something or doesn’t complain, doesn’t mean it shouldn’t be fixed,” says Charles. “If you use the left turn signal in your car, and the right signal lights up, it’s broken. We don’t need to wait for someone to complain.”
The other thing Charles tries to be watchful of is who he gets feedback from. “Stakeholders are not users,” he says. “They make strategic decisions and sign the checks. They don’t spend their day wondering why a dialog keeps popping up, or why fields are clearing out their data, or why it took seventeen clicks to complete what they thought was a simple task.”