• By Everett McKay on November 24th, 2013
  • UX design for entrepreneurs

Design Hacking: Great UX without time, money, or design skills

IgnitersOn November 14, I presented Design Hacking: Great UX without time, money, or design skills to the Igniters: Stanford Entrepreneurs and Silicon Valley Founders group at Hacker Dojo in Mountain View, CA. I would like to thank Raj Lal, Cynthia Lee, and Wendy Soon of Vorkspace for inviting me and making this event happen. I had a great time, made some excellent contacts, and received a lot of encouraging feedback.

Design Hacking at Hacker Dojo. Apparently you are supposed to photobomb from the back.

Download the deck for Design Hacking: A Great UX without time, money, or design talent (8 MB)
Plus links to the event, Wendy’s blog notes, and photos.

A tall order—but doable

Obviously this topic is a tall order—is this goal even remotely realistic? I think so, but you have to believe three fundamental ideas:

  • We waste a lot of time and money on UX design now. Non-designers waste an enormous amount of time creating hard-to-use UIs because they don’t know what they are doing. Experienced designers often waste an enormous amount of time because traditional user-centered design processes are overly dependent upon user research, user testing, and lots of iteration.
  • We don’t leverage what we know. Generally, we know a great deal about our target users—we’re just so focused on what we don’t know that we don’t even realize what we do know. There are basic attributes that all users share that we can take advantage of and use to avoid wasting time.
  • The best is the enemy of the good. You need to make solid design decisions quickly and confidently—even if they aren’t ideal. As an entrepreneur, you don’t have luxury of making perfect decisions with the ideal design process. So, let’s define a “great UX” is one that provides value, and is simple, easy to use, and intuitive for its target users. If we nail those, any shortcomings can be addressed later.

What we need is a perspective to help us make better design decisions more quickly and confidently. Not only does such a perspective exist, but as you will soon see it is one that we already know!

Failing fast…or just plain failing

Traditional user-centered methods require user research, requirements gathering, sketching, prototyping, user testing, and lots and lots of iteration. But there are several challenges, especially if you are in a hurry:

  • User research Frankly, the typical result of most user research is to discover that users haven’t a clue what they want. Or worse—users think they know what they want but really don’t. There’s an old saying: listen to your users, but ignore what they say. What this really means: you have to ask the right questions and interpret the answers. Users aren’t designers, so we can’t expect them to design their own UIs. Good user research takes a long time and is hard do to well.
  • Requirements Gathering requirements works well if they really are requirements. Often requirements are arbitrary, ill-conceived stealth UI specs. The resulting UI might not work well, but at least it meets its acceptance criteria.
  • Sketching Sketching is a great technique during ideation to suggest and explore different design directions. What I see most teams do, however, feels more of what I call “sketching a pile of features,” where the focus is on variations of physical placement of features on the page. This approach can work, but great UX requires going beyond features and layout.
  • User testing User testing is the heart of user-centered design, but I have seen a lot of testing of poor designs that just weren’t test-worthy. A common question determined by user testing: Will users figure out this non-standard, hard to find, poorly explained interaction with poor feedback that doesn’t meet their expectations. We should already know the answer. It’s “no.” No testing required. Often, if you have to ask, you already know the answer.
  • Iteration Iteration is great if it leads to rapid progress towards your goals, instead of just flailing around. When playing golf, I never shank the ball into the weeds and think “Yay! I’m iterating!” A lot of initial UI designs are like shank shots, and the subsequent iterations are slightly improved shank shots. Polishing a poor initial UX isn’t going to get us where we need to be. That first shot needs to be good for iteration to be effective.

These are all sound design techniques, but they take a lot of time and great design is hardly guaranteed.

From what I can tell, agile and lean UX techniques don’t help much here either. They still take a lot of time and money—often with mediocre results, especially for larger, more complex projects. The main difference is that you’ll know your UX sucks much, much faster. [Disagree? Please provide counter examples in the comments.]

The traditional approach favored by developers, which often boils down to putting raw the data structures required by the back end on the screen, doesn’t work at all. Find out why in Don’t design like a programmer.

Reality check

Don’t believe me? Let’s take a look at a well-known UI that is currently in the news.

How many HealthCare.gov’s Account Setup usability problems should have been obvious? All of them!

