Comparison Table

How I designed a new feature for a product team in about 10 hours.

Problem

In this example, a smaller product team that does not have an assigned full-time product designer requested help making a comparison table for a product with only a handful of B2B users. I was already working full-time in a Design Operations role at Ticketmaster and would only be able to devote about 10 hours to this work.

Step 1

Assess what the product team has prepared up to this point

I find that product teams may have already come up with a make-shift mock or perhaps white-boarded a few ideas in advance of requesting help from design. More importantly, it helps to understand how often they may have worked with a designer before and how much value they place on quality design. Said differently, how much time will I need to spend educating the team on the importance of design versus being able to start in on the work?

Thankfully, the Product Manager was open to new ideas even though he and his engineers had already doodled a solution they thought might work (below).

Step 2

Determine how likely user testing will be needed

One item I try to determine right away is the likelihood of user testing for a given new feature. Here are a couple of questions I like to ask myself when determining the need:

1. Is there is a high degree of change to the users' existing workflow?
2. Is the new feature highly complex?
3. Is the feature more of an epic?
4. Is there a high degree of ambiguity about what is currently causing user frustration?

If I answer "yes" to most of the above, then I know I may need to bake in some time for user testing. In this case, based on my conversations with the Product Manager, I was able to determine that user testing was not likely to be needed.

Step 3

Determine what success looks like

I say this to mean - what is the core user problem you are trying to solve?

In this case, the user is at work using a Ticketmaster event list application with rows and rows of events and trying to quickly filter the list of events down to known cases where there are listings with conflicting information. For example, at Ticketmaster, the artist can set up several types of tickets; let's say, upsell or standard, and then the user needs to make sure the event has the correct type of ticket listed.

I often find that it helps to revisit the core problem that you are trying to solve for multiple times during the product design process as it usually enables you to uncover a design that is even more simple.

Step 4

Set the bones

I know many designers start their work with doodles on paper or a whiteboard. I am just not one of them. I do doodle ideas in a notebook I keep at my desk, which helps facilitate plans with other designers, and I am capable of whiteboarding ideas when collaborating with stakeholders.

However, when it's just me, I have a pretty clear idea in my head of how to start, and I have limited time; I like to start in my design tool especially if I have access to standard components in a design system.

So, I like to "set the bones" of the page layout right away. In this case, the solution will almost assuredly be a table and will be a desktop application. So, I can start with a 1,440px wide layout, and set necessary margins and padding according to the grid system included in the design system.

Step 5

Give them something to react to

I usually work quickly to put together a quick first draft to give my audience (in this case, the Product team) a chance to see some work in a reasonably short period. I do this for the following reasons:

1. It shows that something is getting done.
2. Sets a collaborative design process tone.
3. Helps to head off any miscalculations on my part.
4. Get more information about what is possible.

There is a bit to unpack here.

Showing that something is getting done is super important. Nothing starts to deliver confidence than seeing design artifacts. It's a lot like getting home, and there is a package on your doorstep! Stuff is getting done, and Product Managers loves it when he or she can see things getting done. Seeing is believing and showing something sooner rather than later demonstrates confidence, especially when the initial design is not super polished.

Setting the tone that this will be a collaborative design process is critical to get buy-in. This sets the stage that you are merely the humble design person who doesn't have all the answers. Who knows, many times, the Product Manager can surprise you with brilliant insight or even suggest the right solution outright.

Heading off any miscalculations early in the process is vital. I very much like to avoid friction in the design process, and indeed, one way to create resistance is to rely too heavily on early technical and business assumptions. Engineers and product are usually in motion while the designer is mulling over options. Time and time again, stuff changes about the initial set of assumptions. Perhaps some of the data is technically not available, or the business assumptions get modified. Whatever the case may be, show something early so you can adjust your design earlier in the process.

Getting more information about what is possible will give you a clearer path to success. It always happens, the engineers start digging around and learn that can they get this data but not this other data or that combo box with search inside a dropdown you would like to use is too heavy of a lift for the size of this project. Knowing the constraints earlier in the process is a winning formula for not spending time designing a solution that cannot be built.

Here is the first draft of the solution.

Step 6

Give them more drafts

Invariably, you will get course-corrected a few more times after you show them your first draft. So, keep each draft light on the overall effort, which means don't pursue pixel perfection and use simple prototyping like Invision or Sketch to deliver early-stage drafts.

One exciting thing that happened on this project was the scope creep of needed columns. If you endeavor in the art of B2B or Enterprise Design, you will likely run into the situation where product, users or engineering believes it's a good idea to see more columns of information, and it happened here. As you can see below, column bloat rears its ugly head! The best way to combat this is to calmly warn the team that their desire to add columns will result in horizontal scrolling and then proceed to mock it up. Once they see this artifact, they usually reverse their opinion and want to scale back the number of columns. Score one for the designer!

Usually your 3rd or 4th draft is where the design takes its most simple form

Below is my 3rd draft that includes two dropdown menus.

The Winner

The 4th time is the charm

This (below) wound up being the winner, winner chicken dinner design, and it is the most simple of all the drafts I completed. I was able to take the Product teams' idea of a table with asterisks to denote where data conflicts were present, to a sprawling mess of column bloat, to a solution with an accordion menu, to one that requires no additional clicks, is super-intuitive and elegantly simple.

You may also like