1. Take input from everyone.
2. Envision how you want the company to function, then make it so.
3. Ship stuff.
These points are so fundamental, and repeated nearly every day on Hacker News. Yet nearly every company I've worked at misses one of these points, and even when I work on my own projects I have to force myself to take feedback and to "just ship it". I don't have anything super meaningful to add other than the realization that this is all really good advice, and after having it pounded in my head over the past 2 years I still have trouble putting it into action. My ego must be huge!
I enjoyed the article, but I was sort-of hoping that this was an article giving practical design advice to non-designers, because that' what I gandered from the title and that's the position I'm in right now.
I'm handling the (re)(re)design of our site[1]. This is a bit tough because my main job is JS library developer. There are no designers at my very small company, and my own time is constrained as one might imagine. So instead of a real design, I try to re-look at it and pass it around for advice and update it shortly after version releases.
Since I can't give it my full attention, I'd really love to read an article on what do do when you're the only designer they've got, and you're not a designer by trade.
(On the plus side, its nice switching contexts to something more artistically focused from time to time.)
[1] The library has been out for a year and I think just now my designs are finally starting to look "not completely shameful". Old: http://gojs.net/latest/ New: http://gojs.net/beta/
At least I can take #3 to heart. Good for now, and it will get better. (and maybe I will, too)
> So instead of a real design, I try to re-look at it and pass it around for advice and update it shortly after version releases.
Feedback and iteration are crucial parts of a real design process.
> (On the plus side, its nice switching contexts to something more artistically focused from time to time.)
Even visual designers spend a lot of their time doing analytical methodical development of grids, colors, and pixels. Art and aesthetics is only a small part of it.
Designers learn best by working with other designers but this is becoming increasingly rare. The PDG holds events where designers come together, everyone brings work and you work collaboratively with other designers in a studio style environment.
We're current 500+ members strong across Bay Area, New York & London. It's one of the only places in the world where you regularly get to see work-in-progress from companies that you don't work for.
First, this is a very bad situation for a junior designer since they basically get no mentorship. The studio model is very important for developing design talent. Don't take on junior talent without senior talent if possible.
Second, expecting designers to code, a common meme repeated often on hackernews, is even more disastrous in this case; they are overloaded already with design work (and even if you have a few designers already, they will still probably be your bottleneck).
As a designer who codes I've never understood this mentality. I sketch out wireframes, take them to PhotoShop, and flush out the HTML, CSS, and JS. Perhaps if the structure of your team isn't suited for this workflow it could end up hindering the design process but I find it to be quite enjoyable.
So you do design and production (is HTML/CSS and a bit of JS really coding?), great! I have a feeling most web designers are in that boat, though I've never worked in that field before. Not all designers are web designers though.
there is definitely a difference between knowing how to make a prototype and being able to code at a production level. Again, without mentorship it's difficult to learn the difference.
Most developers are clueless as well. I can imagine a junior designer getting into a lot of trouble in a small dev shop given all the misunderstandings.
I totally feel for #3. Probably the best advice you can give sole designers at any growing startup: "‘good for now’ earns opportunities for ‘great’ later on"
1. Take input from everyone. 2. Envision how you want the company to function, then make it so. 3. Ship stuff.
These points are so fundamental, and repeated nearly every day on Hacker News. Yet nearly every company I've worked at misses one of these points, and even when I work on my own projects I have to force myself to take feedback and to "just ship it". I don't have anything super meaningful to add other than the realization that this is all really good advice, and after having it pounded in my head over the past 2 years I still have trouble putting it into action. My ego must be huge!