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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
9. 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.

ABOUT THE AUTHOR(S)

View Profile

Not long after Steve Jobs got married, in 1991, he moved with his wife to a nineteen-thirties, Cotswolds-style house in old Palo Alto. Jobs always found it difficult to furnish the places where he lived. His previous house had only a mattress, a table, and chairs. He needed things to be perfect, and it took time to figure out what perfect was. This time, he had a wife and family in tow, but it made little difference. “We spoke about furniture in theory for eight years,” his wife, Laurene Powell, tells Walter Isaacson, in “Steve Jobs,” Isaacson’s enthralling new biography of the Apple founder. “We spent a lot of time asking ourselves, ‘What is the purpose of a sofa?’ ”

It was the choice of a washing machine, however, that proved most vexing. European washing machines, Jobs discovered, used less detergent and less water than their American counterparts, and were easier on the clothes. But they took twice as long to complete a washing cycle. What should the family do? As Jobs explained, “We spent some time in our family talking about what’s the trade-off we want to make. We ended up talking a lot about design, but also about the values of our family. Did we care most about getting our wash done in an hour versus an hour and a half? Or did we care most about our clothes feeling really soft and lasting longer? Did we care about using a quarter of the water? We spent about two weeks talking about this every night at the dinner table.”

Steve Jobs, Isaacson’s biography makes clear, was a complicated and exhausting man. “There are parts of his life and personality that are extremely messy, and that’s the truth,” Powell tells Isaacson. “You shouldn’t whitewash it.” Isaacson, to his credit, does not. He talks to everyone in Jobs’s career, meticulously recording conversations and encounters dating back twenty and thirty years. Jobs, we learn, was a bully. “He had the uncanny capacity to know exactly what your weak point is, know what will make you feel small, to make you cringe,” a friend of his tells Isaacson. Jobs gets his girlfriend pregnant, and then denies that the child is his. He parks in handicapped spaces. He screams at subordinates. He cries like a small child when he does not get his way. He gets stopped for driving a hundred miles an hour, honks angrily at the officer for taking too long to write up the ticket, and then resumes his journey at a hundred miles an hour. He sits in a restaurant and sends his food back three times. He arrives at his hotel suite in New York for press interviews and decides, at 10 P.M., that the piano needs to be repositioned, the strawberries are inadequate, and the flowers are all wrong: he wanted calla lilies. (When his public-relations assistant returns, at midnight, with the right flowers, he tells her that her suit is “disgusting.”) “Machines and robots were painted and repainted as he compulsively revised his color scheme,” Isaacson writes, of the factory Jobs built, after founding NeXT, in the late nineteen-eighties. “The walls were museum white, as they had been at the Macintosh factory, and there were $20,000 black leather chairs and a custom-made staircase. . . . He insisted that the machinery on the 165-foot assembly line be configured to move the circuit boards from right to left as they got built, so that the process would look better to visitors who watched from the viewing gallery.”

Isaacson begins with Jobs’s humble origins in Silicon Valley, the early triumph at Apple, and the humiliating ouster from the firm he created. He then charts the even greater triumphs at Pixar and at a resurgent Apple, when Jobs returns, in the late nineteen-nineties, and our natural expectation is that Jobs will emerge wiser and gentler from his tumultuous journey. He never does. In the hospital at the end of his life, he runs through sixty-seven nurses before he finds three he likes. “At one point, the pulmonologist tried to put a mask over his face when he was deeply sedated,” Isaacson writes:

Jobs ripped it off and mumbled that he hated the design and refused to wear it. Though barely able to speak, he ordered them to bring five different options for the mask and he would pick a design he liked. . . . He also hated the oxygen monitor they put on his finger. He told them it was ugly and too complex.

One of the great puzzles of the industrial revolution is why it began in England. Why not France, or Germany? Many reasons have been offered. Britain had plentiful supplies of coal, for instance. It had a good patent system in place. It had relatively high labor costs, which encouraged the search for labor-saving innovations. In an article published earlier this year, however, the economists Ralf Meisenzahl and Joel Mokyr focus on a different explanation: the role of Britain’s human-capital advantage—in particular, on a group they call “tweakers.” They believe that Britain dominated the industrial revolution because it had a far larger population of skilled engineers and artisans than its competitors: resourceful and creative men who took the signature inventions of the industrial age and tweaked them—refined and perfected them, and made them work.

