Archive for 2008

Click on one of the items below to go to the post

The Independent Worker’s Field Guide: Rates and Finances

Posted on 8 November, 2008 at 1:05am with 9 comments

Going independent is a scary thing. You have to convince yourself to leave your job, be your own boss and be responsible for your own fate. There seems to be a dearth of good, specific documentation about how to take this step, so I’ve tried here to compile the best of what I’ve learned over the years. This advice is specific to design, but much of it also applies to consulting in any field.

Chapter One: Rates and Finances

Rule #1: You have to budget.

The first thing you should do (nay, must do) is to sit down with your favorite spreadsheet application and write up a budget. Figure out what your monthly expenses are, how much spending money you’d like to have, how much you want to save, and the cost of your health care (either estimated expenses or private insurance if you’re buying it). Add them all up and divide by 0.6 to account for taxes. Voila! That number is about how much you should aim to earn per month.

Remember this number. Cherish it. It’s your new best friend. Look at it when you get anxious about money – it will comfort you.

And I hope you caught that bit about taxes. You don’t have a company withholding money for you anymore, so you’ll have to be responsible in order to be ready when April comes around. Don’t worry though, I’ll explain how to prepare for that in a little bit.

Rule #2: Don’t work forty hours a week.

Now, what I mean is that you shouldn’t work forty billable hours a week, especially if you maintain multiple clients at the same time. There are a few reasons for this. First, people are simply not productive for that much time. It’s required in an office because of the inevitable inefficiency that happens in any company of reasonable size, but you are independent now and you can be a lot tighter about when you work and when you don’t. Work when you’re productive, rest when you’re not. What a novel idea!

Second, you should plan to spend about 5-10 hours a week doing off-the-clock work. This includes finding potential clients, writing estimates and contracts, and networking with your peers. This is absolutely essential to your success and if you don’t give yourself time to do these housekeeping tasks it won’t be long before you’re burned out and signing up to flip burgers at the local In-N-Out.

Rule #3: Be pragmatic about your rates.

Many people struggle with setting rates, especially as it can be difficult to figure out what others in your field are charging. A good starting point is to take your current salary, convert it to an hourly number, and multiply by 2. (Note: a commenter below points out this should be closer to 2.5 or 3. This is more in line with what your company pays for you and is necessary if you have overhead to cover. When in doubt, take the higher multiplier. It is far better to start high and adjust down than to start too low and have to scramble to make up the difference.)

Divide it into your magic number from Rule #1, and then divide by four to find out how many hours a week you’d have to work to make your target. You should be aiming for 20-25 hours a week, so adjust accordingly. If you want to work less, you have to charge more. If you want to (or have to) charge less, you have to work more. Work out an ideal balance that you’re comfortable with.

Now get out there and find some clients. The only way to find the sweet spot with rates is to do some actual work and collect data. Note the kinds of companies that you’re working for — you will probably find that smaller companies have less money in their budgets but more work to offer. Bigger companies often come with good rates but a lot of overhead. Many consultants have a sliding scale depending on the size and visibility of the company. Over time you’ll naturally develop a small range that gives you some wiggle room for negotiation.

Rule #4: Don’t be afraid to negotiate.

When quoting rates, always start high and negotiate down. I’m going to teach you a trick of sorts that can be used when a client is gunshy about your rates. Read the interaction below for an example of this trick in action.

Joe the Web Designer is working at Psuedonym Software for $70,000 per year. He decides he wants to strike out on his own, so he uses my formula to calculate a starting rate comparable to his current salary. His $37/hr multiplied by 2 is about $75/hr. His target monthly income is $6500, so he divides that by 4 and then by $75 to figure out how many hours per week he needs to work. He comes in at 21; looking good so far. Now he’s in negotiations with his first client, XYZZY Industries. They have a conversation something like this:

Client: So what would you charge for this kind of work?
Joe: Well, I estimate that it would be about 25 hours. At $75 per hour that comes out to $1,875.
Client: Ooh. That’s a little high for us.
Joe: I might be willing to negotiate. What’s your budget?
Client: About $1,500.
Joe: I can do it for $1,600 with a budget of 25 hours. That’s a ten dollar discount off my normal rate. Any hours above that 25 would be billed hourly, of course.
Client: Sounds great, let’s do it!

Let’s go over what has just happened. First, Joe now has a data point about his rates. XYZZY was a little nervous about $75/hour. That doesn’t mean he should lower his rates for all clients, of course. But it does help inform his decisions about XYZZY or companies similar to it in the future.

