Negotiation Tactics for Designers

Anchors Aweigh!

image: GummyBearOrgy

"How much do you expect to be paid?" A common question in a job interview. You'd like 60K, but would settle for 40K. Your current position pays 50K, but vacations are inflexible. This is a similar job, only with a better environment and prospects. What should you ask for?

This post is not about pay negotiations. It's about how to get enough time to create an outstanding good design. Specifically, it's about tactics to negotiate design effort during project scoping phase. These negotiation tactics lead directly to better products.

This post is about negotiation tactics to design better products.

If you do happen to be in pay negotiations, read on. We might still be able to get you some extra money. In any case, this post is intended to help you create products you want in your portfolio.

You should ask for the highest amount you think your prospective employer will reject without ending the discussion. Say, in this case, 70K.

Asking for the high amount means that your prospective employer's offers will be presented in terms of how much lower they are than what you are asking. The conversation will be on your terms. Rather than you trying to persuade your prospective employer to pay more, your prospective employer will be trying to persuade you to accept less to work with them. Research shows that, in this position, the final negotiated outcome is likely to be closer to 60K (what you want) than 40K (what you would accept).

Anchoring the discussion

The first concrete proposal on the table sets the frame of reference for the discussion. The phenomenon is called Anchoring.

You should not ask "how much are you willing to pay?" This would likely produce a number closer to your prospective employer's wishes than your own, and your counter-proposal would be compared to the employer's offer already on the table, i.e., it would seem comparatively high.

If your proposal is the first on the table, then your employer's offer seems low in comparison. The discussion then is more likely to be about justifying the employer's lower offer, rather than justifying your higher proposal. That's a much better position for you to be in.

Anchoring

a cognitive bias that describes the common human tendency to rely too heavily on the first piece of information offered (the "anchor") when making decisions.

In addition to setting the range of negotiation, Anchoring also sets the terms.

If, instead of responding with an expected pay amount, you answered the pay question with a request for 3 months annual vacation, you would change the nature of the discussion. Pay would become secondary, and the final negotiated result would most likely give you more vacation time.

Design Negotiations

Now consider the discussions around the planning and scoping of a new product development project. These discussions often start with a set of functional requirements for the proposed -- its job description. Based on these functional requirements, Development and Design estimate the required effort.

Although it makes sense to derive Development effort from functional requirements, it doesn't make sense to derive Design effort from functional requirements. When the starting point for the discussion is functional requirements, Design estimates inevitably seem a bit squishy, less concrete. The time estimate from Development becomes the reference point.

... a short development project soon fades from memory, but a badly-designed product stays around to haunt you.

In this situation, because of Anchoring, Design estimates are judged according to whether or not they add time to the estimate from Development. It almost seems logical to compromise on Design.

After all, if implementation isn't completed, you have nothing to show. Design seems less ...binary. You can skimp on Design and still get a functional product. So Design is compromised from the outset.

I have seen this happen plenty. It's a mistake. A poorly designed product is as much of a failure as a poorly implemented product -- and a lot more tragic.

The solution is a better Anchor. Design should come to the project scoping discussion with a concrete proposal. Design should present that proposal first.

The proposal should be a concrete representation of the kind of user experience the project should aim for. It shouldn't be a specification. At this point, the purpose is not to provide development requirements, but to anchor the scoping discussion.

Project scoping should center on user experience requirements, not just functional completeness.

You won't have time to prepare any considered design for the scoping discussion, and you shouldn't try, because you will anchor the discussion on the poorly-considered designs. The first proposal should take the form of demonstrations of the type or quality of experience you would like to achieve.

To scope a movie booking app, for example, you might show Flipboard. To scope a washing machine user interface, show Nest.

It's a negotiation move, like answering the job interview expected-salary question with your expectations regarding vacations. The first proposal is not a commitment, it's an anchoring device, setting the terms of reference for the rest of the project.

Almost any relevant concrete example will do, as long as it represents a high quality user experience. The examples may take the form of a prototype, sketches, images, existing products, etc; ...as long as it is concrete, and high quality.

In my organisation, new product development projects are preceded by a holistic exploration phase, like a Sprint Zero, which produce prototypes and concept designs that can anchor a subsequent development project.

Quality before Quantity

At the beginning of a new development project, during the scoping phase, Designers should present concrete examples of what the final user experience can be -- design references, not proposals. The examples should be the first thing Designers put on the table, and should be put on the table before development estimates. The purpose is to frame the project discussions around the experienced quality of the final project deliverable, rather simply than on functional completeness.

Because a short development project soon fades from memory, but a badly-designed product stays around to haunt you..

---

Thanks to my colleague Roy Averink for reviewing this article. In his opinion as a professional software project manager, the article is guilty of over-generalisation, but overall, he felt it was not all wrong, and in some cases might even be helpful.

Please share this post. If you comment, I'll reply. Thanks for reading!

---

If your interests extend to theory and philosophy, please check out my other blog.

---