I will be presenting UX Design Essentials in Katowice Poland in November. Looking forward to it!
I will be presenting UX Design Essentials in Dalian, Beijing, and Shenzhen China in July. Looking forward to it!
My blog has been on an unscheduled vacation since November 1st. This is about the time I started working on UI is Communication, and unfortunately I don’t have time to both write a book and blog. Too bad, because I have about one hundred fantastic topics in the queue.
LinkedIn recently added a Poll feature and I’ve tried a few polls on a variety of user experience-related topics. They are fun to make, fun to take, and the results are often insightful. Best of all, I can put together a good poll in a couple minutes, which is about all the free time I have right now.
So, here’s the deal: Every Monday I will post a new UX design-related poll, which you will see in the lower-right corner of the UX Design Edge site. (That’s the weak fallow area for you Gutenberg Diagram aficionados.) Please stop buy, take the poll, and check the results.
To put everything together nicely, I have registered ux-poll.com, which will take you to an archive of the past polls.
Please participate and enjoy!
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. 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.