A Good-Better-Best Framework for Design
The long term relationship between a design team and it’s client has everything to do with what the design team delivers and when. Setting clear expectations about the quality and completeness of the design work keeps both the design team and the client from changing the expectations without thoughtful discussions together. Simply articulating early in the development process, what good, better, and best solutions look like can make all the difference in what is delivered and in the long term relationship.
*****
Yesterday I had a very interesting meeting with some brilliant people from different disciplines. This was a contract meeting where two parties were trying to negotiate design-related outcomes and development funding. One of the parties was the design team and the other party was funding the design work and therefore represented the client stakeholder for the project.
In preparation for the meeting, the design team prepared a set of design milestones, that would be the basis for negotiation during the meeting. In the meeting, the design team presented their milestones and both parties sought agreement relative to the milestones the money that would be spent reaching them.
This is where we ran into trouble.
The design team came to the table with a few milestones that described what the design would look like at various points during the development process.
It became really clear to the funders that the design team described their milestones in a binary way. For example, the team said “for milestone 3, we will have a working physical prototype and an app for the app store. For milestone 4 we will have external investment and our first sales.”
The difficulty that the funders had was this: There was no doubt that the team could have a working prototype and an app. The doubt was if the working prototype would work well enough, and if the app for the app store would be good enough. In the team’s milestone description, to have a working prototype and an app for the app store, there was no description as to how good or better or best that prototype might be. And there was no indication about if the app for the app store would be one that everyone in the negotiation could be proud of, some people would be proud of, or no one would be proud of.
Now the point here is that the team can have an app for the app store – but there are a lot of apps on the app store that have no value – and the team can have a working prototype though it may not work well, even though it’s working.
This lack of describing to what extent the design team hoped to achieve the design milestones was the source of notable trouble during the contract negotiation.
Some Tips
Whenever faced with this situation – and many of you have been or will be faced with it – it is a good idea to describe in vivid terms what a good solution looks like, what a better solution looks like, and what a best solution looks like. These vivid descriptions don’t need to be long, they could be just a few sentences, and although quantitative measures can help, they are not necessary here. A qualitative vivid description can work really well when thoughtfully done.
There are three reasons why a good-better-best framework can be powerful when attempting to negotiate design work.
1. It’s too easy in a design setting, where the future is envisioned, but unknown, for the different parties in the contract negotiation to envision different things. This happens all the time with bosses and employees, parents and children, and in my situation yesterday between a design team and its funders. The more those parties can come into alignment about what the envisioned future is, the better. Importantly, it is at the contract negotiation stage that we start to paint the picture about what the future looks like, and we start to establish practices amongst the negotiating parties as to whether the mode of communication will create confusion or clarity. For the design team whose milestones include a working prototype, an app for the app store, external investment, and sales, recognize that all of these milestone can be interpreted very differently.
2. Experienced designers will know that as we proceed through the development process multiple moments are encountered when there is so much up in the air, and so much uncertainty about the project, that it can be easy to lose track of what the end goal looks like. In those moments of high stress and uncertainty it is so easy to say (with no malicious intent) we have a working prototype – it’s not very good – but it works, so we’ve completed this part of milestone 3. Same thing with the app; we have an app – no one likes it – but we said we would have an app, so we’re just going to launch it so we can complete milestone 3. No one wants to do that no one plans to do that, but this is what can happen when the stress is high and it’s hard to see the forest through the trees. Same thing with milestone 4. We sold some; yeah we sold some to our moms. And we got external investment; I got a loan from the bank. This is not what we meant when we said we would have sales and external investment by milestone 4, though it’s easy to believe things are ok because we checked off the box.
3. The third reason why having vivid descriptions of good, better, and best are so important is that inevitably during the development process the design team and the funders will have to give up some of the things they originally envisioned. This is natural, and I believe it is good to envision something slightly beyond what can be reached, then tone it down during the process. In that process of toning it down, it is very helpful to have a sense for which things can be traded off. Having a vivid description of good, better, and best for the top 3 or 4 objectives and knowing which of those can drop from best to better, or all the way down to good and still be good enough, and also knowing which are most important and need to be best, will greatly reduce frustration during the development process.
In that interesting meeting yesterday, I saw a design team with a binary description of what would be accomplished, and funders wanting more than that before releasing funds. What made the meeting so interesting was that the funders had a hard time articulating why they were unsatisfied, and the design team had a hard time seeing why a binary description was not enough.
In essence, the design team’s binary descriptions resulted in a checklist, that defined the boundary of solution acceptability. If they can check off all the boxes, they will have something acceptable, if they can’t their solution is unacceptable.
When the design team approached the funders to negotiate to simply be within the bounds of acceptability by checking off all the necessary boxes, the funding party said “no, while we can agree that we should be in the bounds of acceptability, the contract can’t be approved with that alone, the contract needs to articulate what good, better, and best solutions look like within the set of acceptable solutions.” Without that, the team and the funders will likely be unaligned in their vision of the future, frustrated with each other in the end, and without a product ready for delivery.
