“They ruined our design!” Alex said this after playing with the mobile app that he had just downloaded from the AppStore. Alex was one of the key designers who designed this app and worked hard for the last six months. His team was responsible for creating pixel-perfect layouts, eye-catching illustrations, and smooth animated effects… and only a fraction of what they’ve created was in the final design.
When you invest so much time and energy in creating something beautiful, you can be easily frustrated to see that the final design looks drastically different from what you’ve designed. But if you take another look at this situation, you might understand why you should think this way.
This article will explore three reasons why the final design might not be the same as the one created by designers and how designers can deal with it.
“Know your user” is by far the most crucial rule in product design. Product teams invest a lot of time learning user needs/wants and preferences. Yet, sometimes it might be impossible to predict how users will react to your design decisions. Of course, the earlier you validate your hypothesis, the better. But often, you have a holistic understanding of user reaction only after you release a product on the market. Once the team receives this feedback, they have to adjust the design to meet the user’s expectations.
Businesses hire designers to solve problems. Stakeholders know what they want to build and why. They usually reach designers with a specific business model that they want to frame in design. Businesses have budgets, and unfortunately, sometimes budget management might not go as planned, so the production cost skyrockets. Nobody wants to release half-baked products, so this situation force management to make tough decisions like:
“Should we limit the number of features or invest an extra $XXX in product development?”
“Should we add fancy animated effects or release a product with simple motion effects?”
It’s much harder for businesses to trim the set of features, but they are most likely to simplify the design.
Designer: “All I want you to do is to take this design and code it. Can you do it?”
Developer: “No, I can’t.”
Designer: “Why?”
Developer: “Because it’s not technically feasible.”
It is a typical dialogue between designer and developer. Not all that was designed can be implemented. Sometimes the problem of technical feasibility can be solved by adjusting the technological stack (i.e., selecting a new technology). But sometimes, the technology that allows creating a design doesn’t exist.
Communication between designers and developers is integral for project success. The earlier designers can evaluate their design decisions, the better.
No, because not only product designers are responsible for creating a product. Design is a team sport — designers, developers, researchers, stakeholders, and the sales/marketing team work together to create a design. The only situation when designers own the design they created is when they combine the roles. In other words, it happens when we design products for ourselves.
No. There are at least a few reasons why designers shouldn’t be upset.
First of all, when you’ve finished a project and released a product on the market, you should have a sense of completion. Be proud of yourself and the team you worked with. You did it.
Second, there is a high chance you have a new experience that you can share with other people. It’s a perfect opportunity for you to update your portfolio.
Last but not least, design is not a static thing. If the team’s decisions are incorrect, the team will update the design in the next interaction.
Originally published at whitelight.co