Second, let’s discuss why Joe got a good deal even though he lowered his rates. Notice that he negotiated from an hourly rate to a flat rate – $1,600 for the whole job (up to 25 hours). In some ways this is a false discount for the company. It’s only $65/hour if he takes the full 25 hours to do the work, and if Joe is smart about how he uses his time there is a good chance it won’t actually take that long. He was also careful to quote the upper bound to the client. If you think a project will take 20-25 hours, always quote them 25. It’s good “potentially saving your ass” practice.

So let’s say he really boogies and it takes him 20 hours to finish the job. Doing the math, we find out Joe got $80/hour for that work, even higher than his original estimate. And the client is happy because they got it done on their budget. Everyone wins.

Now let’s say it really does take him 25 hours or more and ends up being $65/hour. It’s not such a good deal anymore, right? You might be surprised. Keep in mind that every client you have brings some amount of unbillable overhead in the form of communication, estimates, and contract writing. This means there is an advantage to taking fewer, longer projects. The fact that Joe now knows he will get at least $1,600 for his time is worth something.

Let’s take a detour and quantify what a longer-term contract is worth. I usually estimate about 5 hours of overhead for a new client. That includes the work I do to get that project rolling as well as the work I have to do to find them. At Joe’s rates this is about $375 worth of his time. He’s essentially saving himself this money in taking a steady project, so it is still worth it to him even if he has to lower his rates a little.

Of course, this isn’t quite as cut-and-dry as I’m making it out to be here. There are many factors that go into what you charge for a job. Here are just a few possible scenarios:

1. Web design for John’s startup. John is a friend of Joe’s and his company doesn’t have a lot of cash. Joe decides to discount to $60/hour.

2. Building a CMS template in PHP for a local school. Joe really hates PHP and quotes $120/hour, because that’s what it would take for him to actually do it.

3. Design contracting for BigCorp, Inc. Joe raises his rates a little to $85/hour, because he knows the large company can afford it and he has to deal with their annoying marketing team.

