May | 2010 | Danni's UX Lab 'Lucy'

Articulating design decisions

May 21, 2010

I just came back from the Amsterdam UX meetup where Tom Greever presented his new book Articulating design decisions. Tom explained some of the challenges you as designer face when selling your design ideas to stakeholders. He also mentioned some solutions on how to properly deal with feedback when you don’t agree with it, often diplomatically and respectfully.

Tom’s talk motivated me to polish up and publicise this post, finally. Thanks!

Disclaimer: this post is a combination of my (old) notes, thoughts and references.

Introduction

In this article I talk about about presenting your designs and how to get buy-in and convince your boss or client about a certain design.

Ultimately, stakeholders are interested in how to lift conversions (and other KPIs). There is countless data, research and evidence out there, but which will persuade your boss or client?

This article is relevant to any part of the process:

– analysis and research
– consulting
– presenting designs and recommendations
– designing deliverables (powerpoint, e-mail attachments, or other non-personal format)
– answering questions / giving advice or recommendations
– writing functional specificatons

How did you make your design decisions?

To quote Anne Holland’s words, most sites are designed by:

Owner’s gut
Pre-formatted templates
Copying competitors
‘Best practices’
Testing

The question is, which research and best practice, if any, can safely be re-applied to your particular project? And to which degree of confidence?

Evidence-based design

Here are some common research methods to back up your design decisions:

– Usability lab test
– Guerilla usability test
– Hallway testing
– Think-Aloud test
– Remote usability test
– Mobile usabilty test

– Eyetracking
– Card sorting
– Icon matching test

– Expert review (objective!)
– Usability heuristics

– A/B test
– Google Analytics
– MVT test

There is something to be said for all of these methods. In general, research can offer some insight or influence direction. However, it is not always welcomely received by all. The data from a lot of research is multi-interpretable, but not multi-applicable. Outcomes change with time and different cultures/countries. Statistics can be easily manipulated, as Edward Tufte has shown us. Hence we must resort to other means of persuasion.

Scale of persuasion

There are many methods and tactics to convince others about a design. What did you base your design decisions on? On the axis of true certainty, when it comes to communicating design decisions, where are you? Let’s rank some common methods/tactics from low to high confidence, where the highest confidence is “the plain truth”, this is what such a scale might look like:

1. Designer’s intuition (using cognitive walkthrough, from gut feel or experience) or genius design
2. Patterns (Styleguides, User Interface pattern library, iOS/Android UI guidelines)
3. Conventions (like competitor audits)
4. Best Practice or competitor audits or top sites (Often heard the boss/VP/CEO saying:”.. that’s how Apple/Facebook/Google do it!”)
5. Confidence. A lot of hard-headed talking (without pausing) makes it sounds you´re sure of yourself, which helps convince others about your ideas.
6. Research (slideshare by doctors or professors, advice from good-looking or well-rated blogs, or hard numbers from any official looking body of knowledge)
7. MVT and A/B split tests results and case studies

It’s number 5 we’re not all comfortable with. Luckily, good leaders know it’s not just about appearances or your voice that determines your success. Though it may initially help in convincing others of your design decisions, you should back up your design decision with true certainty.

Which of the above will resonate most with your boss?

Lastly, your tools and methods presentation need to be good. See my about ‘Convincing stakeholders’

Communicating design decisions

Sketching, storytelling, critiquing, presenting and facilitating. These are five indispensable skills any interaction designer (that deals with internal or clients discussions) should have. They are most useful in live discussions, brainstorming and workshops.

At other times the communication is not live. It´s by e-mail. Or if the above is not directly available or people are fully booked during business hours to listen to your design. Always ask yourself first if live presentating is better than sending deliverables. I sometimes like to use below methods as pre-work to explore design options and also to anticipate audience questions along the way.

You can either explore design alternatives, or get feedback using one of the following options. Let´s look at each option more closely. Decisions can be based on ….
– Assumptions – are my favourite and an important tool for freelancers or agency employees. Instead of bombarding the client with questions, make assumptions if you can’t quickly get in touch with real users for quality feedback. With the limited time you have, make some quick assumptions and deliver a design as quick as possible. Back it up with your own ‘assumed personas’ and do your own rapid user research (for example by skimming online discussion and support forums). Show that you did this if necessary.
– Assertions – Providing a rationale statement by adding the business reasoning and arguments for the design. For example: “This button will be orange. Rationale: Research has shown that orange buttons convert best.”
– Options – Explore if’s, if NOT’s, show alternatives but never more than 2 to 4. Give stakeholders a choice and ask questions to understand their arguments and context.
– Generalisations – audit, conventions, competitor analysis

– Questions – see Q&A below

Dealing with indecision

When requirements aren´t clear or complete, it is useful to communicate your decisions in the form of recommendations by providing or extending the requirements shows your confidence. If this is the case you can either ask for clarity, or if you have the feeling the requirements author doesn´t really know either, just start designing. It is common in many projects that design feeds requirements through a process of iteration . The last thing you want is to slow your design or getting the blame for delayed projects.

