My app is a song database that musicians can use to assemble set lists; when finished, they can print them out and bring the hard copy on stage like musicians have always done. Some of the first feedback I heard was that the text or the buttons were too small; I didn’t get this because the app uses Apple’s standard interface elements, practically guaranteeing ease-of-use. Finally I realized that musicians were taking their iPads on stage with them and reading the set lists directly from the screen rather than using printouts. I had to add a “performance mode” with all the elements sized for viewing from a distance, and interacting with quickly between or during songs.

Since then I’ve added features that allow musicians to control their on-stage equipment from their iPads, and I’m about to add features to allow multiple band members’ iPads to interact with each other on stage. These and many other features have taken me by surprise because I never would have used the app in this way; I only envisioned it as an easy way to generate printouts. My users have taken it much further than I imagined, and I’m fortunate that they’ve waited for me to catch up so many times.

This fits perfectly with the Derek Sivers book I recently read, Anything You Want, in which he describes his customer service philosophy and quotes another author, Steve Blank: “No plan survives first contact with customers.” And it fits with another book I read this year, The Lean Startup, which advocates the idea of a “minimum viable product” to test your business ideas while saving your resources for growth after you know where it’s needed.

This has been an interesting lesson for me since I typically judge my success in building things by how closely I achieved my original goals. Instead, I’m going to start thinking about how quickly I can find out what the users of the product want, and how effectively I can adapt the product to serve them. I can’t wait to try my next project with this in mind!

I’ve worked with over a dozen designers and created over 100 websites, and I routinely encounter confusion about how this process works. The problem is that some designers and some clients become so focused on perfecting the conceptualizations — image files created in Photoshop or Illustrator — that they forget that those are not the ultimate product. Here are a few concepts to keep in mind if you’re working on the design phase of a web project:

1. Implementing a web design is not a process of “converting” the design files to a web format, it’s a process of building a website using the design files as a guide — just like a house must be built using blueprints as a guide.
2. The goal of any good developer is to match those depictions as closely as possible, but the more particular you are about the details, the longer that process will take. To take a simple example, if the design files show some leading between lines of text, most developers will see that and implement it. But if the developer set the leading to 10 pixels and you had your heart set on 11, the developer will have to spend time revising that.
3. It’s not important that the design files depict every page in exactly the way it will appear on the web. What’s important is that they depict every element that will appear somewhere in your site. For example, if you have a different submenu for each of five site sections, you don’t need to provide five different designs — just give the developer one design and he or she can extrapolate the other four from that. A less intuitive example is icons. If you have a half-dozen different icons that appear on a dozen different pages, it’s more convenient to give the developer one file containing only those icons, than a dozen files showing the complete pages in which they appear. Conversely, if the site contains an unusual page with unique elements, you must provide a file showing that page or at least those elements.
4. The individual elements are typically what the developer will spend time the most time implementing … combining them together to make each page is the easy part. So it’s helpful to think of your design as a collection of elements rather than a complete whole. How many elements are there — did you create four different styles of buttons, when two would suffice? Does every page use the same handful of text styles, or do you envision dozens of different text styles throughout the site? If you try making a list of every element you’ve designed and giving each element a name, you’ll have an idea of what the developer will face.
5. In most cases, the website you’re designing will grow and evolve … usually before the design phase is even complete. Therefore, it’s important to think of different ways in which the design elements can be reused. If you provide a box to present a couple sidebar blurbs, can that box expand to accommodate a longer blurb in the future? If the main menu contains five items now, does the design allow for adding two or three more? Will new text use a small number of styles, or will the person entering the text also have to perform a lot of formatting to keep the look consistent?

If you think of the design as one step in the middle of a long process, rather than the end result, you should be able to create a design that is both easier to implement and more flexible and valuable over time.

The problem with this approach is that users don’t always size their web browser windows to fill their screens. Actually, many users do, but they shouldn’t — especially with ever-increasing screen sizes. After all, the purpose of a large screen is not to let you view one thing at a time, with more empty space around it — it’s to let you view more things at one time. It’s just like a large desk or workbench that lets you spread out several documents or tools for easy access. Most people don’t buy large desks so they can read large pieces of paper, but so they can lay out several pieces of paper side by side.

To accommodate this, web designers should not view their job as “how to fill up those big screens.” Instead, they should design a site at the smallest reasonable size and then let users arrange that how they wish within their workspace.

