Meet the devigner
Or why we will see a new breed of web workers.
If you work for a company that does web sites, and this company passes a threshold of, let’s say two dozen employees, chances are that these people are divided into departments with distinct specialities. Typically, the division follows the lines of ‘designers’ and ‘developers’, also people who create concepts and do project management, accounting, etc. - but let’s focus on designers and developers. Chances also are that this company follows the inevitable path of the waterfall more or less (even if they claim not to), i.e. some one writes down the requirements of the client, hands this over to the guy who writes a concept, passing the ball to the designer who takes the wireframes and creates the graphical presentation. At the end of the chain there is the developer with the honorable duty to write code that hopefully meets the expectation of a client.
The upside of this concept is that the reporting lines are clear: the designer reports to an art director (i.e. a guy who is superior in design skills and does management), and the developer reports to a technical director (you know).
The downside is pretty much everything else. Projects tend to last longer than they need to, the result is not as good as it could have been, format conversions all along the way and at the end of the day no one is really happy with what was achieved. In the worst case it ends up with something that nobody wanted.
One possible countermeasure is to put all the people in this process into one room for a given time (including the client), apply some agile development magic and hope for the best. Yes, this may help, but this doesn’t address the main problem that arises from the distinction of the job description - devs are devs and artists are artists.
Meet the devigner - the person who does design and development.
Once you allow a mindset in which a developer understands that we left ASCII graphics on a VT-52 terminal for a reason (and I say that with deepest regrets) and the designer understands the implications that his art imposes on the code monkey you become a devigner. As Mark Otto puts it in his awesome blog post: designer and developer roles are a spectrum. People who are doing design and development equally well may be rare, but an equal proportion of these skills is not important as long as you are aware of your position in the spectrum.
The devigner concept doesn’t come up naturally because our web development flow is broken. We simply lack the proper tools to support devigners. We should “stop drawing dead fish” as Bret Victor points out (also watch Inventing on principle, worth every second!), implying that we are still in a computer stone age of doing graphics in one application and adding code in the other instead of doing a form of art that these machines could enable us to do.
Becoming a devigner won’t be straight forward as neither your manager or your company will support this right off the bat (they made departments for a reason, right?). It may mean you have to do side projects (or side-side projects) as Sacha Greif puts it, i.e. selecting small projects for yourself and just do it.
Still there are early devigners paving the way for the rest of us, raising awareness of these issues and slowely but surely create the need for tools and different ways of thinking.
