One of the most common misconceptions about director/architect-level designers is they do less work (produce fewer wireframes, specifications, etc.) than junior-level designers. In fact, their work is more complex than people initially imagine when starting out in the field. You have to balance many ideas, requirements, and people, and have to make independent decisions that will cost thousands, if not hundreds of thousands, of dollars. The buck stops with you. This is a level of responsibility you have to endure, if not enjoy, to thrive in higher-level design.
When I was an entry-level designer, I would be handed various interaction design problems and asked for a solution. I would then present three or four solutions to my immediate managers and be done until the next such request. I was always curious what happened after I handed it off. I came to realize that there were several more handoffs, each getting more precise and more fierce as it moved up the chain of command. Different teams would have to get involved, then team leaders, then finally stakeholders, each giving opinions on changes, personal ideas, and ways to try and cut costs. The balancing act that you must do for that is beyond the scope of this article, but I will try to help you deliver the best possible solution you can.
This article is an overview of how to deliver completed designs to other teams or stakeholders in the highest levels of design. I am not going to explain details of design process, because you likely have one of your own, your team’s, or your company’s. I’ll specifically tackle how to walk into a large meeting to present deliverables and get the best reception possible.
I should also add that my experience is with large corporations, such as Microsoft and Apple. How I present ideas to colleagues may be very different than how a vendor or a design agency would present an idea. My strategies for delivering designs are meant to influence a set of peers to maintain the best possible experience for the user. Your focus should be entirely on what’s best for the customer.
Share Documents in Advance
Include all relevant documents including the specifications, executive summary, UX testing materials and, if possible, other requirements stakeholders have given you. If they want to read before the meeting, you should facilitate that in every manner possible. Air out your dirty laundry, include links to past specs and meeting notes if applicable.
The importance of this step is to help them prepare for the meeting. It’s bad form or just bad judgment to introduce a new idea or direction in a large meeting without proper warning. The initial kneejerk reaction will most likely be negative. Resistance to change is inherent. It’s better to give them as much preparation material as possible to facilitate a speedier meeting. You’ll be able to presume understanding of the concepts or reference the materials you have sent out during the meeting with more confidence. I like to include past UX testing findings with notations. This lets me speak directly about the customers’ needs when discussing solutions: “As you can see, six out of seven customers were searching for a way to do X. This pushed us to design a solution for X.” Also remember at the beginning of the meeting to make sure everyone got the materials and to ask if anyone had any questions.
Some examples of documents that I have given out prior to meetings:
- UX findings, executive-level summaries (2-3 sentences discussing results of an entire testing round)
- Excerpts from books describing certain design ideas or thoughts (one in particular I have given out several times is Barry Schwartz’s The Paradox of Choice)
- Links to or wireframes of past designs and findings, or conclusions gotten from those designs
- Links to TED talks (Barry Schwartz gives a great one)
- HTML/Flash/WPF prototypes in a ZIP so they can play with them before they see them in your presentation
- Sketches or drawings of past designs
- Links to specific points in videos of UX Testing for particular quotes
Know Your Colleagues
Be familiar with each of the personalities in the room, and why are each of them has been invited to the presentation. Determine the roles of each member and make a mental note of the history your design team has had with them. Try to anticipate what each person might challenge you with. Think through questions that each may ask and try to determine if there will be any “gotcha” moments beforehand.
At Microsoft, from my recollection, approximately 50% of the employees have a title that’s some variation on “program manager.” This is a very general job title and can represent so many different types of roles. The PMs I usually came into contact with were software PMs whose job is to watch the money. They keep track of the timelines, the budget, and generally keep an eye on all the different teams working on a particular feature set. They ensure everyone is working as hard as they can and that we finish on time and on budget.
When presenting a significant change to current thinking or process to a group of PMs and developers, the reactions will be varied. Many things are on the minds of the participants, including timeline, amount of code, impact on the customer, impact of the footprint (memory or cycles), etc. The developers may invite the challenge of trying to come up with something ingenious to solve the problem of developing your solution, but the PMs may want to keep resource utilization to a minimum. Conversely, the developers might not want to get that deep into the code for something they see as arbitrary and unnecessary because it will have a low customer impact, while the PMs push for more “wow” moments. This is why it’s important to understand where each of the meeting participants is coming from. If one of the PMs is constantly fretting about deadlines, be prepared to speak directly to how your designs will actually affect the deadline.
Do Your Homework
Are there any academic papers relevant to your designs? Have you checked ACM? Developers and PMs react positively to peer-reviewed academic papers given as support for design decisions. Being able to cite testing results or give specific examples from an academic paper is worth its weight in gold.
It’s also worth investigating whether there is any company history that might bear on your work if this is an ongoing version of a product with significant development history. Has this particular solution been tried before and failed? If it did fail, be prepared to speak to that history and how your solution is different and an improvement. Be specific. Have all raw notes, summaries, and findings from user testing ready to go. Be prepared to deep dive into the results as much as you need to be. Be able to cite specific testing answers if need be; more times than not, it’s very useful. I have found that when PMs or developers don’t want to do a particular piece of a design—perhaps because of the number of hours it will take or its perceived risk to the stability of the build—they will hammer it incessantly, challenging the thought process, the reasoning, or the design process. These concerns are easier to respond to when you have user testing results ready at hand, and have organized them in a way that anticipates how you might need to use them to respond to concerns.
When you start designing a particular feature or add-on to a product, remember that you are not the first. There should be a massive amount of documentation on why the designers got to the point you are at now. If you were designing for Microsoft Office Help, for example, you would not expect to go in fresh. There is a massive amount of documentation, designs, test results, and other political/corporate decisions that went into where it lies.
Before presenting some new and interesting feature or add-on, always make sure that you have researched the history behind it first. Talk to some of the senior people; do they have any recollection of that particular feature ever being introduced? Can they recall any unwritten corporate decisions, legal problems, or technical issues that led to its currently not being implemented? Research the idea or feature to the best of your ability to help prepare yourself for speaking to why it should be implemented now if it wasn’t in the past.
Understand the Technical and Engineering Requirements
If you don’t quite understand why engineers cannot implement a particular requirement, ask questions. Generally, you will find a dev or two who loves helping with and learning about design. It is very helpful to have an ally in the development team, someone you can confer with, bounce ideas off of, or get good development advice from. In my experience, there is always at least one developer who is more design savvy than a normal developer. Relationships with this type of person are invaluable in the design process. Feed your designs to your design-savvy developer for feedback on the complexity of implementing the designs how it would affect the product technically.
Be friendly with developers. They are not your enemy (most of the time). Developers are fearful of designers’ ability to create thousands of lines of code with a simple sketch. So instead of approaching your design work simply from a designer’s standpoint, approach it as someone who would also have to build it. Whatever you get approved, someone is going to have to labor over to actually implement.
Be precise and be exact if your aim is to get full sign-off on a design. If you don’t get this detailed in your review, expect to have to do another review when you do. Do not go into a meeting and describe a “slow animation that sweeps from the left;” do go into a meeting and say, “The animation begins and lasts for 0.3 seconds, and here are four slides, from 0 to 0.1 to 0.2 to 0.3 and the resting state at 0.4.” But even this isn’t enough. Make sure you have talked to a developer first to see if this can even be implemented in the manner that you want it to be.
Understand the overall system ramifications of your design are beyond the scope of this article, but I would suggest you gain a familiarity with all the workings of your particular application or solution have on whatever system it may be running on. This includes, but it not limited to, the variables that are changing hands, the memory load, the machine cycles, the net connections, etc. Try to understand as much as you possibly can before asking the next level of stakeholders. What is the effect on the rest of the application or experience? You don’t want the entire experience to pay a tax (in whatever machination that may come in the form of) for a small feature that it shouldn’t have to pay.
Conducting the Meeting
At the start of the meeting, explain the goals for the meeting and what you want everyone to get from it. What you’d ideally like is universal buy-in and strong approval for your design so it can get sent to production, but if you don’t get that, don’t freak out. If you do get rejected, try to understand everything you can about why you got rejected. What were the specific points that supported their criticism? Can you fix them? Take critique well. Remember that arriving at a solution is not easy, especially when you’re working with larger and more complex systems. You may get approval for 90% of the design, but stakeholders might request tweaks or different variations on particular details. This is the easy part. Tweak or do these variations in quantity—three or four of each—and present them to a smaller audience, sometimes only the dissenters. This should help you get to the next level. Iteration is part of the process. I have personally gone through 8-10 design iterations on a particular feature before I finally got approval. Don’t think of it as 20% rejection, think of it as 80% approval!
Some additional tips for running the presentation:
- Try to keep questions until the end of the presentation, remembering to leave ample time for questions and challenges. Depending on how radical, new, or complex your solution is, be prepared to spend a larger portion of the meeting receiving and responding to feedback.
- If you get challenged, ask questions. Try to understand exactly what they are saying and understand their reasoning. Also try to make sure everyone else in the room understands it. This is very important if you need to explain the challenge to your team after the meeting.
- Answer direct questions directly. If you do not know the answer, say, “I’ll find out and get back to you.” Then get back to them with an answer soon after the meeting.
- Answer direct challenges directly with all relevant documentation. If you don’t have it, do not try to persuade them with vague answers. Tell them what you have, why you made the decision, and let it stand on its own two feet. Do not get defensive beyond reason. If something is challenged, explain how you got there and let it rest. Do not repeat yourself (this is rule #1, as repeating yourself will make others feel talked-down to). Do not defend the solution like it is you personally. Do not fumble for answers. If you can’t answer the challenge directly, respond with “I’ll find out for you.” Letting feedback get to you personally is unprofessional. You are not an artist delivering a masterpiece.
- You may encounter unreasonable challenges and you can get “edge-cased to death,” which is what I call it when people try to kill things with the most unreasonable of problems. I also call this the “one-armed man in Uganda” challenge. I actually had someone bring up a one-armed man in Uganda as a possible customer and therefore we needed to think of him when designing a solution. This can be extremely frustrating, but if you have critically thought-out your design beforehand, you will be prepared.
- Though you may feel you have answered someone’s question or challenge completely, ask the person if he feels you’ve completely answered his question. Just because you think it answered it does not mean you have.
- Be transparent about the entire process you took getting to the design. Have slides ready showing testing subjects, iterations, sketches, and any other materials that you may have collected along the way.
- Address problems with the design honestly. Be transparent about all the things that have given you headaches over the course of the project. Helping people understand the journey you’ve been on helps them respect the destination all the more.
- Talk about the user or the customer directly. Your job is to ensure the user has a great experience, not to make the developers happy. As you move up the ladder of stakeholders, you will find a common trait: they all care what customers think. Speaking directly to how designs affect customers will keep the conversation rooted in your sole purpose, to make the customer happy on all levels.
Always remember to do what is best for the user. You aren’t there to make your colleagues happy or sad. In the end, you all have the same goal. You all want to make the customers happy and create a piece of software that you are proud of. This can be one of the hardest parts of working in the UX field. Trying to be a voice for the user’s point of view in decision-making. Senior colleagues will all have their own ideas what is best, so use the user’s perspective as an objective frame of reference for responding to them. Don’t explain things in terms of your own opinion; rather, speak in terms of the user. Don’t say, “I picked this because it was a cool design;” instead say, “We chose this design because it tested amazingly well with current/future/target customers.”
Closing the Meeting
Go over what you have agreed upon and ensure it’s clear. Give action items with dates to everyone who needs them. If someone assigns you an action item but says they need to find something first, call that out; if they don’t find that something, you shouldn’t be responsible for the action item. Schedule meetings immediately following other dates and action items. Your job is to get this through to production. Your job is not complete until it is.
Aftermath
Discuss the meeting with teammates who were not available to attend. When discussing challenges that were brought up, give them the best representation possible rather than being dismissive of them or making straw men of opposing arguments.
An Unspoken Truth
This piece of advice I have saved for the end is generally not talked about in senior level/corporate design circles, but it I think one of the most crucial aspects of getting approval for a design. I think it was best said by a very respected designer and dear friend of mine (who shall remain nameless): “The best way to get a design approved is to let them think it’s their idea.”
I cannot emphasize this enough. By leaving strategic holes in your design and allowing others to come up with conclusions or obvious fillers, it reinforces their own personal stake in the design. This will get them personally involved in the approval process as one of your biggest advocates, since they’ll equate defense of your ideas with defense of their own. This whole idea is rather sketchy, so use it with caution. You will be giving up some ownership of your design, but in the end remember your goal is to make the best experience for the user. It’s about them, not us.