An even better approach is to design a site that can automatically expand and contract to correspond to the user’s window (not screen) size. If a user wants to view a number of smaller windows, the site will look good; if a user wants to view just one large window, the site will also look good. This is called “liquid design,” and although most designers don’t approach their work in this way, I always advocate for it. “Fixed” designs are still more popular, but with computing devices ranging from 40″ flat-panel displays to 2.4″ phones, I’m hoping more designers come to realize that the best person to decide what size to make the site is the end user.

Today I was thinking about one inherent problem, which is the level of specificity that programming requires. I don’t think most people understand this, so I wanted to take a shot at explaining it. To make this a little more concrete, let’s imagine that you’re designing software for a robot, which will help with your cooking.

You don’t like chopping vegetables, so you decide to program your robot to carry out that task. First, you program it to distinguish a vegetable from other objects in the kitchen. In this process, you realize how many different shapes vegetables come in, and how difficult it is to tell a vegetable apart from other objects. But eventually you limit yourself to 10 different vegetables and teach your robot to recognize them.

Next comes chopping. The basic up-and-down motion of the knife is easy enough to program, but there are a lot of decisions to be made during the chopping process. How large should the pieces be? What shape? This varies by the recipe and maybe by the vegetable, so you end up creating a chart that your robot can refer to when beginning a new chopping task.

You’ve spent more time on this than you expected, but now your robot is working pretty well. You set it to work on a bag of potatoes and turn your attention to other things. OOPS — when you look again, the robot has chopped a few rotten sections of potatoes along with the good sections. Your robot doesn’t know how to recognize bruises or spoiling, so you have to teach it that, too. Unfortunately, a rotten potato looks different than a rotten tomato, so you need more charts explaining all the possibilities. Eventually, by trying some different vegetables and watching the robot carefully, you get it to correctly identify and reject rotten vegetables every time, without throwing away too many good vegetables in the process.

Satisfied, you leave the room to work on something else, and come back in a few hours. OOPS — the bowl that the robot was using is full, and the chopped vegetables are overflowing onto the countertop and the floor. Now you need to teach the robot how to tell if the bowl is full, and what to do when that happens.

I think you see the problem now: software (whether in a website or a robot) only does what we tell it to do, and no more. The key is thinking, in advance, of every specific instruction we will need to provide, for every possible scenario. But this is difficult because our own minds are very adaptable and don’t require so much planning.

This is where my job as a programmer comes in. If a client asks me to build a robot that “chops vegetables,” I need to translate that to a robot that “identifies particular vegetables, divides them into particular sizes and shapes, rejects pieces that don’t meet particular standards, and stores them appropriately.” To the extent that I can think of these requirements in advance, I can offer an accurate time and budget estimate, and build a product that the client is happy with.

By the way, I have a narrower definition of “bug” than most people, and that’s easy to discuss using this analogy. When you found that your robot was not discarding the rotten vegetables, was that a bug? I would say no, because nobody had bothered to tell the robot about rottenness. That’s a problem, but it’s not the robot’s fault! If, on the other hand, you had programmed the robot to recognize a particular kind of rottenness in a particular vegetable, and it still failed to do so, then you’d have a bug — a piece of software that’s not doing a task it was specifically designed to do.

The good news is that once we get that robot working, it will chop a heck of a lot of vegetables without further intervention. The bad news is that it falls upon us to define in advance every detail of that task.

When my favorite hosting company had an incident recently, losing data for two of my clients’ sites, I realized that this model is quite outdated. Modern websites consist of much more than the developer’s files. With a content management system, my clients are adding content and files from different locations that are only collected in one place on the server. And with a social networking site, users are adding content constantly, without which the site would be worthless. Without an automated backup of the site’s database and root directory, replacing content added by the clients is time-consuming, and replacing content added by users is impossible.

My solution is a new system I’ve created for my clients. It allows me to configure automated backups of the database and the root directory, at different intervals if needed, as frequently as once per hour. I and/or my clients can receive email notifications of every backup, and every backup failure. The backup files are saved at a different datacenter than any of the sites, and are available to clients any time at a password-protected web page. Clients can even log in and run a manual backup at any time.

This should bring my backup strategy up to the level of my current website development. I can’t say I’m looking forward to using it, but I do like knowing it’s there!