Abstract, High Resolution, Listen & Learn

Have you watched Abstract on Netflix yet? World-class designers share their life and work and philosophy, which I’ve found fascinating. A common thread in the episodes I’ve watched so far is that design doesn’t happen in a vacuum. In order to produce something useful and beautiful that people will love and buy, you have to engage with the world. It involves talking to people. Listening and verifying with your own eyes and ears.

Ralph Gilles — Head of Design at General Motors — says in Episode 5, “Go out and talk to people.” He gives the example of his Chrysler/Jeep design team engaging with millennials literally “in their living rooms.” Listening to their problems and trying to solve those problems, taking it all back to the car design lab. “How do you know what consumers want even before they know what they want?”

Tinker Hatfield — shoe Designer at Nike — says in Episode 2, “Get outside, engage with the world.” How a steady stream of fresh input leads to innovation and being outside, doing sports he loves, helps him staying connected to everything. Running a mile in their shoes, if you will. An example of the years of close back-and-forth work with Michael Jordan to perfect the Air Jordan basketball shoes.

I’m sensing a trend here: if I listen, I learn. When I approach my own software work, do I understand the needs of the person for whom I am designing and developing? If the answer is no, I need to step outside my office and talk to people using the software.

Another compelling series to hear from talented and innovative product designers is High Resolution, available on YouTube. In Episode 8, similar ideas emerge from Automattic’s own Head of Computational Design & Inclusion, John Maeda:

Don’t focus on kerfuffles within your org — keep your focus on the world. That’s where you are meant to be. No matter how great of the place you’re in.

… Creative people are diverse-oriented, and great remixers. — John Maeda

These thoughts remind me of the “jobs to be done” philosophy where success comes from understanding peoples’ circumstances. And not only accepting input when it fits a certain profile I already expect.

The key to successful innovation is identifying jobs that are poorly performed in customers’ lives and then designing products, experiences, and processes around those jobs. — via Harvard Business Review

Discovering what those jobs are requires engaging with your customers, in their lives, in their work. Now it’s time for me to get outta this chair.

Interview with WisdmLabs

I recently spoke with Namrata G from WisdmLabs about Automattic, WordPress, GPL, CSS frameworks, and more. Full interview here: Interview with Lance Willett – Sweeper at Automattic.

WPCandy Interview on Commercial Themes

Hard to believe it’s been 12 months since the last time I was on WPCandy.

I talked last Friday about commercial themes on WordPress.com with Ryan Imel of WPCandy, looking back one year after launching the service. Here are the links to listen to the interview.

Thank you to Ryan and his crew; they do a superb job of covering all the WordPress news and events, day in and day out.

Don't Work on Spec

From the Important Topics in Running a Web Design Business Dept. I’d like to share a recent conversation with a colleague about whether or not it’s a good practice to include mockups in a possibly unpaid bid for a project. I’m posting it here for reference and to continue the conversation.

Colleague: I’ve seen on Twitter… times where you said that you’d finished a mockup for a client. And by that, I’m assuming you mean a mockup of a website that you’re proposing to build for them…

Lance: My situation might be different than other web professionals in that I generally work with the same clients over and over (my last “new” client was Summit Hut in September 2007). So, the mockups I do now are for paid projects that have budgets and buy-in from clients. And, these projects aren’t typically new websites; although in one case that I talked about on Twitter the mockups I presented were for a complete overhaul of a web application’s user interface.

In the “real world” of trying to land gigs or client projects, mockups and prototypes can play a part, but be very careful when people ask for that type of work without pay.

If that’s the case, when you do your mockups, do you just do straight HTML (so the look is there, but not the functionality), build it in Photoshop (or something similar) or something else?

As far as the “how” of mockups, I almost always jump from paper sketches and basic ideas into HTML and CSS. That is my strength, and I am very fast from concept to working website, so it’s my best use of time and energy. I use Photoshop and Illustrator for design elements such as backgrounds, buttons, and icons with an occasional—but rare—entire mockup in Photoshop that I then flatten as a PNG and use as a mockup or starting point for coding.

Skipping Photoshop doesn’t work for everyone, but it can be a timesaver if you are more comfortable working with other tools. Check out Why we skip Photoshop, a great take on this by 37signals. Most “graphic” web designers take offense to this type of approach, since they say that those kinds of designs tend to look alike in their boxiness, and that you are constrained by CSS basics, etc. I don’t agree—I think creative and good design work can happen in non-visual tools. Overall, I think you should do your work where it is fastest and more efficient for you; for me that is coding HTML/CSS and tweaking the display right in the browser, not in an image editor.

The big advantage for me for moving from paper and ideas directly to code is that I can get a working demo up faster and into my clients’ hands that much quicker.

And also, if you’re doing a proposal for a client (bidding on a project and/or expanding upon a bid you already sent), do you generally give them a mockup of what you’re proposing and do you charge for your time to build that mockup and the bid?

My advice, and the standard industry practice, is to never do work “on spec,” meaning those design mockups should never be for free. If you get client buy-in and establish the mockup and design process as part of your workflow, you won’t get bit by people backing out after you sink time and energy into it. There are those occasional clients who want ideas for free, and they will use you to that end. Of course, those folks might be few and far between, but be aware that they are asking you to do unpaid work.

There is a lot online about this already, so I won’t harp on it too much. From the master Zeldman himself, read Don’t design on spec. For a perspective from a respected graphic web designer, Veerle Pieters, I recommend Free of charge please!, and there is even an entire website dedicated to the topic: NO!SPEC. Besides reading what other web professionals have to say, I’d also recommend picking up a copy of Graphic Artists Guild Handbook: Pricing & Ethical Guidelines for some great advice and case studies (Amazon).

If a client asks for work up-front with no payment, my tendency is to run like the wind! If you feel they are a worthwhile client, and you really want to work for them, spend some time educating them on your workflow and process, and explain why the mockup and design iteration phase is an important part of the project cost and budget. That education will pay off many times over, giving more value to all the parts of your web design work, not just the “expert” parts such as coding and testing.

For example, in my typical web design project process I have clients read and sign off on each step, including brainstorming, planning, content organization, and design mockups. Giving each stage in the process a monetary value can help you feel good about spending time to get things right, and gives the client a reason for all the charges you bill them (or all the line items in an estimate beforehand).

This is a very important topic—if you are a freelancer it would do you good to define your stance and “official policy” on spec work. Let’s educate ourselves, our colleagues, and our clients on why spec work is unprofessional, and share this conversation with others.