When tasked with overhauling a legacy feature of our application, I worked closely with Product and facilitated a series of design exercises. We gathered a team of customer facing staff and engineers to map out the current feature, build a lean prototype, and discuss it with our users.
You can’t just start building whatever you think might be a good idea. Never assume that you know what’s best for the customer. Talk to them, show them what you’re thinking, and look at the data.
There are lots of ways to validate an idea. I find a mix of qualitative and quantitative data help tell the full story. Tasked to find a quick win for one of our features, I wrote an SQL query that showed me the most common ways users had set some custom configurations. I used that data to determine which configurations to offer as a standard preset.
On another project, I needed to learn more about why users weren't adopting a recently launched feature. I worked closely with our Customer Success department to set up user interviews with specific clients who were great candidates for the feature or had set up an alternative workaround to accomplish the same thing. Hearing their perspective gave me a deep understanding of where the feature had failed and allowed me to create a more user centered solution to the issue.
Draw it on paper, make it in Sketch, animate it in Principle. Anything goes, just build something. Create a thing that a person can see and say “that is bad”, or “that is good”, or better yet “here is what I wish it did differently”.
When working on an overhaul of an export feature, I created some low fidelity prototypes to discuss with our customers. I chose low fidelity so the customer would focus on the features and functionality we were exploring, instead of final stage design decisions like color and typography. I think wireframes like this offer an abundance of perks, such as the ability to iterate quickly without worrying about visual design.
When trying to nail a visual design or perfect an interaction, I make as many iterations as it takes. I send out the most promising versions to colleagues to run some quick and easy preference tests. Allowing people to choose between some options and explain their choice will always yield the best feedback.
Nothing ever got better by staying still. If you want to make something truly useful (and make it well), then testing is the answer. Make a couple versions and see what sticks. Do some indirect testing. Do some direct testing. Gather the data and determine what you did well and what needs to change.
While I was working on a redesign of a very specific power user feature, I had to take a ton of data and make it easy to understand. I also had to account for several technical limitations regarding version history and data storage. Once I got my design in a good place, I put it in front of several Product Support Specialists to see what they thought. They gave lots of great feedback, asking questions I hadn’t considered and trying to do things I had not accounted for. I took those notes and made changes to optimize the feature.
You'll learn a lot during a project. When you find something that isn't working, make the changes that will most benefit the user.
When I first arrived at ActiveCampaign, I highlighted several parts of the platform I wanted to improve. The navigation and general structure of the "overview" pages stuck out to me and over the course of 6 months we chipped away at them, resulting in a drastically different look and feel for the app. I gathered lots of user data to inform my decisions and worked closely with engineers and product managers to develop new and useful features that our customers would benefit from. Along the way, many iterations and experiments helped us determine the best paths to take, resulting in a design and set of features we knew had value.
I don't handoff designs and leave the engineers to it. I sit with them, always ready to offer constructive feedback or help test the most recent build. In addition to constant collaboration, I provide a stateful guide covering all possible variations of a feature. While I am always available to follow up on these specs, creating a stateful guide helps the engineering team work quickly and stay detailed.