In just about every step along the way through my design process I am constantly looking for inspiration and digging in to how others may have solved similar problems (no sense in recreating the wheel if there is an existing paradigm). Ideally I’m getting hands on with these products, which can be tough when you’re talking about enterprise software. Google Image and Dribbble searches are always handy and can suffice when you’re unable to use the real thing. Fortunately, I was able to get my hands on numerous tools. This went a long way toward helping me understand how they were handling custom data visualization and dashboards, and thus how users may already expect to perform some of the tasks they’ll be doing with our software.

These applications and websites that helped me better understand the current landscape of data visualization products and their UI.

Time to Test

One valuable piece of ForeSee’s professional services offering is access to our extremely knowledgeable and talented usability team. Their main focus is to investigate the websites and products of our clients, helping them with any usability issues they discover. In addition, though, they take time out of their busy day and play a huge role in assisting us by facilitating our testing sessions, pinpointing issues, and recommending adjustments.

When discussing the projected timing for testing, we decided the earlier the better. Creating a completely customizable dashboard and data visualization system was a pretty massive undertaking for us. The sheer scale and complexity of this project pushed us to verify as early as possible. We didn’t want to go too far down the direction we were headed if it wasn’t the right course. In hindsight, testing early with our clients like we did was absolutely the right decision. In fact, the design ended up evolving so much after the first round, we held a second round of testing after the updates.

Here are some of the most prevalent takeaways from our testing sessions:

Needed to clarify what a “card” was. The concept was new and we hadn’t done a great job explaining the new system.

We had numerous terminology issues to address.

There was confusion around “Done Editing” vs “Saving” a card (we ended up combining the concepts).

Nearly all users tried to interact with the charts in some way (drill-in functionality is key)

It took time for users to find the menu of dashboard options initially, but all eventually found it (this was deemed OK by myself and the usability team as this seemed to be a justifiable learned behavior)

If you’ve ever been a designer witnessing testers work their way through some of your testing flows, then you know how agonizing it can be to see them inevitably struggle. Biting your tongue when you just want to shout “Click the big blue button!!” In all seriousness, while watching these can be painful at times, user tests are the single most powerful tool you have as a designer. I’ve never gone through testing where I didn’t learn something, and these tests held true to that. After some design refinement and polish, we were now ready to hand off the finalized work to the developers.

The Handoff

One might think that the moment the designer hands his work off to the developer to create, his or her job is done. However, this is far from the reality of the situation. As the developers piece together your design, those back-and-forth discussions are inevitable. And that’s good thing! A solid line of communication with the Dev Team is vital. Things can easily get lost in translation between static image and code. There are, however, numerous ways to set your developers up for success, and reduce the amount of uncertainty, guess-work, and questions they have. In this example, I knew the complexity and sheer number of possibilities that came with this project could lead to a lot of questions. I set out to answer those questions before they were asked and tried to prepare and guide my team as best as possible. Here are some assets I created to help with just that:

Guidelines for the card system

A guideline doc I created that includes direction on how we handle sizing, spacing, text, color, responsiveness, labeling, overflow, hovers, dragging, and tooltips.

Card creation flows for each card type

Each type of card had unique options to consider when going through the building process, so I designed flows to cover all the possible use cases for each card.

Here’s an example of what the builder flow looked like as I linked it together in Sketch (using InVision’s wonderful Craft plugin 🔥)

Edge cases, empty states, error states, and loading states

I made individual pages including edge cases, empty states, error states, loading states, and tooltip examples for each card type that we were building to help answer questions for the Dev and QA teams

A closer look at some of the edge case work I did for this

Matrix of all our different survey types

As you can see, we have lots of survey types, with lots of pages, and each have some unique UI dependencies. I created this to allow the team to quickly see what the UI would look like for all these different survey types.

InVision was perfect in allowing me to piece all of these things together. I used the popular prototyping tool in a unique way by hosting this abundance of information in a single, easily accessible location, allowing the team to consume it all in a manageable way. Being told by the Development and QA teams how valuable all of this was made me incredibly happy. It’s a standard of detail and thoughtfulness that I’ll continue to hold myself to.

There were still plenty of questions and discussions happening during the development and QA phases, but before long we had a real-life functioning product. Getting your hands on the real thing that you worked so hard to help create is what product designers live for. The custom dashboards and card building features have only been live in production for a few weeks, so I’m sure we’ll be getting plenty of feedback and more insight on how we can improve it further. For now, let me share with you the things I’ve learned and the major takeaways from the invigorating process of building this thing.

Learnings

Early Documentation

In the early stages of a project, we need to do a better job of documenting and organizing our knowledge and findings. Understanding the problem, early research and discussions, competitive analysis, success metrics, testing results etc. None of this could be found very easily in a single, handy location. I ended up establishing a new process for the product team and we now require a Product Brief (within Confluence) for each project that serves as the single reference point for all of this information.

Better utilizing our clients’ time

We have great clients who love being involved in our product development process. Often this means being asked to test our early designs. Our pool of client resources to pull in for testing isn’t abundant, however. I feel like we may be able to better utilize the precious time we have with our clients. Every face-to-face moment with one of our users is so precious. I’ve found that during our early interviews when we’re discussing pain points, functionality needs, and our early ideas for a solution, this is when we’re getting the most insightful, empathy building nuggets from our clients. So, instead of asking these folks to perform click tests that check for overall usability of the designs, let’s utilize their time in the most impactful way possible. This doesn’t mean forgoing usability testing by any means. We have a large internal analyst team we can leverage for these sorts of usability tests.

A formalized “Design QA” process

When pieces of the product are handed off to QA by the front end team, designers aren’t always brought in to assist with the testing. This can result in us later finding design problems, specifically some of the more aesthetic issues that other team members may not notice. While the back-and-forth we have with developers often help in refining these details, we had no established process and things were slipping through the cracks. Moving forward we plan to have a specific Design QA step in the process where designers sign off on the dev work.

What’s Next?

When releasing software, the goal is not to ship a “complete” product. Waiting until every desired feature is packed in there before releasing is a sure fire way to mess things up. Like all projects, this one was not immune to the constraints of time and personnel. Thus, this initial release was missing some big ideas that we plan to add: