There’s a thread on Quora about how to define a designer’s ideal range of knowledge.

Here are the dimensions we look at:

1. Writing: Can they think and communicate clearly? Writing skills are critical to UI.
2. Interface design: Can they organize elements in 2D space so that the arrangement is meaningful, clear, and instantly understandable? Can they organize elements in time (navigation, flows, steps) in a way that minimizes uncertainty and feels efficient?
3. Product: Can they appreciate the problems and desires our customers have and turn that understanding into business value? In other words, do they know what matters and what doesn’t matter to customers and stakeholders?
4. Development: Are they able to code their designs in HTML/CSS? Can they go further and integrate their designs into the application source code? Can they talk shop with programmers?
5. Character: Are they a nice person with a good motivation?

Of course it isn’t necessary for everyone to kill on every point (except #5). But I think you can tell a lot about a company’s design culture by looking across these dimensions.

Designers sometimes use the word “refactor” in a loose way. I think they overhear the word from programmers without getting the precise meaning. This article will introduce the term to designers so they can gain the same advantages that programmers have from a clear understanding.

How do designers loosely understand refactoring? Many take it to mean “rearranging” a design or “adjusting without completely rethinking” it. Refactoring actually means something else. It means changing the way a design is built without changing the way it looks from the outside.

Here’s an example of a refactoring. Let’s say there is a list of elements on a page and we want a dividing line above and below each element. Below the list there is a copyright footer.

We could implement this design with the following HTML and CSS:

Sometimes you need to take shortcuts to quickly prove a concept. I’m experimenting with a new view on Basecamp and I need some data to generate that view. I want all the messages on a project, grouped by day, and also the latest comment per message per day. I don’t know the “right” and performant way to put that query together. But I don’t need to worry about that. I’m just testing a concept here.

So I wrote a totally ugly, awkward implementation that gives me @posts_and_comments. And that’s ok. If this design is successful, the fact that I want @posts_and_comments isn’t going to change. What will change is the implementation that pulls that data out of the database and populates the instance variable. In order to make that future step as easy as possible, I’m hiding my ugly implementation behind a clearly named private method on the controller. The controller action calls `find_posts_and_comments_for_log` and as far as the view is concerned, nothing untoward is happening.

If the concept doesn’t work out, no problem. I didn’t spend too much time on the implementation. If the concept does work, the ugly implementation will be easy to replace later because it’s tucked behind a clearly defined method.

When your implementation is a total hack, put it behind a good interface. Then you can swap the implementation later without rethinking the design.

Here’s an interesting quote from Kent Beck. He says:

The product of software development is two-fold:

• The behavior of the system
• The options for extending and modifying that behavior in the future.

That second point summarizes what good software design is about. Each feature we build in our code gets us closer to release. But the way we build each feature can set us on different paths. If we don’t care how it works, as long as it works, then our launch may come and go without a problem. But when it’s time to return to that feature and make a change or an improvement, we’ll likely find ourselves wading through a tangle of spaghetti.

We want to take the other path, where each coding decision carries a question with it: What will I think of this code when I need to change it in six months? Will I understand it? Will changing this break other things, or will the change be isolated? This habit, to the extent that we can keep it up, allows us to keep improving our apps instead of getting stuck in spaghetti.