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.
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.
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:
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.
OK, let’s get down to business and apply the design process outlined in Part 2. Let’s call the new UI SiteNabber.
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.
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!
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.
There are two top tasks:
1) Downloading a site (or partial site) for offline usage.
2) Downloading a site (or partial site) for backup.
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.
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!
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!
I’ll do this in the next section.
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.
Beyond the scope. But if you are a user, please send me your feedback.
While working through the above process steps, two important takeaways really jumped out at me:
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 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:
Let’s apply these techniques and handle the options in a variety of levels:
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.
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:
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.
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.
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:
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.”
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.
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:
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.
Like the rest of the technology world, I am mourning the loss of Steve Jobs two weeks ago. Steve Jobs had an extraordinary understanding of the human side of technology, and courageously believed that technology should not only be useful but enjoyable—that it should make an emotional connection. He revolutionized the computer, music, and cell phone industries by doing a few things extremely well, keeping things simple and delightful, and waiting to release products until the technology was ready instead of merely possible. He led an extraordinary life and founded an extraordinary company.
To get an idea of how extraordinary, I’ve been asking myself some hypothetical questions. What if the circumstances where different? What if the real Steve Jobs:
Would Apple’s results be the same? Better? Worse?
To raise this thought experiment a notch, suppose Steve Jobs’ doppelganger (a different person with similar skills, philosophy, personality, and temperament—let’s call him SJ2) were to land a job in the following circumstances:
How would this person’s career go?
Of course, this is crazy hypothetical so there are no right or wrong answers. Please share your thoughts in the comments and compare your answers to mine.
Breaking news: My contract for my book UI is Communication was just approved! More later but if you are interested in being involved, please let me know.
Yesterday I stumbled across Improvements in Windows Explorer on the Building Windows 8 blog. I found this post interesting because while it is superficially impressive, I see some fundamental UX design mistakes that I suspect will result in the redesign falling short of expectations. Students of my UX Design Essentials course and readers of my blog should recognize them immediately.
OK, what did you find? Let’s proceed…
First, for the good part. Here’s what I like with the Windows Explorer redesign:
I’ll add to this list as I discover more things, but this is it so far.
Guess what? Windows Explorer is getting a ribbon. What a surprise! Didn’t see that one coming. To be a bit snarky, I think Improvements in Windows Explorer could be accurately retitled How we used data to justify a ribbon for a simple utility that probably doesn’t need one.
Don’t get me wrong, I love the ribbon and think it is a fantastic UI innovation. But from The Politics of Ribbons:
The ribbon has one significant strike against it: it is the heaviest commanding solution there is. A good UX design principle is to use the simplest, lightest weight solution that does the job well, so applying this principle suggests that—given its weight—a ribbon should be among last commanding choices, not the first.
In UX Design Essentials, I identify the classic UX design process mistakes. Here’s #3:
Falling in love with one (usually first) solution.
It’s a good bet that the ribbon was not only the first choice, but the only serious choice considered. Using a ribbon was likely a politically driven decision justified with data. Look at the data…we just had to use a ribbon!
A good design process is about making choices on behalf of target users to create a product that satisfies their goals. But you can’t make a good choice if you have only one option to choose from. Focusing on a single solution short-circuits the design process.
To convince me that this is a great design, I want to see an exploration of simpler, lighter weight alternatives and a demonstration that the ribbon approach is in fact better. And if you practice effective prototyping, you can’t argue that would take too much time and effort.
Windows Explorer is a utility, meaning that it is typically used to support tasks initiated in other programs. It’s what Alan Cooper describes as a transient application, not a sovereign one.
This is a significant detail because it affects how people use the program and how you should make design decisions. Here are some implications:
Bottom line is that users want utilities to perform tasks as quickly and simply as possible, then move their attention elsewhere. A complex utility, with lots of stuff you really don’t need, undermines this goal.
Doesn’t this feel UI way too complex for what should be a simple utility? Do you really want to wade through all this stuff to find a command? Do all these commands need to be visible on the screen all the time? Don’t you think there must be a simpler alternative that does the job better?
With over 200 commands, Windows Explorer looks like it was designed by a feature hoarder. If your top 10 of 200+ commands are 82% of usage, time to start cutting back.
BTW: Here’s a useful ribbon guideline that I think is appropriate:
The highlighter test is a simple, quick way to evaluate how effectively a UI is using screen space. Gather your top tasks, perform those tasks using your design, then highlight the UI elements that are potentially useful for those tasks. If almost everything is highlighted, you’ve done a great job. If not, you’ve got some work to do.
Here’s my highlighter test for the Windows Explorer ribbon:
Note that I highlighted only 3 of 19 visible ribbon commands. Crikey! The reason is that I use shortcut keys, context menus, or direct manipulation (usually drag and drop) for all the other commands. Yes, the data shows that Paste, Properties, and Copy are top commands, but that data also shows that 85% of usage comes from context menus and shortcut keys. I don’t expect the ribbon to change that much.
One benefit of traditional menu bars that deserves some appreciation is that you can fill them with every command you’ve got and nobody is going to care much. Not true with a ribbon.
The key to user-centered design is to identify your target users, understand them well, and make good decisions on their behalf. Improvements in Windows Explorer mentions power users quite often, but doesn’t mention typical users specifically. Looks like the Windows 8 team is targeting power users. Nothing wrong with that if it’s appropriate.
A value proposition states the reason your target users will want to buy and use your product—especially when compared to the alternatives. Their post suggests that power users are using after-market add-ons like TeraCopy, QTTabBar, DMEXBar, StExBar (which BTW the ribbon-based Windows Explorer won’t support anymore). Power users also use command line and Windows Power Shell.
The “when compared to the alternatives” part of the value proposition is a killer here. While their post makes a strong case that the redesigned Windows Explorer has many features power users will like, they didn’t make the case that power users are going to care. Will a Windows Power Shell user switch to Windows Explorer because of the ribbon and a few new commands? I doubt it. And if not, are power users really the right target?
Good value proposition work would have revealed this all-important problem.
But wait, there’s more. Let’s start to create a persona for power users with a few key characteristics:
BTW: I wouldn’t expect “Desire to respect Explorer’s heritage” to make this list. Your design priorities should clearly align with your target user.
Now assume that you are a power user and want to copy the file you just selected. Which approach are you more likely to take:
For this power user persona, I just don’t see #2 happening here. I know that the Windows team no longer uses personas. Perhaps they should.
At this point, you might be thinking: OK then, what would you do instead? Glad you asked!
Note how the Windows 8 team is focused on data, features, and feature discoverability. I mentioned in the introduction that using data is a much better way to make decisions than personal opinion. But there are several traps using data, the most important being that using data is often used as a substitute for thinking.
Data tells you “how much.” Knowing “how much” is important, but knowing “why” is far more important still. Raw data doesn’t tell you the users’ goals or what they are trying to do. It only tells you what they did and how often.
For example, the Windows data shows that Properties is the second most frequently used command. Why? Why do suppose users want properties so often? Is looking at properties a common task or goal? When you see a file, do you immediately think “I really want to see its properties”? No! The Properties command is a means to an end, but never an end it itself. The user is trying to perform some other task and checking Properties appears to be required in order to do it.
While a good design (that mindlessly follows data) would make the Properties command more prominent, a great design (that leads with data) would strive to eliminate the need for the command in the first place!
How do you do that? With scenarios! A scenario describes a specific target user trying to achieve a specific goal or task in a specific environment. Their post mentions Windows Explorer supports many different scenarios like viewing photos, playing videos, and playing music—then completely ignores that fact when justifying design decisions.
Remember: Windows Explorer is a utility that helps users manage files—a goal that most users rarely have!
A better approach is to design for the goals that users really do have. Design the best possible experience for viewing photos! The best experience for playing videos…for playing music…for protecting users data…for finding stuff. Supporting these scenarios should drive the design decisions, not raw data. So, for example, if you view a folder of photos, the top-level commands should be focused on the top photo tasks—and nothing else! And if done properly, excise tasks like displaying Properties go away because they are no longer needed.
Unlike task-based design, scenario-based design considers the user’s context—a great way to eliminate unnecessary complexity. In any given context, the user isn’t likely to need 200+ commands, but more like 5.
If you watch the video at the end of their post, Alex Simons show some tasks that look like scenarios. But those feel fake to me. Why? Remember that Windows Explorer is a utility and scenarios are tasks done in a specific environment. Real Windows Explorer scenarios should rarely start or end in program itself. These aren’t “end-to-end” scenarios but rather what I call “technology vignettes”—scenarios fragments artificially limited to the component you are working on, but not tasks that users really do. Designs that hold up well with “technology vignettes” routinely fall down when evaluated with real scenarios—especially for utilities. They aren’t “end to end” but “middle to middle.”
I really want things to work properly. I’ve found several basic features in Windows Explorer that just aren’t quite right yet, but in the interest of time I’ll limit myself to four:
These details weren’t mentioned in their post. Hopefully the Windows 8 team is addressing them, but I fear that focusing on the ribbon will distract from nailing the basics. I’ve seen that happen before.
If you do only one thing… When evaluating a design, take a step back and ask yourself what is driving your decisions. Technology? Features? Politics? Schedules, deadlines, and budgets? Data? While practical realities, these shouldn’t be the driver. Instead your design should be driven by providing value, satisfying user goals and tasks, delighting users by doing a few things exceptionally well. If you are using data, don’t let it become a substitute for thinking. Take the time to understand what the data is really telling you.
Want to learn more? Be sure to check out the UX Design Edge training courses. Every technique I’ve mentioned here is presented in UX Design Essentials.
Disagree? Leave a comment!