Nielsen Norman Group did a guidelines review of HealthCare.gov’s Account Setup step. Here is a sample of the guideline violations they found:

  1. Allow users to see the product/information before registering.
  2. Keep calls to action (CTAs) and other pertinent information above the fold.
  3. Use email address as username.
  4. Simplify password requirements.
  5. Provide specific and actionable error messages.
  6. Display passwords as users type them.
  7. Remove unnecessary steps.

There are no surprises here—the designers should have known that these would be issues. Lots of time and money wasted here. My bet: this UI wasn’t designed as much as it was specified based on arbitrary, ill-conceived requirements. Usability wasn’t much of a concern but acceptance testing was. [Am I wrong? Please let me know in the comments.]

What we (should) already know

To design great UX without money, time, or design skills, we need to leverage what we already know. If you were to ask a group of people why UX design is so hard (which I routinely do), invariably they will agree that one of the biggest challenges is that we don’t understand our users well enough.

This is certainly true. But if this were the root cause of poor design, I would expect to see many UIs that are well designed, just for the wrong target audience. In practice, I never see that. Instead, what I see is UIs that are poorly designed for everyone. It’s doesn’t matter who you are or what you are doing—they’re poorly designed.

Of course, it’s true that different users have different knowledge, motivation, preferences, workflows, etc. But there are many attributes that we can safely assume that all users have that we usually don’t even consider. I have compiled dozens of these and put the top 50 in UI is Communication.

But to keep things simple, let’s start with one user attribute that every UX designer should know:

Unless they have been trained or have prior experience, users only know what your program tells them.

I believe the real root cause of most poor UI is a failure to communicate to its users. Well-designed UIs are self-explanatory, and shouldn’t require trial-and-error, a user’s manual, help, or training to use.
Most user’s manuals explain how the UI should have been designed in the first place.

UI is Communication

A user interface is essentially a conversation between users and technology to do tasks that achieve users’ goals. A UI is a form of human communication, and if it communicates well it will be naturally intuitive. My UI is Communication book explores UI design from this point of view, and I will explain this concept in detail in a future blog post.

But to get started, a great way to design UI is to think about how you would explain a task to a target user in person. Think about the steps, their order, the language you would use, and the details that what you would bother to explain. Also think about what you wouldn’t say—those unnecessary steps or details you know the target users just don’t care about.

That conversation is a high-level guide to what your design should look like—great UIs feel like a natural, friendly conversation. But to be clear, I’m not saying the UI should be a literal conversation—that might be tedious—rather it should feel like a human conversation in terms of the steps, order, and communication. And it should never be chatty—applying this process usually results in less text, but much better text.

If there is a difference between what we say in person and what we say in UI, usually it is the human conversation that is right and the UI that is wrong. We naturally explain things in person in a way that the target users will understand. Great UIs should mirror human conversations because that is the most effective way to explain things.

At this point, I’m sure that you would like to see some examples. If so, please check out the Look Inside feature on Amazon. There is a very generous preview with many examples to get you going.

Putting it all together

Now let’s cut to the chase! Here is a communication-focused design process that requires a minimum of time, money, and design skills.

Most of this process is fairly traditional. The main difference is that we are using our understanding of the target users and top scenarios to determine how to communicate the tasks effectively on a human level. Scenarios and communication drive the process. At best, traditional design processes discover that communication accidentally. Instead of focusing on a mechanical solution and hoping to stumble across a usable human solution, let’s flip that and start with an intuitive, human solution and make it work mechanically. And save a whole lot of time and money by doing so.


  • Define your target users (hours)
    • Determine all the facts and assumptions about your target users, and make sure you have the right market.
    • For more information, check Personas: Dead yet?
  • Define your product’s value proposition (hours)
    • Determine what will motivate your target users to buy and use your product.
    • Merely solving a problem is a weak value proposition. Instead, you need a solution that provides real value—one that’s worth the trouble.
  • Determine your top scenarios (hours)
    • A good scenario describes a specific target user with a specific task or goal, in a specific context or environment, but without specifying a solution.
    • More simply: Who, what, when, where, and why…but not how.
    • For more information, check Design scenarios—and how thrilled users ruin them.
  • Reality check with real users (days)
    • Make sure you have these decision making tools right before proceeding.


  • Hire a good professional visual designer—one that you can trust (days)
    • The process outlined here will get us a long way in the interaction design, but we’ll need help with the visual design.
    • Let’s not pretend that non-designers can do the visual design. We can’t! (And trust me, it’s obvious!)
  • For each top scenario, design the human “conversation” (hours)
    • Determine how would you explain the task to the target user in person.
    • Determine a simple, familiar, efficient task flow that mirrors that conversation.
    • Analyze, optimize, simplify to get it right.
  • Use the conversation to design the pages (days)
    • Does the page communicate well and mirror what you would say in person? Does it have integrity—does everything need to be there?
    • For more information, check Effective Prototyping.

Some evaluation techniques to consider:

  • Scenario-based reviews (hours)
    • Use the top scenarios to help you evaluate the design from the users’ point of view.
    • Are those top scenarios easy to perform? Are the underlying user goals achieved?
    • The traditional “look at a screen and throw spears at it” approach doesn’t work well.
  • Communication reviews (hours)
    • Have someone explain the design and carefully listen to the explanation. Can you find any differences?
    • If so, explore why. If there are differences, most likely the in-person explanation is right and the UI is wrong.
  • Value proposition reviews (hours)
    • What is going to motivate users to use the product?
    • Are the benefits maximized, the costs minimized? Is its value immediately obvious?
  • Intuitive reviews  (hours)
    • Review the attributes required for an interaction to be intuitive.
    • Any missing attributes will be a problem unless the interaction is advanced, infrequent, or optional.
    • For more information, check Intuitive UI: What the heck is it?
  • Reality check with user reviews, preferably with paper prototypes (days)
    • Perform informal usability studies by giving target users important tasks and seeing if they can perform them successfully.
    • You can use paper prototypes for this. Functional prototypes are usually too expensive to create and result in too much commitment in the current design.
    • For more information, check How do you know when a design is done?

I put a rough time estimate for each of these steps (in parentheses) to back up the “without time” claim. While designing all the pages and doing some user-based reality checking will take days, most of the remaining steps can be done in a matter of hours for simple projects.

UX Design Essentials for Entrepreneurs

For the sake of brevity, I glossed over several important design techniques that I mentioned here, but they are all covered in detail in my UX Design Essentials class. My next UX Design Essentials in San Francisco (San Mateo, actually) will be on April 23 – 25. You can register now without payment.

While I believe that UX Design Essentials is at least 90% relevant to entrepreneurs with extremely limited time, money, and design talent, I’m thinking of creating a new UX Design Essentials for Entrepreneurs class that is 100% relevant, then delivering that version exclusively in the Bay Area, New York, and Boston.

A good idea? Please contact me to let me know.

UX Design Essentials in Poland

I will be presenting UX Design Essentials in Katowice Poland in November. Looking forward to it!

UX Design Essentials in China

I will be presenting UX Design Essentials in Dalian, Beijing, and Shenzhen China in July. Looking forward to it!

Don’t design like a programmer, part 3

In my original Don’t design like a programmer post, I explored a common UI design trap that programmers often fall into, where you have a data structure, map that directly to a UI, and expect the results to be a good user experience.

I ended the post with this example, which shows what happens when you fall into this trap:

This has been my most popular post and the feedback has been very supportive. Still, several people said that they weren’t satisfied that I ended the post bad example without showing a good one, and asked me to provide an example of a good design. Easier said than done!

My first step towards this goal was Don’t design like a programmer, part 2, where I outlined a design process for good design and its various attributes. In this third post, I would like to put everything together, apply the process, and show a partial mockup of a good design that is user centered and avoids the “designing like a programmer” trap.

Two critical design problems

My original post was not a critique of the wGetGUI UI, but rather an exploration of a common UI design trap that programmers often fall into when designing UI. wGetGUI was just an example.

There are two critical problems with the original wGetGUI design that I must point out before continuing:

  • The purpose of the program is unclear. You need external knowledge to understand what the program does.
  • The mechanics of the program are unclear. You need external knowledge to understand how to use the program.

While these are design problems are quite common, I believe they are unacceptable. The purpose and mechanics of a well-designed program should be obvious from inspection, and should never require external knowledge, experimentation, or documentation to understand. This is the very definition of what it means to be intuitive. The old programmer acronym of RTFM should be replaced with DTFUI.

By contrast, the more obvious design problems—the over complexity and exposing everything on a single surface—are of secondary importance and easy to fix.

Applying the design process

OK, let’s get down to business and apply the design process outlined in Part 2. Let’s call the new UI SiteNabber.

  1. Define the product. Write a short paragraph to explain what the product is for. What is its value?  How does it differ from existing solutions? Why does the world need it? Why will people care?

    SiteNabber is a simple utility for copying website files, primarily for site backup or offline usage. Without SiteNabber, users either have to copy the files manually or use a complex utility.

  2. Define the target users. Write a short paragraph to define the target users and their relevant characteristics.

    The target users for SiteNabber are intermediate computer users. They have enough knowledge about computers and the Internet to want to copy a website’s files, but they aren’t so advanced that they would prefer using a more complex existing solution. Experts who want to control every detail aren’t target users!

  3. Define the user goals. Write a short paragraph to explain why the target users are going to use the UI. What goals do they have? What problems are they trying to solve? What is going to satisfy them? Disappoint them?

    The top user goal is to perform the download/backup task with minimal hassle, both in terms of effort to use the program as well as time to download the files. SiteNabber users need enough control over the task to avoid wasting time by using an efficient approach and not downloading files they don’t want.

  4. Define the top user tasks. Write a short paragraph to outline specifically what the target users are most likely going to do. Focus on the top six or so tasks—not everything that might be possible. If you have defined more than six, you’re not focusing enough.

    There are two top tasks:

    1) Downloading a site (or partial site) for offline usage.

    2) Downloading a site (or partial site) for backup.

  5. Define the user’s context. When and where are they doing these tasks? What facts do they know and data do they have? What do they not know? What other tools are they using? What other solutions are available?

    Users may own the site content but probably do not (if they owned the site, they would probably use a specialized site archival tool). Consequently, users probably don’t know the structure of the site, its specific file types, or their sizes.

  6. Explain each top task to a friend. Suppose that you are explaining each top task to a friend who is a target user. Pay attention to how you would explain it: the steps, the order, the details, the language you would use, etc. Also pay attention to the things you wouldn’t bother to explain. The way you would explain the task in person is the right way to explain the task in the UI. This explanation drives the remaining steps.

    Here are the steps to copy a website:

    1) Determine the url for the website you want to copy.

    2) Chose the folder you would like to copy the files to.

    3) Start the copy process.

    4) Unless there is a problem (such as files that are too large to copy), that’s it!

  7. Map your natural explanation into a page flow. Break that task explanation into steps, give each step a title that explains what users are supposed to do, and list the elements required to do it. Don’t worry if you aren’t sure yet or if only one page is required. You can revisit this step as needed.

    Page 1: Gather the required input from Step 6, provide access to options. The title should explain what the utility is for.

    Page 2: Give progress feedback, deal with any problems found. No input required. Title: Copying website files…

    Page 3: Show task completion. No input required Title: Website copy complete!

  8. Design each page. Start with the page with the title that explains its purpose (exception: skip the title only if the purpose is so obvious that the title is silly). Give the layout a natural left-to-right, top-to-bottom flow. Start the task in the upper left corner or upper center. Emphasize the elements that need emphasis, and deemphasize those that don’t. Put related elements together so that their relationship is visually obvious. Map the interaction to the simplest, most constrained controls that do the job. To simplify the page, consider displaying optional elements on demand. Make the control to complete the task or advance to next step obvious.

    I’ll do this in the next section.

  9. Simplify and optimize the task flow and pages. Evaluate the design to make the operation simple and natural. Remove unnecessary effort or knowledge. Try to eliminate any frequently repeated actions. Provide reasonable default values. Take full advantage of previous user input, and avoid having users reenter information. Prevent input and other types of errors. To simplify, focus on what users will do instead of what they might do. Visually, remove unnecessary visual elements (like boxes, lines, 3D, meaningless icons.)

    I’ll jump ahead here and point out that the target user knows the website url and where to copy the files to, but doesn’t know anything about the files being copied. But the target user does have the goal of not wasting time or disk space. Consequently, the options should optimized avoid wasting time and space by default.

    A good optimization goal is that users should be successful on the first try instead of trial and error. That is, instead of attempting the copy, failing because of some problem, canceling, tweaking the settings to avoid the problem, and then starting over; the UI should be designed to handle problems as they are found.

    Another optimization is to preserve all previous input and settings so that users don’t have to reenter them.

  10. Review the communication Now compare the design to what you did in Step 6. They should match—after all, that’s the way you would naturally explain the task in person so any discrepancies suggest problems. For example, if you mention five options in your explanation, but your UI always offers 40, you’ve got a discrepancy.
    Make sure the purpose of each page and control is clear. Sometimes adding a word or two makes a huge difference. But don’t worry: the goal isn’t to have a lot text, but rather less, better text. Iterate as necessary.


  11. Review the results. Now compare the design to what you did in Steps 1 – 5. Does it fulfill its purpose and provide value? Does it enable the target users to perform their top tasks to achieve their goals in their actual context? Any discrepancies suggest problems. Iterate as necessary.


  12. Test with real users. You’ll never be sure that you’ve got it right until you test with real users. There are many ways of doing this, but direct observation is important. People have a tendency to blame themselves for mistakes, so they might not self-report all problems. Iterate as necessary.

    Beyond the scope. But if you are a user, please send me your feedback.

