Design well managed(algrim.co)
algrim.co
Design well managed
http://algrim.co/posts/11-design-well-managed
6 コメント
[deleted]
This might be an unpopular opinion, but I've seen the exact opposite of this. Given too much freedom, I've seen designers and product managers derail entire development cycles. Compare a few days for a single designer against two weeks for even a small development team and not only have you lost an amazing amount of money, but the opportunity cost of not getting something into the users' hands and iterating on it is huge.
For the same reason I've also pushed for aesthetic changes to be moved to following iterations. If your wireframe is solid and agreed upon up front, then iteration can happen on both the development and the design side as you move forward. I think it's alright to release something that isn't fully baked because what you learn in the end is so much more valuable than trying to get it right the first time.
Bottom line: get something out the door and iterate. Too often people don't do either. Either they try to perfect it and take too long to learn from it, or they push it out and move on to the next thing. Nothing is going to be perfect the first time, so just get it out there and continue to work on it. Just because you're targeting a feature in a single iteration doesn't mean you should forget about it afterwards.
For the same reason I've also pushed for aesthetic changes to be moved to following iterations. If your wireframe is solid and agreed upon up front, then iteration can happen on both the development and the design side as you move forward. I think it's alright to release something that isn't fully baked because what you learn in the end is so much more valuable than trying to get it right the first time.
Bottom line: get something out the door and iterate. Too often people don't do either. Either they try to perfect it and take too long to learn from it, or they push it out and move on to the next thing. Nothing is going to be perfect the first time, so just get it out there and continue to work on it. Just because you're targeting a feature in a single iteration doesn't mean you should forget about it afterwards.
The point about challenges over tweaks is great, but I don't understand the headline.
From the green button example:
> A great designer can change the UI elements on a Photoshop document in about an hour. You have a one-hour meeting to provide feedback. Three days to produce changes.
How does he get from two hours to three days? An hour for the mockup, an hour for the meeting... and 22 more for changing the css?
From the green button example:
> A great designer can change the UI elements on a Photoshop document in about an hour. You have a one-hour meeting to provide feedback. Three days to produce changes.
How does he get from two hours to three days? An hour for the mockup, an hour for the meeting... and 22 more for changing the css?
Thanks for the comment. The estimation is for a series of feedback items which is fairly common for those types of sittings. In general you can expect a 3 day churn.
>Multiply that by how many team members involved in the meeting
Are you multiplying the full three days by the number of people in the meeting or are you just multiplying the hour of meeting by everyone in the meeting? The 4300 figure would be 100 hours or 3 days for 4 people. Even if there are a few changes, it sounds more like 4 people talking about changes and one person making them, which even with 3 days of changes would only be $1200. The other 3 people can work on other things during those 3 days.
Are you multiplying the full three days by the number of people in the meeting or are you just multiplying the hour of meeting by everyone in the meeting? The 4300 figure would be 100 hours or 3 days for 4 people. Even if there are a few changes, it sounds more like 4 people talking about changes and one person making them, which even with 3 days of changes would only be $1200. The other 3 people can work on other things during those 3 days.
A lot of folks are asking about the math breakdown. So here it is:
- 3 employees discussing design at $110/k/y or $43/h napkin - 1 founder discussing design at $90/k/y or $36/h napkin - 1 meeting — $165
3 days of work to follow: - 1 designer making edits — $903 - 2 working on projects related to said design — $1806
Total: $2874
- ~2 hour meeting to discuss, examine, make notes, etc. — $335
Total: $3,209.00
- Opportunity cost of founders 3 hours — $1,100 napkin (based on potential hourly value not pay)
Total: $4,309.00
Please note this is generally napkin math based on my own experiences & numbers. It is generally impossible to get an exact number but you can get very close.
- 3 employees discussing design at $110/k/y or $43/h napkin - 1 founder discussing design at $90/k/y or $36/h napkin - 1 meeting — $165
3 days of work to follow: - 1 designer making edits — $903 - 2 working on projects related to said design — $1806
Total: $2874
- ~2 hour meeting to discuss, examine, make notes, etc. — $335
Total: $3,209.00
- Opportunity cost of founders 3 hours — $1,100 napkin (based on potential hourly value not pay)
Total: $4,309.00
Please note this is generally napkin math based on my own experiences & numbers. It is generally impossible to get an exact number but you can get very close.
>2 working on projects related to said design
Why is this included? If two people are working on the back end for a widget, and the designer spends 3 days changing the colors of buttons and types of sliders on a widget, why does this mean that the two people working on the backend aren't making their usual progress in the meantime? Maybe they lose a few hours of time to integrating the design changes, but a few days?
Why is this included? If two people are working on the back end for a widget, and the designer spends 3 days changing the colors of buttons and types of sliders on a widget, why does this mean that the two people working on the backend aren't making their usual progress in the meantime? Maybe they lose a few hours of time to integrating the design changes, but a few days?
> A great designer can change the UI elements on a Photoshop
> document in about an hour.
Why, then, do people still use the digital equivalent of painting on canvas? An effective design agency would come up with the overall information architecture including layout, font, and recommend color scheme based on the client's brand. Then give the client a very user-friendly tool to adjust the elements that the designers have specified as being configurable. The design agency can put whatever constraints on it they want, but then let the client have at it while the designers guide the client through the whole design process, offering feedback on why something does or does not work.
> Why, then, do people still use the digital equivalent of painting on canvas?
Because anyone who pilots Photoshop can use the title "web designer" and still get hired. It's somehow accepted by most in the industry that the work of a designer stops at a mockup.
> An effective design agency would come up with the overall information architecture including layout, font, and recommend color scheme based on the client's brand.
This is what designers are supposed to deliver. In the real world, the managers will ask for a mockup of the product, something they can show to stakeholders right now to show progress, and that will almost never be implemented because requirement changes/flaws will be found during development, and the design ends up being realized by the developer. I've worked on / know about a handful of companies where the process is exactly this.
Because anyone who pilots Photoshop can use the title "web designer" and still get hired. It's somehow accepted by most in the industry that the work of a designer stops at a mockup.
> An effective design agency would come up with the overall information architecture including layout, font, and recommend color scheme based on the client's brand.
This is what designers are supposed to deliver. In the real world, the managers will ask for a mockup of the product, something they can show to stakeholders right now to show progress, and that will almost never be implemented because requirement changes/flaws will be found during development, and the design ends up being realized by the developer. I've worked on / know about a handful of companies where the process is exactly this.
Or you could do the smart thing and hire a designer that can sling front-end code worth a damn for $150k, and the feedback cycle becomes much cheaper and faster. "Let's see it in green" should take no more than 10 seconds, and can be done in-meeting.
As an aside, that sounds a lot like design-by-committee, which isn't known for producing the greatest results. If there are problems with the design (not branded enough, important button isn't emphasized enough, etc), then make sure that the point of the meeting is to highlight those problems and let the designer take care of the solutions later. If a (non-designer) founder is picking button colors, that founder isn't delegating properly.
As an aside, that sounds a lot like design-by-committee, which isn't known for producing the greatest results. If there are problems with the design (not branded enough, important button isn't emphasized enough, etc), then make sure that the point of the meeting is to highlight those problems and let the designer take care of the solutions later. If a (non-designer) founder is picking button colors, that founder isn't delegating properly.
> A designer is paid ~$110k/y on average in San Francisco. Scratch figure of $43/hr. A great designer can change the UI elements on a Photoshop document in about an hour. You have a one-hour meeting to provide feedback. Three days to produce changes. Multiply that by how many team members involved in the meeting, plus the daily burn of the Company. For a cost- effective average startup, that's around $4,309.00 every time you provide feedback.
This math doesn't add up. I don't know what companies the OP is basing his assumptions on, but a "cost-effective average startup" doesn't spend $4,000 every time a designer is asked to change a color or form element.
There are some good points in this post but hyperbolic warnings like this take away from them.