In 1779, Samuel Crompton, a retiring genius from Lancashire, invented the spinning mule, which made possible the mechanization of cotton manufacture. Yet England’s real advantage was that it had Henry Stones, of Horwich, who added metal rollers to the mule; and James Hargreaves, of Tottington, who figured out how to smooth the acceleration and deceleration of the spinning wheel; and William Kelly, of Glasgow, who worked out how to add water power to the draw stroke; and John Kennedy, of Manchester, who adapted the wheel to turn out fine counts; and, finally, Richard Roberts, also of Manchester, a master of precision machine tooling—and the tweaker’s tweaker. He created the “automatic” spinning mule: an exacting, high-speed, reliable rethinking of Crompton’s original creation. Such men, the economists argue, provided the “micro inventions necessary to make macro inventions highly productive and remunerative.”

Was Steve Jobs a Samuel Crompton or was he a Richard Roberts? In the eulogies that followed Jobs’s death, last month, he was repeatedly referred to as a large-scale visionary and inventor. But Isaacson’s biography suggests that he was much more of a tweaker. He borrowed the characteristic features of the Macintosh—the mouse and the icons on the screen—from the engineers at Xerox PARC, after his famous visit there, in 1979. The first portable digital music players came out in 1996. Apple introduced the iPod, in 2001, because Jobs looked at the existing music players on the market and concluded that they “truly sucked.” Smart phones started coming out in the nineteen-nineties. Jobs introduced the iPhone in 2007, more than a decade later, because, Isaacson writes, “he had noticed something odd about the cell phones on the market: They all stank, just like portable music players used to.” The idea for the iPad came from an engineer at Microsoft, who was married to a friend of the Jobs family, and who invited Jobs to his fiftieth-birthday party. As Jobs tells Isaacson:

This guy badgered me about how Microsoft was going to completely change the world with this tablet PC software and eliminate all notebook computers, and Apple ought to license his Microsoft software. But he was doing the device all wrong. It had a stylus. As soon as you have a stylus, you’re dead. This dinner was like the tenth time he talked to me about it, and I was so sick of it that I came home and said, “Fuck this, let’s show him what a tablet can really be.”

Even within Apple, Jobs was known for taking credit for others’ ideas. Jonathan Ive, the designer behind the iMac, the iPod, and the iPhone, tells Isaacson, “He will go through a process of looking at my ideas and say, ‘That’s no good. That’s not very good. I like that one.’ And later I will be sitting in the audience and he will be talking about it as if it was his idea.”

Jobs’s sensibility was editorial, not inventive. His gift lay in taking what was in front of him—the tablet with stylus—and ruthlessly refining it. After looking at the first commercials for the iPad, he tracked down the copywriter, James Vincent, and told him, “Your commercials suck.”

“Well, what do you want?” Vincent shot back. “You’ve not been able to tell me what you want.”
“I don’t know,” Jobs said. “You have to bring me something new. Nothing you’ve shown me is even close.”
Vincent argued back and suddenly Jobs went ballistic. “He just started screaming at me,” Vincent recalled. Vincent could be volatile himself, and the volleys escalated.
When Vincent shouted, “You’ve got to tell me what you want,” Jobs shot back, “You’ve got to show me some stuff, and I’ll know it when I see it.”

I’ll know it when I see it. That was Jobs’s credo, and until he saw it his perfectionism kept him on edge. He looked at the title bars—the headers that run across the top of windows and documents—that his team of software developers had designed for the original Macintosh and decided he didn’t like them. He forced the developers to do another version, and then another, about twenty iterations in all, insisting on one tiny tweak after another, and when the developers protested that they had better things to do he shouted, “Can you imagine looking at that every day? It’s not just a little thing. It’s something we have to do right.”

The famous Apple “Think Different” campaign came from Jobs’s advertising team at TBWA\Chiat\Day. But it was Jobs who agonized over the slogan until it was right:

They debated the grammatical issue: If “different” was supposed to modify the verb “think,” it should be an adverb, as in “think differently.” But Jobs insisted that he wanted “different” to be used as a noun, as in “think victory” or “think beauty.” Also, it echoed colloquial use, as in “think big.” Jobs later explained, “We discussed whether it was correct before we ran it. It’s grammatical, if you think about what we’re trying to say. It’s not think the same, it’s think different. Think a little different, think a lot different, think different. ‘Think differently’ wouldn’t hit the meaning for me.”

