I suppose the biggest caveat to this is that it requires projects with a 1+ week duration. A lot of our work is smaller, and as such can be completed in an hour or two. We'd be back to billing 0.10 of a week for 4 hours of work, for example.
I quite like the day/half-day workflow employed by many freelancers. I think that makes sense, and it also gives the designer greater freedom and flexibility to do "good" work.
Hourly billing is by it's nature quite restrictive, as you're aware that you want to ensure the client is only paying for the hours you're actually working. It's open to both over-servicing, and under quoting as it requires accuracy from all parties.
But still, why not charge by project or work but time? Charging by time feels like:
punishing yourself for being good at what you are doing and quicker
overcharging customer if you are slow
making the conversation about "how many hours they can buy?" rather than "what do they want/need?"
it exposes you to end up in a conversation like "why a logo took 3h42m to make not 2h30m?"
It doesn't mean that you still can't consider how long time would a project take (plus or minus) and reflect that on your price.
Not that I'm all for hourly rate but just to answer your points:
It'd be the opposite. You could charge more than other designers because you do it better and faster.
If you can find clients to hire you at the rate you are happy, awesome.
You'll going to have the conversation either way. It'd just change to how do you come up with the price tag for this project.
You can explain that in less than 5 minutes. It's part of educating the clients.
With #1, couldn't you just charge more on a per-project basis? You're talented, your work is worth $5,000 for X, while designer #2 is worth $1,000 for X. Plus, again it doesn't hurt you if you complete the work sooner.
What I'm saying is, in the end, fixed & hourly rate are the same thing. see #3
I personally break the project scope into line items and attach working hours to each line. The total fee is fixed or time then? it's the same.
I'm not sure I understand #3.
What do they want/need is surely the question asked at the beginning of the conversation then you still need to estimate how long it will take.
If someone says they need "a way to help their users better filter products when searching their eCommerce site" how do you estimate how long it takes - I've never had a client sign off on something without at least an estimate of how long something is likely to take.
It's not like anyone can reasonably say a job will take exactly 3h42m but you can at least ballpark something based on experience and your skill to give a client a rough idea of what to budget.
The other way we often try to work is to establish what their budget is first - oddly, in web it often seems like asking for a budget is a shady thing and clients think they should keep it secret. We try to reverse this and when we have an idea of budget and project requirements, we'll deliver as many features as possible within that scope.
For most projects, I like to charge a daily rate. Most of my projects end up being between 1 and 1.5 weeks long. I also attach a schedule that summarizes what I plan to do and how many days of work each major task will take.
If the project ends up being more of a "day project", then I can can charge a full day or 0.5 day rate.
My clients seem to understand this format. I'd be interested to know if anyone else is doing something like this?
The (sometimes massive) discrepancy between how much work a project takes from a client's perspective and the actual amount of work required is one of the bigger challenges here, no?
I'd be interesting to see a meta-study or a retrospective on how different these are, on average.
Personally, I work in 2 week sprints. Client/Partner pays to budget the sprint and the rest of payment is given on delivery. If we like each other and things are going smooth, we continue on and draft up another 2 week sprint. This keeps us non-married in contract, and less risk for both parties. Has been working out well for me.
I have a similar approach. Also work in 2 weeks cycle for a fixed price. At the beginning, I define what goes into these 2 weeks – together with the client, based on his requirements. What I'm able to deliver in this time is of course based on my experience. If the clients don't do their part, it's possible that I'm not able to deliver all the things, but I'm still getting paid. Because I also have blocked the time from my schedule to fully commit my time and focus to this project.
This is basically what SCRUM/Agile is like. Clients buy a chunk of development time and set priorities. Challenges with this approach with a fixed pricing model is that you're limiting the number of projects you can work on at the same time. Also I imagine that clients comparing vendors are confused by this approach. Agency A charges me $3000 for a website, while Agency B charges me $8000 for a week of work of 4 people. Next to that, Say a project goes fine on monday and tuesday but on wednesday 'shit' happens. You can't transfer to a different project until monday.
What works best is to basically set goals and a budget ceiling with your client in advance but don't limit yourself to a pre-defined timeframe or a single pricing model even within the scope of the project. Building something you've done plenty of times before like a WordPress site can be a fixed rate while the custom tailor made animation might be billed hourly.
Also give your clients an option to extend the scope of the project. Like, well after one iteration as agreed this is the design, which is o.k. but we feel it could be improved with a little more time and better photography which costs 'X'.
As someone else mentioned. Clients are usually not up front about their budgets. And most have no clue what anything costs. The quotes they receive might also vary from $300 to $10000 which isn't helping.