Early on in any project, it’s time to consider the goals, budget and timeline. The combination of these factors create the constraints needed to design a solution.
These constraints point toward a concise ratio. Playing it safe based on that ratio can be smart, but can often get you stuck if you’re not using a smart process. This can be bad for your business and spin into a never ending cycle of mediocrity.
Leap Ahead
Even with flexible factors, you will limit innovation without the right mindset. For example, you cannot get near the improvement that could be possible with simply extending a timeline. And you can’t innovate by being afraid of risk. This doesn't mean you should throw your constraints out the window. Quite the contrary. For a successful project, it’s necessary to mitigate risk and gain buy-in on even the most meager change. Constraints give you direction. But, don’t be fooled into thinking you can wait until another iteration to explore a bigger leap. It will never happen unless you recruit real people to tell you where the line is. Those who are not constrained, and who ultimately lead direction.
Are you tired of designing ideas that could be amazing for your users, only to be told to take a smaller step ahead? Or have you allowed innovation to take a backseat, playing it safe from past experience? Are you working in teams that push back on or delay new ideas?
I would bet that most designers do their best on every project. I know many use their skills to convince others to take user experience to the next level at every opportunity. I also know that when I’m designing, I always design with the most innovative solutions even if I know it may be too big of a change for reality. After I get my ideas out I work with my team to reign it back under constraints. But we try not to reign it back too much until we get real users and technologists involved. Autonomy is an extremely important part of the design process if you want to lead.
Ask Forgiveness (Early)
Perhaps you have heard the phrase “Fail Early”. I prefer “Ask Forgiveness, Not Permission” when it comes to gathering insights for design decisions. As you learn more, you’re not failing. You’re iterating, and not waiting for permission to do your best. To know where the line is, you can set up a pilot program with select users, utilizing what you think is the best experience possible. It's important to note that this is just part of the user testing and research process. After you have some iterations and testing under your belt, you can design a pilot to try it out.
Having real users experience your idea allows you to pull out all the stops, know you may be wrong, and be ok with it. You can even use it to re-confirm things you've learn in the past over time. Worst case, you will still end up with a bigger leap than if you had played it too safe yet again. You may instead find excitement in user delight on strong innovation that takes a stand against a bad experience they had come to expect. Additionally, you stop the cycle of setting low expectations with partners. You will never make progress if your iterations are always safe. Either will show in your business results.
Goal Planning
Take some time to have a clear understanding of what do you want the pilot to help your team decide. Make a list, and plan accordingly.
If you use your pilot with a best case design, you will learn a lot to help you plan how to get there. One of the most important things you could learn is if it’s worth it to get there at all. You will save time and money with the focus you gain. User-backed research gives a firm foundation to discussions moving forward.
Your users will be using this in context. Here some things you will learn before you invest in the real product.
- Unforeseen contingencies / scope change
- Milestones - plan how to build it
- Are users confused by the change?
- Will users pay for this feature?
- User success (general or task-based)
- User enthusiasm - emotional measure
- Do users perceive this as an improvement? By how much?
Real Life Example
Recently we worked to use a new design language for a new feature. Originally, we were concerned about the experience this will create inside our product with legacy UI. We made some mockups and after some discussion, we realized we were playing it too safe. If we went too safely to “bridge” the two UI systems, we may be selling our new language short, which in turn sells our users short. Our concern has not gone away, but we are using our users to tell us where the line is instead.
I say go big, test and then reign it back if you need to.