Design is hard. We put a lot of effort into coming up with concepts. We work diligently to identify user goals and support them in the product. We create animations that help guide and inform our users. We design in little touches to add delight for our users. We put our heart and soul into our work.
And as much as we would like it, we know that not every little thing that we come up with will be implemented as designed. At some point, we will have to let go of something.
There are many reasons for this. The data that users need might not be available or easily collectable. Potential build costs might be too expensive or take too long to market, causing key things to fall out of MVP (and beyond). Whatever the reason, at some point we will all be asked to take what we designed and compromise to some new solution. With this in mind, I am here to offer some tips.
Shoot for the Moon
When you design, your first and foremost concern is supporting your users and their goals. You should be laser focused on this. Even though you know that at some point you will have to compromise, you should drive forward like you won’t until it becomes inevitable. There are several reasons for this.
First, each design change may have an impact on other parts of the system. We are designing systems, a series of inter-related pieces that all work together. Compromising early has some benefits. You can account for the issues early and avoid the risk that you will need to make major changes late in the game. On the flip side, the sooner you make a change, the more impact that you may have.
If you pull the trigger too early, you weaken the foundation of the entire system. Consider a rock rolling down a hill. A rock near the bottom of a hill will roll quickly and come to a stop. A rock that starts from the top can hit more and more rocks, causing a rock slide. The earlier in the process a compromise is made, the higher up the hill you are letting loose that rock.
Second, it’s easier to preserve a singular ‘ideal’ state than it is to preserve good ideas that have been abandoned along the way. Many systems can’t be built exactly as designed, but the ideal design is still worth preserving. When designers compromise, it’s important to mark what the designed state is and preserve this so that future versions still have something to aim for.
It’s easier to preserve a singular ‘ideal’ state than it is to preserve good ideas that have been abandoned along the way.
This can be very powerful if you’ve done user testing on the ideal state and have verbal confirmation from users that it is valuable. This can drive the team to work towards building what you designed, getting the data you need, or making the transformations necessary, even if it’s after MVP has been released.
Finally, you never know know what you might actually be able to get. I’ve had a lot of discussions with developers over the years. There have been many times when I have been expecting to compromise only to be surprised that what I am asking for is actually achievable.
In one case, I looked at the data that were available in the current system and didn’t see what I was looking for. I assumed going into the conversation with the developers that I would need to compromise on this one. I mentioned what the data was and why I was looking for it. I was pleasantly surprised when the response was a “Yes”. The developer said that they “had always collected it but never stored it because they didn’t know that it would be useful.”
They “had always collected [the data] but never stored it because they didn’t know that it would be useful.”
There is a lot of data that could be easily collected that isn’t. Your company may be collecting data for other products that may be useful for yours. Most companies have people with deep institutional knowledge that know the ins and outs of everything the company does. But you can’t find this out if you don’t ask. This leads to the second point.
Know the Data
One of the most common areas that requires compromise is with providing the data that your users need. While sensors have become cheap and data is ubiquitous, it’s still not always possible to get the data that your users need. It’s more common than not, especially in complex domains.
When you start discussing what can be built, its important to know the data. Where possible, investigate databases to know what data might be lurking in there. If you don’t have access to the databases, then ask to view data models that might have been created for the system. Get to know what data your systems are using and what other systems might be using as well. You never know where the data you want might be hiding. If you can get out ahead of this and know in advance, you will be operating from a well-informed position.
It also helps you understand what might work if what you want isn’t available. Compromise doesn’t just mean removing what’s not possible. Sometimes it involves modifying what you show to users to get as close a proxy as you can. It might not be exactly what the user needs, but it can still be a step closer. It’s tough to do this if you don’t know what else is possible.
This also shows the importance of working closely with the rest of your team. If you are constantly communicating/working with the product manager and developers, you can make requests for new data early in the process. This gives the team more time to pull the strings necessary to make it a reality. If you wall yourself off to design only to come out at to the end, it’s going to be much more difficult to compromise. You leave the team much less time to make the changes necessary. Speak up early and often and it becomes easier to get what you need.
Built is (Usually) Better
Your goal is to support user needs. You design to do so. But you can’t help your users with a pixel perfect mock-up. Your users can’t do anything with a JIRA story. In order to help your users, they need something built. This is why compromise is so important. As a general rule, it is probably best to err on the side of getting something built to put it in the hands of the user.
However, at some point the compromise actually can go too far. If what the team is able/willing to build is insufficient for the user, the product can do more harm than good. What you build can frustrate your user. It can cause the user to lose trust in your product. You can hurt your brand. Some products can recover from this, but companies have failed over less.
As a designer, you need to speak up if you think what is being built starts slipping below this line of quality. Compromise can become a slippery slope, and there are rarely clear signs that this one last compromise makes the difference between useful and not. Keep the user in mind and make sure what they are getting still provides value. Test again with the compromised version if you can. Let the users speak in whatever way you can to make sure their needs are considered. Try to get as much information as possible on the table so the team can make the best possible decision.
Everyone is a winner
The goal of a compromise is not to ‘win’. The goal of compromise is to do what’s best for all parties — the user and the business specifically. Products need to be built to be valuable. But building something does not make it valuable. If there are strong things that the user must have, then stand up for them. But understand why others on the team are asking for a change. You are working as a team; move forward in the way that’s best for the team.
No one wants to compromise, but it’s an important part of the process. It’s also a skills, one that will take time to develop. If you hold out for some ideal design, your great designs might never see the light of day. If you concede on everything, then your users might not be fully supported. Finding the best way forward takes tact, trust, and time to get right.
I still don’t relish the opportunity to compromise. I still pine for the ideal. But I have gotten better at it over the years. These are some of the key lessons I’ve learned through my experience over the past 14 years. Do you have other tips when it comes to compromise? I would love to hear it — feel free to share in the comments.
Thanks for reading. For more of my UX ramblings, follow me on Twitter: @bkenna1 or here on Medium.