The point of Meisenzahl and Mokyr’s argument is that this sort of tweaking is essential to progress. James Watt invented the modern steam engine, doubling the efficiency of the engines that had come before. But when the tweakers took over the efficiency of the steam engine swiftly quadrupled. Samuel Crompton was responsible for what Meisenzahl and Mokyr call “arguably the most productive invention” of the industrial revolution. But the key moment, in the history of the mule, came a few years later, when there was a strike of cotton workers. The mill owners were looking for a way to replace the workers with unskilled labor, and needed an automatic mule, which did not need to be controlled by the spinner. Who solved the problem? Not Crompton, an unambitious man who regretted only that public interest would not leave him to his seclusion, so that he might “earn undisturbed the fruits of his ingenuity and perseverance.” It was the tweaker’s tweaker, Richard Roberts, who saved the day, producing a prototype, in 1825, and then an even better solution in 1830. Before long, the number of spindles on a typical mule jumped from four hundred to a thousand. The visionary starts with a clean sheet of paper, and re-imagines the world. The tweaker inherits things as they are, and has to push and pull them toward some more nearly perfect solution. That is not a lesser task.

Jobs’s friend Larry Ellison, the founder of Oracle, had a private jet, and he designed its interior with a great deal of care. One day, Jobs decided that he wanted a private jet, too. He studied what Ellison had done. Then he set about to reproduce his friend’s design in its entirety—the same jet, the same reconfiguration, the same doors between the cabins. Actually, not in its entirety. Ellison’s jet “had a door between cabins with an open button and a close button,” Isaacson writes. “Jobs insisted that his have a single button that toggled. He didn’t like the polished stainless steel of the buttons, so he had them replaced with brushed metal ones.” Having hired Ellison’s designer, “pretty soon he was driving her crazy.” Of course he was. The great accomplishment of Jobs’s life is how effectively he put his idiosyncrasies—his petulance, his narcissism, and his rudeness—in the service of perfection. “I look at his airplane and mine,” Ellison says, “and everything he changed was better.”

The angriest Isaacson ever saw Steve Jobs was when the wave of Android phones appeared, running the operating system developed by Google. Jobs saw the Android handsets, with their touchscreens and their icons, as a copy of the iPhone. He decided to sue. As he tells Isaacson:

Our lawsuit is saying, “Google, you fucking ripped off the iPhone, wholesale ripped us off.” Grand theft. I will spend my last dying breath if I need to, and I will spend every penny of Apple’s $40 billion in the bank, to right this wrong. I’m going to destroy Android, because it’s a stolen product. I’m willing to go to thermonuclear war on this. They are scared to death, because they know they are guilty. Outside of Search, Google’s products—Android, Google Docs—are shit.

In the nineteen-eighties, Jobs reacted the same way when Microsoft came out with Windows. It used the same graphical user interface—icons and mouse—as the Macintosh. Jobs was outraged and summoned Gates from Seattle to Apple’s Silicon Valley headquarters. “They met in Jobs’s conference room, where Gates found himself surrounded by ten Apple employees who were eager to watch their boss assail him,” Isaacson writes.

“Jobs didn’t disappoint his troops. ‘You’re ripping us off!’ he shouted. ‘I trusted you, and now you’re stealing from us!’ ”

Gates looked back at Jobs calmly. Everyone knew where the windows and the icons came from. “Well, Steve,” Gates responded. “I think there’s more than one way of looking at it. I think it’s more like we both had this rich neighbor named Xerox and I broke into his house to steal the TV set and found out that you had already stolen it.”

Jobs was someone who took other people’s ideas and changed them. But he did not like it when the same thing was done to him. In his mind, what he did was special. Jobs persuaded the head of Pepsi-Cola, John Sculley, to join Apple as C.E.O., in 1983, by asking him, “Do you want to spend the rest of your life selling sugared water, or do you want a chance to change the world?” When Jobs approached Isaacson to write his biography, Isaacson first thought (“half jokingly”) that Jobs had noticed that his two previous books were on Benjamin Franklin and Albert Einstein, and that he “saw himself as the natural successor in that sequence.” The architecture of Apple software was always closed. Jobs did not want the iPhone and the iPod and the iPad to be opened up and fiddled with, because in his eyes they were perfect. The greatest tweaker of his generation did not care to be tweaked.

Perhaps this is why Bill Gates—of all Jobs’s contemporaries—gave him fits. Gates resisted the romance of perfectionism. Time and again, Isaacson repeatedly asks Jobs about Gates and Jobs cannot resist the gratuitous dig. “Bill is basically unimaginative,” Jobs tells Isaacson, “and has never invented anything, which I think is why he’s more comfortable now in philanthropy than technology. He just shamelessly ripped off other people’s ideas.”

