Rule #1: Understand The Details

This is the most paramount thing. I only have one rule. You must understand the details at least as well as the engineers or product managers. How can the organization possibly trust designers if they don’t know the details.

Never put a button on a UI if you don’t know what is it for and why a user would care.

Design the Details

When designing, include every use case, every error case, and every contingency. It’s not the way it looks, it is the way it works. Engineers and PMs will respect the team more when they know the details are in the designs. It takes more effort, but it is worth it.

Make it Realistic

Never put in Lorem Ipsum. Always try and make the content plausible as if a real customer would have that data. This is especially true for graphs and charts. Never have a chart be nonsense. Make the numbers add up to something sensible. Engineers will respect it and it will make it easier for people to give realistic feedback. Lastly, it helps the designer really know if their designs will hold water.

This is especially true for volumes. Never design a table with 3 things in it if the reality is that the user would have 3,000 or 3 million. Designs change based on volumes. Be careful with them.

Show Prototypes, not Canvas

Don’t make people look around your canvas to find the right info. Set up a prototype and walk them through the user interface. In a prototype, everything should be clickable. Alternatively, you can make a storyboard, which has little hands to indicate where to click and it is a straight line. Use storyboards when you want to show one specific case. Show prototypes when you have a wide swath of UI.

Pair Designing

I always try to put multiple people on projects. So if you have 4 projects and 4 designers, each designer would be assigned to 2 of the projects. Each with a different person. The reason is fairly logical:

1. Protection against SPoF (Single Point of Failure). If someone goes on vacation or leaves the team, you don’t want the project to be left unassigned and the engineering and product management team lose confidence in the design team.
2. Energy levels are easier to maintain when you have someone else working side-by-side with you. Figma is especially good for this. I didn’t employ this method before Figma, but it has been great ever since.
3. Growth. Designers leave from each other. They learn techniques, strengths and weaknesses. Pairing people up let’s the team learn from each other.
4. Bonding. You bond with people you work with on a project. Not every pairing works well, but that helps you manage the team effectively.

Design Systems

Design systems should be bullet-proof. Every component should be a delight to use. A great Figma library can multiply your efficiency by 10x. You can iterate more, design more. Everything goes faster. It just takes someone paying attention to the details. Designing a design system is design. Your users are the designers. They need training and need to learn how it works, but usability is a key factor. Test your components with them and make sure they can design quickly.

Note: There is another thing which is a specification for components for engineering. This is NOT the same thing as a Figma library. Don’t mix up the two. One is for designers and the other for engineering. Make the library for designers simpler with only the components they use in normal design.

Everyone is a Leader

I share my post about Different Kinds of Leadership with my teams. I encourage them all to employ as much of those techniques as possible. I also share my design levels chart and emphasize how leadership is the most important aspect of promotion and additional responsibilities. Everyone can be a multiplier on the team if they know how to do it.

Information Architecture

Information Architecture is probably the most important and neglected part of big product design. It sets the stage for every feature but there is often not enough room for a designer to work with. I centralize IA either in myself or someone who specializes in it.

Catalog First

Whenever designing, try and create an outline of what you are going to do and wire up the screens with no content. it helps everyone understand what is about to happen. Another kind of cataloging is to list out all of the options for a particular design choice. Don’t design them, just sketch them in FigJam (or equivalent) and list them as options. No option is bad as long as it is plausible. Then when you run out of options, you eliminate the bad ones and then decide which is the right option to go forward with. Usually it’s a choice of optimization, such as the option that is easiest to produce, or the one that is best for sales, etc. I call this process cataloging, not sure why.

Acceptance Process

These are a series of 1:1 meetings with stakeholders to show them designs and get feedback to improve them. (Detailed blog here) This is an essential part of a strong design team. You can’t just show your work to a group and expect it to go well. A committee is a horrible forward to give feedback on a design. If you have 1:1 meetings with people you can make the group meeting go much smoother. They will have all seen the work and all have had a chance to get their fingerprints on it. If this process doesn’t happen, you are just asking executives and other stakeholders to grab your mouse and start designing themselves.

Look for Opportunities

If a designer bonds with people outside their department, they will inevitably find opportunities to give good UX to other parts of the company. This includes, training, support. documentation, product marketing, and even finance.

Example: I once helped a finance person who was having trouble collecting taxes from customers. We had reached a milestone called “Nexus” which meant we had to charge sales tax in the state of Texas. The customers refused to have this increase in payment. So I designed a video called “Nexus in Texas” and it told the story of how that law began and how the money is used to build bridges, schools, and public works in Texas and that we did not keep any of it. We produced the video and the customers literally asked if they could copy the video to help their own finance team collect from their own customers. Lesson: Design is more than just UI.

Summary

Strong designers need to believe that their expertise is equal (yet different) to that of engineers and product managers. Strong design teams need to work together to feed engineering design specs that create better products. These things don’t happen accidentally. They require intent. I ask that intent of all the designers on my teams.