| How to Win Approval on Your Design Presentation | ||||
|
|
Authors: $author_name 
  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 AdvanceInclude all relevant documents including the specifications, executive summary, UX testing materials and, if possible, other requirements that 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:
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 of ?€œprogram manager,?€ or PM. 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 to a group of PMs and developers a significant change to current thinking or process, 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 HomeworkAre 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 RequirementsIf 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:
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 MeetingGo 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. AftermathDiscuss 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 TruthThis 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. Image courtesy of iStockphoto, Yuri Arcurs, Flickr, poolie More About: Business, design, mashable, web design For more Dev & Design coverage:
Read more: http://feeds.mashable.com/~r/Mashable/~3/yPVYjtBjrxw/ Comments (0)
 Write comment
|
Subscribe to this comment's feed
