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.
The comments are closed.