A couple important takeaways

While working through the above process steps, two important takeaways really jumped out at me:

  • For a simple utility like this, these design process steps don’t take very long—you just have to think them through. Thinking them through by writing code is the opposite of agile. Saying that you don’t have the time to apply this process isn’t a convincing excuse.
  • The steps strongly suggest that the original wGetGUI is designed for a target user probably doesn’t exist. Its target user wants a simpler, easier to use UI than the command line version, yet somehow knows what all the command line options mean. This is the Using variable or technology names as control labels trap I identified in Part 1.

Page design

Now let’s cut to the chase and design some pages!

Page 1: Gather input, perhaps with an Option dialog.

Here is the main page that identifies the program and its purpose, gathers user input, and provides access to options.

The large main instruction at the top of the page explains the purpose of the utility. Should no longer be a mystery.

The website and folder combo boxes are used to get the source and destination for the copy. Combo boxes are used for efficiency, since previous input is likely to be reused in the future. The Browse buttons (labeled with ellipses) are used to display picker dialogs to help users with providing the input. Once everything is set, the user initiates the task by clicking the prominent Copy website button.

The options required for efficient copy are selected by default. Instead of sprinkling options everywhere, the options related to the source are accessed using Source options and the options related to file copying are accessed using Copy options. General advanced options are accessed using the Advanced button. I’ll look at options in more detail in the next section.

Page 2: Give progress feedback, deal with any problems found.

Here is the progress page:

The purpose of this page is to communicate the overall progress. Gory details like the current filename being copied aren’t necessary so they are omitted. I’m assuming target users really don’t care.

An interesting design challenge is to deal with large files that users might not need to copy without having to abandon the task and start over. Note that the first page has a Prompt for large files option. If that option is set, files that are larger than some specific size are prompted before copying. Here’s how that UI might look:

Here files greater than 1 GB are prompted. Users can select to copy them as they are found or wait until the initial copy is done, select the desired files, and click Copy large files. I haven’t tested this solution, but there is a lot to be said for eliminating trial and error.

Page 3: Show task completion.

Finally, the last page gives clear feedback that the task as been completed:

As a convenience, the page gives a link to the destination folder to complete the task from the user’s point of view. If in the top scenarios users are likely to want to access that folder immediately (which I’m not assuming here), a better approach would be to not display this feedback, but just close the program and display the folder to show task completion.

To wrap this section up, note how the pages closely match the task steps outlined in Step 6. If they were different, that would suggest a design problem.

Handling the options

Handling all the options is clearly a challenge with the wGetGUI design. In the interest of time and space, I won’t mockup screenshots but rather describe a good solution.