After close to six hundred pages, the reader will recognize this as vintage Jobs: equal parts insightful, vicious, and delusional. It’s true that Gates is now more interested in trying to eradicate malaria than in overseeing the next iteration of Word. But this is not evidence of a lack of imagination. Philanthropy on the scale that Gates practices it represents imagination at its grandest. In contrast, Jobs’s vision, brilliant and perfect as it was, was narrow. He was a tweaker to the last, endlessly refining the same territory he had claimed as a young man.

As his life wound down, and cancer claimed his body, his great passion was designing Apple’s new, three-million-square-foot headquarters, in Cupertino. Jobs threw himself into the details. “Over and over he would come up with new concepts, sometimes entirely new shapes, and make them restart and provide more alternatives,” Isaacson writes. He was obsessed with glass, expanding on what he learned from the big panes in the Apple retail stores. “There would not be a straight piece of glass in the building,” Isaacson writes. “All would be curved and seamlessly joined. . . . The planned center courtyard was eight hundred feet across (more than three typical city blocks, or almost the length of three football fields), and he showed it to me with overlays indicating how it could surround St. Peter’s Square in Rome.” The architects wanted the windows to open. Jobs said no. He “had never liked the idea of people being able to open things. ‘That would just allow people to screw things up.’ ” ♦

LEARNING OBJECTIVES

1. Compare and contrast artwork using graphic design principles—contrast, repetition, alignment, proximity (C.R.A.P.)
2. Compare and contrast artwork using ad design principles (picture, headline, text, logo)
3. Compare and contrast artwork using type design principles (font, size, weight, color, form, direction)
4. Distinguish between layouts that conflict versus layouts that go well together
5. Categorize fonts based on visual inspection
6. Manipulate images and text to re-create a best practice advertisement in PowerPoint
7. Choose and successfully employ PowerPoint techniques to solve a complex task

Introduction

How much graphic design do you need in business? Considering the heavy emphasis that is currently placed on “the look” of deliverables, the answer might be a lot. We don’t pretend that you will become a master of graphic design after just one chapter. However, there are some survivor principles of graphic design laid out by Robin Williams. Those principles are contrast, repetition, alignment, and proximity (C.R.A.P.).

You will learn to see the world in a new way. For years, you have looked at magazine layouts, ads, banners, flyers, etc. Some have caught your eye and some have not. Unless you have been trained in graphic design, it would most likely be hard for you to vocalize what it is about a layout that appeals to you.

The principles of graphic design, ad design, and type design will be repeated throughout the text when designing the following deliverables:

• Ads
• Websites
• Resumes
• Term papers
• PowerPoint presentations
• Spreadsheets
• Graphs

Everything that you design in this course will have a professional feel to it. Our goal is to make your work indistinguishable from the work that appears in publications such as theNew York Times and the Wall Street Journal. Realizing that goal will also help make you a valuable contributor in the workforce. Others will value your work as professional, polished and communicative. You will also be able to give guidance to others on how to improve the look of their deliverables.

Robin Williams Robin Williams is the author of the Non-Designer’s Design Book. This is an essential reference used even in graphic design programs.

Where Are We in the Life Cycle?

Many information systems projects are conceived of in a life cycle that progresses in stages from analysis to implementation. The diagram below shows the stages that we touch in the current chapter:

Contrast

Contrast focuses our attention and should be used to highlight the most important points that the audience should take away. Designers should use colors, bold type, and size to distinguish parts of text or an image and create contrast. Contrast is used in all aspects of life. For example, jewelers usually display their diamond pieces on a background of black velvet to let the jewels stand out. The page you are reading uses headings to create contrast with the text.

Another way to create contrast is by using visual weight. You create a focal point and then lead the reader’s eye around the page. The main focal point is the picture. The next “heaviest” item on the page is the headline, followed by the date, followed by the logo, followed by the body text. The reader’s eye is led from one item to the next based on these “weights.” The greatest mistake that most students make in flyer design is to make all the text the same size as though it needed to be readable from 20 feet away. As long as the picture and headline capture interest, a reader will move in closer to read the rest of the flyer. Also, if every item is the same size then nothing stands out and it looks unprofessional. Variation of font sizes and weights is critical to focus attention.

When working with type, aim for a contrasting layout. Contrasting layouts create visual interest and energy. For example, when you wear clothes of contrasting colors, such as red on navy blue, the outfit can be quite eye catching. Our examples will follow the conventions Robin Williams sets out in her book.^[2]

The opposite of contrast is affinity. Layouts demonstrating affinity show subtle variations in color or brightness. The overall effect is pleasing, though not particularly remarkable. For example, a person wearing a dark suit with a dark tie would be wearing an outfit that shows affinity.