The more work you do, the more you’ll know how far you can push different kinds of clients, and how much you believe your time is worth. Use your monthly magic number (see Rule #1) as a guide, and remember that you’re free now to make your own choices about what you earn. No more begging for raises – you just have to earn them yourself.

Rule #5: If you’re not turning away clients, you’re not charging enough.

This is related to Rule #4. Negotiation is good and can improve your relationship with the client. However, if you find that you’re negotiating a lot and not often getting jobs at or above your target rate, you probably need to toughen up a bit and push harder for the higher rates. Some clients won’t be able to afford you and will go elsewhere. However, assuming your rates are fair and appropriate for your experience and work, some will stay and pay it. You never want to be in the situation that you are known for your low rates. Competing on price is the kiss of death.

Think of it as a form of supply and demand. The more you work and the more experience you have, the more your time will be worth. Your rates will go up over time to match the increased demand for your services. Think of it as a promotion, indie-style.

Rule #6: Give yourself a salary out of the “company” bankroll.

One final rule that will help keep you prepared for tax season. You probably want to set aside about 40% of everything you earn for taxes. One way to make sure that you do this diligently is to deposit your checks into a “company” bank account. (You did set up a fictitious business name, right? Of course you did!) Give yourself a “paycheck” out of this bank account once or twice a month, making sure to leave at least 40% of what you earned. If you find that you need to take out more than that to cover your expenses, you need to go back to Rule #1 and revisit your budget. Maybe you need to work more hours or ask a higher rate in order to make your target.

If you’re feeling saucy, you can use the company bank account for business-related expenses as well. Come up with a fair wage for yourself and leave everything else to reinvest into the company — purchasing advertising or office supplies, for example. Working for yourself takes discipline, especially financial discipline. Keeping your accounts separate is a good way to establish a mental boundary between what you earn and what you actually get to spend.

And as a corollary, doing your taxes as an independent is extremely complicated. You will probably want help in the form of a small business accountant. They can help you plan, deal with expenses and invoices and keep your taxes under control.


Well, that was a hefty chapter! But finance is a hefty topic when it comes to being your own business. The next chapter will cover writing contracts, details of invoicing and payment, and making sure your butt is covered legally. Feel free to leave any comments or questions you might have and I’ll try to answer them here. Angry tirades also accepted. Everyone is welcome!

That’s all for now. See you next time for Chapter Two: LeChuck’s Revenge.

A Halloween tribute to punditry

Posted on 31 October, 2008 at 9:36pm with 7 comments

Used jackets and tie from the Salvation Army store: $25.

Hair gel and bobby pins: $7.

Package of corn starch: $3.

Dressing up as your favorite liberal pundits: Priceless.

Colin making his Keith face

Colin doing his “Keith face.” If only one picture could capture the act of wadding up a piece of paper…

Me doing my Rachel face

My “Rachel face.” Things I have that Rachel does not: a billion bobby pins in my hair. Things Rachel has that I do not: jackets that fit, and a TV show.

The news better run.

The news better run!

Black and white and blue all over

Posted on 18 August, 2008 at 12:30pm with 3 comments

Last week Valleywag posted a critique of usability guru Jakob Nielsen, who is apparently now taking some flack for his ongoing criticism of “web 2.0″ design. “Today, though, Nielsen’s dismissal of Ajaxy user generated content comes across as more crank than critic,” the article notes, taking issue with his “garish yellow-and-white design” and “tiresome refusal to use images to convey information and ideas.”

This editorial interested me because I struggle with the same issues as a designer at Google. I’ve watched the web 2.0+ world evolve around us, but our design mentality remains rooted in the early days of the web. Black text, white background, blue hyperlinks. And it’s not just Google and Jakob Nielsen – this aesthetic persists all over the web, despite many designers’ attempts to banish it forever.

Speaking for myself, the sites I use every day are still very much in line with Nielsen’s view of good usability. Google web search, Gmail, Reddit, Wikipedia, Twitter. Black and white and blue all over. Why does it work?

The interface needs to stay out of my way

Every application has a function. Assuming that function is well-implemented and something that I need to use, I will want to use that application. The interface should only be a tool that helps me get to that functionality. The moment I have to think about the interface – even to marvel at how cool the drag animation is – the application has failed in it’s primary purpose. It exists for the function, not the design.

“Now Anne,” I can hear you saying. “What if the point of my application is the experience? My Flickr/YouPorn/Facebook mashup is super-slick and fun to play around with. I get like ten thousand hits a day!”

Okay, yes. These apps do exist, and should exist. They can be anything from neat toys to richly detailed digital adventures. I’m not really talking about these kind of apps, because a user isn’t really trying to do anything with them. They are there simply to experience it.

When you have problems is when you get the bright idea to make your practical application, say a webmail client or a news aggregator, and make it “experience oriented.” A rich, novel interface can certainly give your site impact and memorability. I might tweet about how cool it is and it will probably generate a lot of interest and hype. These are good things, but they reside in the sphere of marketing, not usability. Designing for the launch is a mistake. Getting people to log in on day one is only half the work; getting them to stay is the other half. You want them to come back every day and the novelty of the rich user experience is only going to last so long. When it wears off, can they do what they need to do on the site quickly and easily?

Yes, latency is still an issue

…unless your target demographic really is rich, technologically savvy people with fast internet connections in the United States. Hey, it might work if your margins are really high, but if you’re writing a web app, chances are good they aren’t.

Reddit is… well, Reddit, but I keep going back to it as a source of things to read because it does what it does and stays out of my way the rest of the time. It is literally just a list of links on a page, which is exactly what I’m looking for. I want a service like that to load instantaneously, because I’m likely to hit it many times throughout the day. Waiting for an image to load annoys me. Waiting for a page full of them makes me want to go somewhere else.

If your app is going to have a rich artistic element, it had better damn well be customizable

Imagine if Apple set your desktop image for you. You use your computer every day, and even if it was the most beautiful photograph in the world, you would get pretty damn tired of that image. This situation sounds ridiculous when talking about client products because it’s well known in that world that customization is an important part of a happy user experience. I don’t understand why web developers haven’t picked up on this yet.

iGoogle is a good example of how to do this right. This is an application you’re meant to keep open in a tab all day while it pulls in news feeds and tracks your email and whatever else you configure it to do. When they realized iGoogle wasn’t exactly the prettiest thing to look at, they added user-customizable themes with colorful, rich banner images behind the Google search box. Even better, the image changes throughout the day, so every time you click over to that tab to check your email you might see something different. The end result is that it takes a while to get sick of a theme, and when you do you can always just switch to another one.

User experience is not all about the clicks, but revenue is

You don’t have to take my word for any of this, you know. You can use any number of free tracking tools (Google Analytics and Website Optimizer are my favorites) to learn more about the behavior of users on your site and run experiments with the design. Usage statistics certainly can’t tell you everything – they can’t tell you if your users are happy, for example. And there are some pretty ugly and/or misleading things you could do that would almost certainly increase the number of conversions on your site. I’m not trying to tell you to do these things. The negative impact to your overall user satisfaction and brand would not be worth the increase in clickthrough.

Even still, you have to be running these numbers and aware of them if you want to be an effective designer. “But the green links make users feel good!” is not an effective argument if blue links increase clickthrough by 5%. ROI is not a dirty word; embrace it, and if you keep a record of the data you collect and the tweaks you make, you’ll have a lot of ammunition handy when talks of a redesign come up. The first question you should ask is “What problem are we trying to solve?” and the second is “How can we prove that we solved it?”

The moral of the story

“So Anne,” you ask. “Can I use images or what?” The answer is, it depends. Pretty graphics and colors and AJAX and slickness are all great, when they don’t get in the way of what your app is supposed to do. No matter how you approach it, things that are clickable should be easily identifiable as clickable. Things that are meant to be read should be clear and easy to read. I’m stating the obvious here because it is the precise reason the text + hyperlinks paradigm is powerful and shouldn’t be overlooked.

Just look at Wikipedia. In many ways, it is the perfect web application. How empowered do you feel when you use that site? You have easy access to almost anything you could ever want to know, and anybody who has used a computer in the past twenty years can figure out how to navigate it. Even my grandmother knows blue underlined text is a hyperlink. It’s a big flag that says “you can do something here!”

Now, I know you need AJAX and pretty gradients and buttons to make your webmail client usable and attractive. Do what you have to do to make it work, but at that point you might want to ask yourself if the web is the appropriate platform for that application.

Remember, design is equal parts marketing and usability; approach it as such. Be pragmatic. Don’t mindlessly decorate. And don’t be afraid to use what you know works – even if you are in danger of Valleywag calling out your “so 1990s” design. Own it!

How I got started programming

Posted on 1 July, 2008 at 3:24pm with 8 comments

Note: I was tagged by the wonderful Amy Hoy over at Slash7. This is a great meme; it’s interesting and educational seeing how various professionals got into the business. Other responses I know of: Giles Bowkett, Chris Pietschmann, Erik Kastner, Joe O’Brien, Maggie Longshore, Tim Wingfield, Jeff Blankenburg, and (as far as I can tell) the original post by Michael Eaton. There are many more I’m sure; these are just the ones that came up on Google.

As a side note, it’s amazing how many of these stories begin with the Apple ][. But more about that later.

How old were you when you started programming?

I suppose that depends on how you define programming. I was eight when I wrote this little gem in AppleSoft BASIC (the referenced "Sarah" is my older sister):

20 GOTO 10

I'm not sure if you can count that as programming, however. It's more like electronic vandalism. (Watching her figure out how to stop the loop was always fun.) I also liked to make pictures on the Apple ][ monochromatic greenscreen by painstakingly plotting every point; again, this "program" can only dubiously be labeled as such. At the time, I didn't even know how to save my work, so they were all blissfully transient.

BASIC nuisances aside, the first program I wrote that a normal person could actually use without having to shut off their computer to stop it was a calendar application I built in PHP many years later. I was 19.

How did you get started in programming?

It all started with this machine, still in usable condition over twenty years later: the Apple ][.

These pictures were taken only a few months ago in my parents' basement. Depicted is the ineffable Colin Barrett poking through the user's manual and trying to get it to load AppleSoft; unfortunately, the floppy itself had long since gone bad. In an era where most of us get an AppleCare plan on anything and everything, it's pretty amazing to think that this machine has outlived the very media that its operating system is printed on. But I digress.

What's amazing about the Apple ][ (and // and other related models) is that it provides excellent affordance for programming. As soon as you boot it up you are provided with an inviting, blinking cursor, a prompt at which you can type straight-up BASIC and be immediately gratified with a response. The built-in BASIC interpreter was probably the single most influential factor on my technological growth, and judging from the articles others have written I’m not the only one. Think about it; in today’s era a child using a computer has to take several complicated steps to get to an environment in which they can program. Back then, all you had to do was turn on the machine.

What was your first language?

BASIC and Logo. I learned both from a children’s guide to programming (unfortunately I can’t remember the title anymore).

What was the first real program you wrote?

The first “real” program I wrote was a trivia game written in BASIC when I was about ten years old. The user could input their name and then answer a series of multiple-choice questions, mostly about animals or science. Since the whole program operated on GOTO loops (hot tech, I know), getting a question wrong meant only that you would go back to the question and get another opportunity to answer. It was therefore impossible to get to the end with anything but a perfect score. It was, uh… a very forgiving game.

What languages have you used since you started programming?

BASIC, Logo, Pascal, C, HTML, JavaScript, AppleScript, ASP, PHP, Ruby, Python, Objective-C. As you can tell, my experience is definitely skewed towards web development and the Mac OS.

What was your first professional programming gig?

My first real job in college was working as an assistant webmaster for the school of Mechanical and Industrial Engineering at the University of Illinois. I had been making web pages in my free time for quite a while, but this was my first exposure to web programming. I was mostly hacking on existing ASP code the previous webmaster had written. It was scary, to be sure. I was an English major at that point and considered myself more of a designer than a coder. But reading and debugging this person’s code was actually a great way to learn, and I put myself through college with various HTML/ASP/PHP web development positions.

If there is one thing you learned along the way that you would tell new developers, what would it be?

I want to re-state something that Aaron Hillegass often says in his book Cocoa Programming for Mac OS X. This is hard work. It’s tough thinking and sometimes the problems are hard to solve. But you are not stupid. Repeat that to yourself. You are not stupid. Don’t give up before you’ve even given yourself a chance.

I feel that what keeps most people out of programming is fear. Fear that they will fail, that they’re not smart enough, that they don’t understand what makes the computer go. You need to understand that it’s not a strange new world; it operates by predictable rules in a predictable system. Learn the rules and use your brain. Don’t be afraid to think, and don’t be afraid to take risks.

And finally, don’t bite off more than you can chew. Any learning process is best taken one step at a time. Learn to type before you code.

What’s the most fun you’ve ever had programming?

That would actually be quite recently. As much as I love engineering, computers and problem-solving, I’ve had quite the love-hate relationship with programming over the course of my life. I’m fascinated by the power it gives you, but often appalled by how it is implemented. “This isn’t intuitive at all!” I would exclaim whenever a particular programming language’s syntax confused or frustrated be. Syntax in general has been a large barrier for me, and as a result I’ve often avoided programming whenever I could.

But then, in April of this year, I came across a project at Google that demanded automation. There was simply no other way to do it. I needed to generate over a thousand static HTML files and over four thousand screenshots across 14 languages. It was the largest marketing campaign we’ve ever done. And I needed to do it in just under a week, also accommodating time for QA and bug fixes. Doing it by hand was simply not an option.

I turned to Colin and said, “There’s a way to automate this isn’t there? There has to be. Otherwise it’s just not going to happen.”

He knew of a FireFox extension that could be accessed from the command line to take and save screenshots, so that’s where we started. He showed me some Python; it was my first exposure to the language. But Python is Python, and I was up and running within hours. And much to my surprise, I loved it. I took to it immediately. It was stupid, procedural programming, and certainly didn’t take advantage of Python’s more sophisticated OO features, but it worked. Within a day I had a script that processed the data files out of the spreadsheets they were in. In another day I was running one that would open the URL in all the appropriate languages (command line), take the screenshot (FireFox extension), open the screenshot in Photoshop and run an action on it for cropping/resizing (AppleScript), save the file and scp it to the proper location on the server (command line), and then move on the next one. Python was the glue that held all of these parts together; os.system was my friend.

A few days later I had made HTML templates that represented the static files in the project, and had another script which inserted the proper strings for all the languages and send the generated HTML files to the server.

For perhaps the first time since I was eight and using BASIC to harass my sister, I was really enjoying programming. It was empowering me. I didn’t feel trapped by it; Python is a beautifully intuitive language and quick to learn. And if I got stuck, I could ask Colin or find resources online. I realized what a large support network I have for programming, and how valuable of a resource that is too. It was wonderful.

And it worked. At the end of the day, the campaign launched successfully worldwide, when by any other means it would have been impossible.

Since then, I’ve had a better relationship with programming. I respect it, and I feel like I know how to make it respect me. I also know better how to approach learning it, and understanding it. And I know now that it’s worth it.

Phew. Sorry to ramble so long, but this is actually a subject quite near and dear to my heart. It’s an important part of my history and even my identity. Now then, here are a few people I would like to hear tell their story:

Mark Dalrymple
Aaron Hillegass (a pipe dream, I know… but I’m sure he has a good story to tell)
Mike Lee
Joe Heck
Jonathan Wight
Victoria Wang
Elliott Harris

A few free pixel icons

Posted on 26 June, 2008 at 8:43pm with 2 comments

I recently decided to practice my iconography skills by making some small web-related icons with nothing more than the pencil tool and a limited color palette. It was fun and educational, and the best part is that I have a set of 36 juicy icons to show for it! It’s deliciously pink and green, and I call it “Materwelon.”

I’ve done some fake anti-aliasing to soften the edges, so these icons will look best on a very light or white colored background. They all fit into a 16×16 square and I have prepared a .png that contains them all in a grid for easy CSS sprite-sheeting. Here’s an example of how you might use these in a webpage, and here’s the sprite sheet with all 36 icons. Feel free to use them however you please.