There are several techniques to simplify a UI. These are the most useful for this program:

  • Removal If an option is unlikely to be used, just remove it! Here are some reasons to remove options:
    • There is one option that always works well, so alternatives aren’t needed.
    • The program can determine the right thing to do automatically, so users don’t need to be involved.
    • The option is so obscure that nobody uses it.
  • Goal based Better to have a few, high-level settings based on the users goals than a whole bunch of directly exposed technology knobs and dials that require users to map to their goals.
  • Contextual While anything might be (theoretically) possible in general, only a few things are likely in a specific context.
  • Organized Options are easier to find when well organized. If the options don’t fit well on a single page, the traditional tabbed property sheet is a good standard solution.

Let’s apply these techniques and handle the options in a variety of levels:

  • Level 0: Removal Just do the right thing without involving the user. For example, if a file already exists in the destination folder with the same size and timestamp, it’s the same file. No need to download, no need to ask. Given the target users defined in Step 2, it’s appropriate to be aggressive here. Remember that super experts aren’t the target.
  • Level 1: Surface most important, frequently used options For this proposed design, the Prompt for Large Files option is important enough to be surfaced to the top level. If the design had goal-based options (suppose the options for backup are different from those for offline viewing), those should be surfaced as well. I don’t think the other options justify surfacing. Certainly not a good idea to surface all of them!
  • Level 2: Contextual options The source and copy options are accessed contextually using the Source options and Copy options buttons.
  • Level 3: Advanced options I used an Advanced button to present any remaining options—assuming any remain. Ideally these would fit comfortably on a single page, but I would use a traditional tabbed-based presentation if not. Normally I recommend against using an Advanced label (generally, it’s better to use a more specific label), but that label is appropriate here because the remaining options really are advanced and infrequently used.

The design process puts a lot of emphasis on defining and characterizing target users and their goals. The challenge of handling the options illustrates why: good design decisions completely depend upon the needs of the target users. Don’t fall into the other classic programmer trap of designing for yourself or presenting everything the same way.

Handling the details

I haven’t yet performed Step 12: Test with real users, so there’s a good chance that I have some details wrong. This is normal and expected. Here is some feedback that might come up with real users:

  • I need all those options! The proposed design eliminates only the options that aren’t really needed—so any disagreement lies with what is really needed. To simplify, the focus should be on the probable, not the possible. Yes, I suppose it is possible that somebody using a website copy program doesn’t want to copy html files, but it sure isn’t probable. Better to remove such options.
  • Your design isn’t practical.The original wGetGUI design is a UI for a command line program, so you can’t get progress feedback (or some other problem.)  Feasibility often comes up as an issue, so I want to make two important points:
    • The user experience should drive the technology, not the other way around. Saying that the technology can’t support a good UX is usually a poor excuse. Fix the technology!
    • Decisions made by backend/API developers affect the user experience. Such developers often claim that their work doesn’t affect the UI. This is nonsense. But this attitude explains why so much software has poor performance and responsiveness, poor error handling, poor feedback, and can’t be canceled.
  • But I like the original design… If so, that’s great. You had the motivation to learn how to use the utility, but most users don’t. This proposed design is targeted at those users.

If you do only one thing… If you design UI like a programmer, please try to apply the design process outlined in Part 2. It really does work and it gets you focused on your users instead of the code.

Want to learn more? Check out UX Design Essentials and UX Design Basics

If you would like to learn more about the process I’ve just described, please consider taking my UX Design Essentials course or my online UX Design Basics course. I’ve designed both of these courses to help non-designers get started in UX design.  I’ve only scratched the surface here.

Correcting the reality distortion field: Learning the right lessons from Steve Jobs

There have been many stories about Steve Jobs lately. Walter Isaacson’s authorized biography Steve Jobs came out this week and is now the #1 bestselling book. Isaacson has hit the talk show circuit hard—I must have heard essentially the same interview at least four times this week.
Through Isaacson, here is what we are learning about Steve Jobs:

  • Steve Jobs was an arrogant jerk. A harsh but concise summary. He often treated his family and coworkers quite badly. He was quite full of himself.
  • Steve Jobs was cruel and humiliating. He didn’t hesitate to humiliate employees. Many Apple employees lived in fear of being fired—and rightly so.
  • Steve Jobs valued his own personal opinion above everything else. Jobs famously said “People don’t know what they want until you show it to them.” As a result, Apple has downplayed user research. Apparently Jobs wasn’t all that interested in the opinions of Apple employees either as he routinely ignored their input.
  • Steve Jobs was a demanding perfectionist. He wanted everything to be just right, and wouldn’t accept anything else.
  • Steve Jobs was a great innovator. At least, that’s what everybody says. But unless you define “innovation” as “perfecting ideas invented by others,” I believe Apple isn’t especially innovative.