In type design, a layout showing affinity is best for formal documents, such as wedding and graduation invitations. For most other documents, use a contrasting style to make your documents really pop. However, tailor the contrast to suit the audience and the occasion for the document. For example, a business plan prepared for a bank should have less contrast than the layout of this text book. When in doubt, be conservative.

The one type of layout that you must avoid is a conflicting layout. In a conflicting layout the type is very similar but different. For example, never use two different serif fonts on the same page. Think of wearing an outfit that has two different shades of red that are very similar but different. The combination looks like a mistake—as though part of the outfit had faded in the wash. In the same manner two serif fonts side by side will look like a mistake. Fonts should be identical or very different.

The text on the next page is taken from The United States Declaration of Independence and demonstrates some type contrasting techniques. By increasing the font size and changing the text color, you can highlight certain words or information that you want to stand out. The goal is to make “Creator” stand out as the most important word in the sentence. You can also boldface to dramatize the weight of the text or italicize to accent the text. Direction refers to adding space between letters to make text stand out. Structure, using serif or sans serif fonts, can also differentiate text and will be discussed in the next section.

The two main categories of font are serif and sans serif. Serifs are the ornamental strokes at the end of the letters, which all serif fonts have. Sans serif means without serifs, therefore sans serif fonts do not have these decorative additions.

Serif and sans serif fonts can be used together to create contrast within text. Typically sans serif fonts are used for headings while serif fonts are used for body text.

Note that you should avoid combining two fonts that are from the same category. For example, two serif fonts that look similar, such as Georgia and Garamond, should not be used together.

Serif fonts are best used in text heavy books because the serifs quickly guide the reader’s eye from letter to letter. Sans serif fonts are the best choice for online text because serifs can blur in the pixels on a screen. The resolution of most computer screens is not sufficient to precisely draw the serifs in a body of text. The result tends to look blurry. Therefore, most websites use a sans serif font. An exception is sometimes made for the page title, which because of its greater font size, can show serifs much more clearly. To allow for serifs online, Microsoft developed a series of ClearType fonts designed to accurately reproduce serifs.

Though font options are limited online, other techniques such as size, weight, color, form, and direction can be used to create contrast within online material. Color is especially powerful on a website as most viewers have a color monitor.

Please see the Appendix for additional font categories. These include slab serif, modern, script, and decorative.

A fill is the color, gradient, or pattern the occupies the inside of a drawn object. An outline is the color, gradient, or pattern that borders the drawn object. PowerPoint has extensive fill and outline options.

Repetition ties objects or images together. For instance, we know which football players are on a team because of the repetition of their uniforms. This text uses repetition of fonts, styles, and sizes to unify the design. On the facing page, repetition of graphic elements draws an image together.

Adobe has a wonderful free web-based application called Kuler, which helps you choose a color palette. One of its most spectacular features is the ability to upload an image and have Kuler automatically generate a color palette from that image. You then use that palette for fonts, fills, and so forth in your composition, and you are virtually guaranteed that the colors will all work well together.

To use the more interesting features of Kuler you must first create an account at:kuler.adobe.com. Now you can save your color palettes. Once saved, you can reveal the numerical values that correspond to your color palette. These numeric values may be imported into PowerPoint (under custom color).

Alignment indicates organization, polish, and strength. Text on a page is easier to read and understand if it is properly aligned to the margin. Alignment should be applied to every design or page layout to show order. Alignment on this page is created by left aligning all of the text and graphics.

Proximity creates relationships within objects in an image. Placing objects close together shows their connectedness and focuses the audience’s attention. For example, captions placed near photos on a page layout show that they describe the photos they are near. The page you are reading places headings next to the text they introduce to signify their relationship.

Graphic design is perhaps the most creative aspect of information design. Though design leaves room for originality, there are clearly articulated principles every designer should follow to create clear and effective images. We will adopt four basic principles outlined by Robin Williams. These principles that have been introduced in the previous pages are: contrast, repetition, alignment, and proximity (C.R.A.P.).

Mastering these principles will allow you to produce clear documents and make presentations look more professional. The business cards on the next page demonstrate good and bad examples of each design principle. Please study these principles as they will appear again and again throughout this text.

Dion Hinchcliffe has been working for two decades with leading-edge methods to accelerate project schedules and raise the bar for software quality.

According to Britain’s National Air Traffic Services (NATS), more than half the planes landing at London’s Heathrow airport are stuck in circles overhead — often for 20 minutes at a time — as they wait for its congested runways to clear.