Why design principles shape stronger products

Our design team didn’t have any design principles and it was difficult to determine design success.

My job is to design and improve/redesign a legacy CRM system for real estate professionals. We often ran into design limitations because we didn’t have any principles to refer to. Our users have a love/hate relationship with the product. Some users think it’s a great lead generation tool that boosts their business and helps to manage their contacts. Some of them think it’s cumbersome, time-consuming to complete tasks, buggy and not user-friendly. There is so much to improve, but what are the restrictions?

New features vs. existing problems

We collaborate with our user research team to conduct user testing/interviews. It varies from testing existing features to redesigning a prototype. We gather user feedback and categorize them to define or confirm usability issues. We go through the cycle of user testing, design, and iterate. Yet, while we working hard improving the product, new features are often requested. This can be frustrating, especially on a page that already has usability issues. The more functions you add, the more complex it becomes.

Legacy design patterns

At work, we have our legacy design patterns. Thus, new designs are always tied into consistency. In theory, consistency is necessary because we don’t want to detract from what users are doing. Though at the same time, we want to move fast and reduce task clicks. But then we would have to sacrifice consistency. What should we do? How should we rank consistency and efficiency? Which is more important?

User needs vs. Design needs

Through user testing, we learned that user needs often don’t match design needs. Admit it, don’t we all have the tendency to design based on our hypothesis? We think we understand the user flow without further user research. The truth is that we aren’t always right. The lessons impart a human-oriented sense of “why?”. Why don’t users just get it? Why can’t they find such an obvious button? Why wouldn’t they want to use a function that we think is useful? Why don’t they like the existing features? So many why that confuses us.

We learned that the company built the CRM over years. It was developed from version 1 to 2, and now version 3. The legacy patterns worked for the previous versions, why won’t they do the same on the current one? We started to realize that the users are different. When you are dealing with diverse users, it’s important to first understand their needs. Learn who they are, what we need to design for. Make sure you know what their user stories are, and what their journey map is like.

Inspirations

We came to the conclusion that we need to create a set of design principles. I set up a design team meeting and required everyone to present their ideas. I recommended a website called Design Principles FTW for inspirations. You can look up design principles from a list of companies, such as Google, Facebook, Apple.

Define Design Principles

We generated solid design principle ideas from the presentation. We needed to go deeper and define what they are. I set up a second meeting and asked everyone to write down their principles on sticky notes. Then we all put them up on the wall to group them and rank the importance.

Maslow’s hierarchy of needs

As we started to figure out what the design principles should be, we needed a better way to visualize them. Back in June, I wrote a Lyft redesign article and talked about their design principles. They used a pyramid shape ( Maslow’s hierarchy of needs) define the importance of order. It inspired me and I decided to give that a try.

I printed out the design principles we created and cut them into pieces. I drew a giant pyramid on the white board and put a sample of Maslow’s hierarchy of needs next to it. Each of us got a set of principles and put them into the pyramid based on the way we wanted to rank them.

Oops, conflicts occur

We realized there were a few conflicts. We can’t decide which is more important, consistency or efficiency? We had a long discussion. At the end, we decided to group consistency and efficiency together. The reason is that it often differs depending on what project you work on and where you are during the process. For example, our engineers prefer consistency because they already built an style library. As designers, we have empathy for our users because of the extra number of clicks they have to go through. We want retention! We want to attract existing users of competitor’s product to our product! We know some legacy patterns are stopping us from accomplish it. Why not explore options that can actually help them run their business more efficiently? What if there is a need to prioritize efficiency over consistency for a specific case?

Here is something I learned from design events:
Don’t be afraid of creating new patterns if specific legacy patterns aren’t working well. Communicate with the engineers and product managers, help them understand the special needs. Hopefully, that way you can get your new design patterns into the next sprint.

Finalize Design Principles

We were so excited! Then, we paused. “Collaboration” exists in every step, we should take it from the pyramid. Beauty is an effective word, but why don’t we make it sound more artistic and fancier?

We had an idea to visualize the pyramid with pictures of examples next to it. I thought about how burgers are made, with bread, meat and sauce. I tried a few ideas and decided that meat is too specific. I replace “Meat” with “Ingredients”, as it’s more broad and presents psychological needs better.

Here is what we ended up with:

• Know your user = Bread (Basic needs)
• Clarity + Consistency & Efficiency= Ingredients (Psychological needs)
• Aesthetics = Sauce (Self-fulfillment needs)