How design principles helped me stop bad design behavior

I’m working with a startup called SpotAngels, which is a community-based parking map.

I recently wrote our design principles. It could be considered useless for a small team whose main focus is to move fast, but referring to design principles helps me stop bad behavior and it speeds up tons of decisions every day.

😈 “Make it design-perfect”

We decided to implement a new feature. I sit at my desk and start mapping the feature’s flow. Because I like when my designs look beautiful, I pay attention to details and make all screens pixel-perfect. Super proud of my design, I’m showing my work to the Product Manager and the engineer’s team.

Surprise! I have to re-do everything because the flow is wrong, I designed useless steps and elements are hard to implement overall. I made pixel-perfect screens for nothing and I’m discouraged.

A perfect design takes time and we want to validate our assessment as fast as possible. Push quick and dirty is better than design a time consuming perfect experience.

We don’t build perfect experiences because our time is precious and we want to provide the maximum impact. We always ask ourselves how to obtain 80% of the value with 20% of the work. We are not famous or beautiful, we are efficient.

😈 “You can solve this problem by yourself”

I have to solve a design problem. I open my design software, create a blank artboard and start designing. I create new elements, design new flows and struggle to find the right solution. When it’s finally done, I go home and I open one of my daily apps.

Surprise! This app has already solved the problem I’ve worked on. If I had simply followed the way they solved it, I would not have had to redesign new elements.

Without a benchmark, it’s hard to solve a problem by oneself. It’s also easy to design new elements and forget to re-use our old work.

We believe in building coherent and simple products, so we are consistent and standard, but we can break consistency and innovate to serve users’ needs. Wherever possible, we should use the same language and the same design patterns.

😈 “Don’t add personality to your design”

I’m designing a crowdsourcing flow in which I ask a lot of questions to the users. All those answers are useful for the community and make our data more accurate. I’m thinking of how to end this flow. You know what? I don’t want to personalize my design. I will use a native alert with “Thank you” in the title.

Surprise! People did this flow once and never participated again. Why? Because they are not thanked enough in comparison with their contribution and they don’t feel important and needed.

We design for a single user and we always make her feel special, unique and beneficiary of a personalized experience. We also design to make her feel like a part of a community. We give her the feeling to be accompanied, important and useful.

😈 “This title is too long, cut it”

I’m designing a screen with a lot of long titles and it’s not beautiful. I’m going to cut everything and replace the missing part by '…'. I’m finalizing my prototype and getting ready for the user test.

Surprise! They don’t understand anything because they can’t read the entire information. When we want to be understood, making it beautiful is always the cherry on the cake.

We work hard to make it simple. Parking is a complex ecosystem and our job is to bring clarity to users. We always design the simplest experience to answer our users’ needs and our visual style is always clean and understandable.

😈 “What a great idea! Ship it!”

I’m using the SpotAngels app to find a parking spot on-street and, while using the app, a great idea comes to me. I’m 100% sure it’s a great improvement and many users will enjoy it. I come back to the office, and we decide to assess this idea’s impact.

Surprise! After our assessment, we determine that only a few people are likely to use this feature. This idea is definitely not game-changing. We are building for users, not individuals. It’s easy to cling to your own idea.

We start with identifying users’ needs. We do research, analyze data, we talk to users and prove our assumptions. We have empathy for users and remember that what they ask for isn’t always what they need. We end with users’ needs. We check and measure if the product built still answers the needs.

---

I really want to convince any team to write their own design principles. It helps to keep consistency in our design and make better decisions. It’s your angel voice against your bad behavior.