Isaacson (like everybody else) is in a state of wonderment as to how this all managed to work out so well. All this worked out because, against the odds, Jobs was usually right.

I’ve seen other managers attempt to do similar things, and the results are consistently disastrous. For example, endlessly obsessing over colors might put you on everybody’s “A list,” but probably not the A list you have in mind. Being an arrogant, cruel, humiliating, self-absorbed, perfectionist jerk isn’t normally the road to success. It would a tragedy if this turned out to be Steve Jobs management legacy. Steve Jobs wasn’t successful because of these characteristics, but in spite of them. Not just anybody could have pulled this off—Steve Jobs himself was just barely able to be Steve Jobs. I fear that we are in for a generation of Steve Jobs wannabes screwing up every project they touch.

“You aren’t Steve Jobs, so don’t act like him.”

Exposing the reality distortion field

Let’s consider one example. When Isaacson describes Jobs’ famous reality distortion field, he explains how the Macintosh team said a project would take three months to complete. Jobs insisted that they do it in only two weeks, and lo and behold, they amazingly got the project done in two weeks.

This is pure BS. The reality distortion field here is that Steve Jobs deluded himself into thinking that is what actually happened. In the real world, when a team of talented software developers say a project will take three months to complete, it will probably take a bit more at best. People rarely overestimate. If they worked double time, perhaps they could get a week and half’s worth of work done in a week’s time. It is simply not possible for a team to deliver three months of real work in a couple weeks.

My experience is that if a project manager insists on doing a project in less time than the shortest estimate, the project will end up taking more time than the longest estimate. I can’t prove this, but Steve McConnell comes awfully close in Rapid Development: Taming Wild Software Schedules.

In the section Overly Optimistic Scheduling, McConnell tells the story of Microsoft Word for Windows 1.0. Based on metrics, McConnell estimates the optimal schedule to be 460 days. The shortest estimate the team gave was 395 days. Bill Gates insisted that it be done in 365 days. How many days did it actually take? Try 1887—5 times longer than planned! Why? Because cutting all the corners required to pretend that the product could be done in a year meant that the resulting code was poor quality crap that all had to be redone (or “stabilized”). This is how ignoring your team’s estimates usually works out, and I doubt that Jobs’ results were any different.

The Right Lessons of Steve Jobs

I think that Steve Jobs was absolutely brilliant visionary and project leader. But the brilliant part isn’t the story being told by Isaacson—those are mostly character flaws. Here’s my summary of the brilliant part:

  • Focus on experiences over features and technologies. The user experience is the only thing that matters. To users, the user experience is the product. Therefore, the user experience rightfully drives the design and features and technology are enablers—not the other way around.
  • Make it delightful. Well-designed products make an emotional connection. They are a joy to see and a joy to use. They are designed to make users fall in love with them.
  • Do less better. Better to do a few things well. Have a few, well targeted products instead of many, poorly positioned ones. Better to have a few great features than many not-so-great ones. Nail those and move on instead of constantly fixing problems in hastily designed and implemented features. Jobs once said “Quality is more important than quantity. One home run is much better than two doubles.”
  • Keep it simple. The simplest design that does the job well is better than a complex design that can potentially do everything. Well-designed simplicity is powerful—don’t let anybody sell you that tired “simple means simplistic” nonsense.
  • Set a high bar. Good enough is not good enough—aim for insanely great. Set high expectations for your products and your team. Have pride in the quality of your work.
  • Get it right the first time. Don’t start work on an innovative product until the technology is ready. Ship a product when it’s ready, not when it’s due. Don’t take three times to get it right.

These are the right lessons—the part of Steve Jobs’ life that you should aspire to emulate.

If you do only one thing: Remember that Steve Jobs’ vision, focus, and high standards are what made Apple great, not his personal character flaws.

For more information, please contact info@uxdesignedge.com

All Content Copyright © UX Design Edge