Product Design

As A Department in A Large Institution

Open exploration of big design ideas is great and necessary, but not if stakeholders have pre-conceived expectations or view presentations of big ideas as promises.

Design exploration is an important part of product design, one of the major steps in a project. It is dangerous for stakeholders to think of it as something they can request on a whim. That presumes expectations. That presumes ideas presented will become ideas promised for production.

Planning

Always get specs. It can be hard to know for sure when a design is done if there isn’t a list of requirements to check against.

There is a relatively small project I was working on this week. I assumed I was finished yesterday, having comped all the views which would contain the content I was given. Today, a lead on the project looked at my work and asked about other types of content I didn’t know were a part of the plan.

As a professional designer, I can’t drop the blame fully on the project manager. I didn’t ask for the specs, which meant my assumptions ended up biting me in the ass. I assumed what I was given, was everything needed to be designed for, which wasn’t true. This particular situation was small stakes, but it’s a good reminder why specs are so important. Having written requirements protects everyone.

Process

Keep your iterations during the design process, and, when finished, look back and review how you ended up where you did. What decisions didn’t work and why? All failures should produce learnings.

I’m currently doing all my design work in Sketch. Previously, my tool of choice was InDesign. Both are great for me because I like to work iteratively and these tools make that easy. After every quick round of design changes to a comp/artboard, I make a duplicate and continue with my next changes there. Sometimes the changes are small differences on one element or component. Sometimes the changes are more broad and structural. But no matter the scope, I can always read the story of how I came to the final solution.

When it’s time to archive a project, I go through my designs and review. I take a few notes, asking myself, “What did I learn from this?” It’s not always much. Maybe something like, “Call to Actions always feel better to me when placed closer to the bottom right.” Or, “The solution for greater clarity in this component depended on increasing the typographic contrast.” I then often delete many of the interum iterations, keeping ones which most represent my best thinking. Reducing the clutter will make going back to the project later easier to revist.

Design Documentation

With design documentation, it’s difficult to discern what is too little and what is too much. While It’s a waste of time to redline every single element in a comp, a developer should never have to guess at anything. Getting the balance right depends on a few variables: the effectiveness of the design system in place, the experience and knowledge of the designers and developers, and the extent to which previously built components are referrencable.

At the very least, design documentation in specific agile tasks should define anything novel not yet established in the product. This work is the designer’s responsibility. The developer, however, needs to know enough about the design system and the rest of the product to be sure they are following established patterns. There is a natural give-and-take here which needs to be worked out between designers and developers. No two product teams will have the exact same balance.

My attitude is always to accept 100% of the responsibility in situations like these. As a designer, assume the developer needs you to be highly detailed in your documentation. Be thorough at the start, and later discern where you can lean on your growing design system.

Should Designers Code

Now is maybe a good time to touch on the hot drama discussion around whether designers should code or should developers study design. There is no right or wrong answer to the topic, but in my opinion, it is worth understanding the fundamentals about any subject which is tightly tied to your own career. Can a chef be successful without understanding how plants and animals are farmed? Can an architect be successful without knowing how building materials are collected and treated? This works flipped, as well. How great is a farmer who doesn’t know the fundamentals of cooking, of how his product is used? How good is a lumber producer who is unaware of how their lumber will be used?