Indecisions and unknows are not desirable – they can hamper your design. In functional specifications, they could be indicated as:
– Open questions – a structured list (sometimes Excel) of outstanding issues that address unanswered design requirements. They can be complemented with:
– Questions (shows most uncertainty. Can be Q/A self-interview style, so your assumed answers are already there, making it easier for your reviewer to confirm). Sometimes open-ended questions work well, especially for sensitive issues (for example when asking about business values: “Our business gets most complaints about …”. See also the Business Assumptions sheet in Lean UX book [link])
– “TBD” or TBC – when clearly marked (e.g. in red) and indicated within a document or wireframe, may work if limited in amount. Downside is that may indicate the unwilligness/uncertainty of the designer to provide answers, even if in reality there are ´holes´not covered in the requirements specs and need to be answered with the help of a product owner.
– “Input needed from product owner” – like TBD, but clearly pushes the responsibility to the product owner. If you must resort to such measures, try to get the input beforehand.
– “(name of product owner)”, – shows reviewers (people likely to be involved or read the docs/see the design) clearly who is responsible and who needs to do the action to get things moving forwards and make work happen. For each action there is a person’s name and a clear divide of accountability.
– bunch of backlog post-its – it’s good to review these once in a while. Some issues are good to park, decisions to post-pone, and some solve themselves along the way while working on other stuff.

The goal is to avoid any indecision at all. Organise a workshop early on to get a group decision if needed. Making ideas happen is often about getting a decision out there, rather than making the best decision. Keep in mind, ideas are flexible and not set in stone.

From Concepting phase to Elaboration phase..

Ask questions – Q&A style

Another way to get decisions done is to ask yourself your own Q&A in an inverview style, as if you were interviewing a stakeholder. This shows a lot of confidence and is useful if you are picking up early signs of non-support.

For example:
Q: Why is this widget required?
A: Many users will be asked the same questions during check-out. The widget communicates and radiates importance, but not urgency, and is perceived as optional for those who know about its function.
Q: Will users use the widget?
A: The widget is prominent and dominant in visual design, and the most noticeable element on screen. The copy is inviting.

In some companies the UX designer is expected to chase the developers/product owners to get the answers. The culture then is more of a “If it ain´t clear, ask for clarity” approach. In other companies, especially those with less control or transparency or unclear processes, it is common for designers to postpone projects or getting designs done by ´blaming´the product owner for not providing enough answers (on time) or due to meager requirements specifications.

In many design projects, it can´t be avoided. Requirements feed design, but also vice-versa.

Some tips:
– Share. Honesty and frequent, good communication is the key.
– Involve. Regular sessions to communicate design decisions and blockers (learning from SCRUM).
– Ask for help. A project manager can help to chase people and keep things moving on. Get a single point of contact from the developers team.

The art of persuasion

What convinces your stakeholders?

Styleguides like those of Apple or Yale or others e.g. http://www.webstyleguide.com/wsg3/index.html
“Providing as much factual data as possible and 2) asking very direct and unemotional questions. For example, questions might be “How will the impact of this feature/interaction be measured?” or “Do you have data or studies to show that this would lead to the improvement you’re expecting?” Not all solutions can be data driven but if you have a set of key studies and research you are better off. “
“best practice … that starts with something like this: “There are no right or wrong ways to design a website or application. Over the last decade a lot of research and observation has been done to determine best practice. As the web is a fast evolving environment the research subject is a moving target and thus research tends to be very time and device specific.”
Present with confidence using psychology and sales person tactics
Speak their language – if they are used to data, costs and numbers (and graphs), use them as your convincing tools. Measure the effect (%) of your designs versus old designs if needed.

Verbal confidence

Zurb’s article talks about Designers at the table:

Talk lower. If her pitch is naturally on the higher side (like mine), the designer can practice talking at a lower one. She’ll instantly sound more confident, like magic.
Talk slower. It’s easy trip on words when the brain can’t keep up with the mouth. Slow down, pause between points. It’ll make the designer sound more thoughtful.
Don’t end statements on high note, like a question. It’s a super common mistake, and an easy one to curb by paying attention to the voice.
Don’t fill time by repeating a point twice. Instead of building confidence, it actually does the opposite. Repeating a statement makes the designer sound unsure, like she’s trying to convince everyone, including herself. It’s another mistake we often see (and personally struggle with). It takes a conscious effort to break this habit.

Breaking convention

You have this new idea, your own insight or innovative pattern that is trending in your design circles. Perhaps it’s placing the breadcrumb trail at the bottom of the page, or perhaps it’s even more zany. Yet, it breaks most convention. Should the initial design stay with conventions, or can you introduce this zany idea? After you have convinced yourself, can you convince your stakeholders?

Read my post about ‘Consistency’

Danni's UX Lab 'Lucy'