AlternateIdea

The Real Reason Designers Don't Contribute To Open Source

Discussion

1. oblivious@subtleGradient.com said on August 28th

   I’m just glad there are a few of us around that walk the line between those two camps.

2. Androse Rosewood said on August 28th

   Ahah, I experienced that same exact scenario a few years ago (“what, MacOS 9 doesn’t run X11?!?”, “We don’t want you to rethink the way the app works, we want you to make it pretty!”, etc).

   So I learned how to use svn.

3. Scott Superb said on August 28th

   hahaha. That was so well written and I can relate totally as I have been on Designer side. I’ve only recently learned SVN after diving into rails and I took a similar path.

   Want to learn rails… installing rails from source is better… installing from source? what the…lighttpd/webrick? should use versioning (svn)... how do I version code and what’s the best ways.

   As a designer I took each step as a small learning curve and just stuck with it. No point fighting with developers, they do things for a good reason (most of the time)

   This is a common problem, yet one not easily solved. When you’re heavily involved in one aspect(design/development) you tend to forget about the other side of the fence.. and just presume they’re on the level.

   PS: Loving your prototype enlightenments by the way

4. Scott Superb said on August 28th

   Out of interest Justin, which were you first?

5. Andrew Turner said on August 28th

   Sadly – this is definitely the case. I’m on the developer side and am always on the lookout for designers willing to help out on Open-Source projects.

   The two-sides usually work in different circles, and it’s very tough to pair them up, especially early in a project when it may just be an idea in the developer’s mind.

   It reminds me of boys & girls in middle school. They really want to meet, but they’re really not sure how to talk to one another -

   Any suggestions on better methods for 1) developers & designers matching up and 2) how to work together better?

6. Justin Palmer said on August 28th

   @Scott: I was a designer first. I always tell people design is my profession, but programming is my hobby.

   @Andrew: Good questions. I posted a slightly dated response to the last question back in 2005.

   I think a designer needs to be on board from the start. Design drives development, it should never be the other way around. I always compare it to putting the dashboard in a car. If the developer is responsible for wiring it up and the designer is responsible for the interface, think how screwed up the interface would be if it was wired first? Sure you might have shiny buttons and rounded edges, but it’s hard to change the radio station when the knob is on the passenger side of the car.

   Find common ground with a designer, visual tools if you can. Always make the assumption first that designers have no clue what your talking about and be humble and helpful about helping them get aquatinted in your environment. After all, it’s Designers who are being thrust into a Developers world. You’ll likely never be asked to open Photoshop.

   As far as finding Designers, there are so many designers out there who want to help on open source projects. Visit design forums, go where they hang out. Take your project to them, but don’t take it to them after the fact and don’t take it to a ‘real’ designer if your not up for listening to what they have to say. Design is not eye candy, nor is it common sense, it’s a very complex skill developed over time.

7. Anonymous said on August 28th

   Design drives development, it should never be the other way around.

   True. But the best designs always take the underlying technology into account. In software, this usually means that the designer has to also walk the development line to some degree.

8. heyotwell said on August 28th

   At times I’ve put it to developers like this: how soon did you start your data model? That’s when you should have started the UI design, or sooner.

   I’d be interested in seeing this same post from the other point of view: the Designer who has an idea for an application and tells the developer to “just wire it up.” :-)

9. Nate Cavanaugh said on August 28th

   I have to agree with this 468%.

   Even though our CMS, Expanse, was designed by artists, for artists, it still can be a chore to find the balance between design decisions and programming decisions. And we’re not even open source.

   A huge problem with it is that designers and artists DO NOT react well with collaborating with programmers.

   Even most template systems, supposedly there to help the designer end up causing more confusion (of course, because they’re written by programmers).

   What the world needs more of, is people like you Justin, Shaun Inman (and I’d conceitedly put myself in that category) of designers with a programming capability.

   We have a responsibility to help bridge the worlds of design and programming to help them communicate.

   Then there is also the “how do I benefit” side of things. Personally, one of the reasons why we charge for Expanse is that we wish for it to become self-sustaining enough to allow us to devote our full attention to it, as well as to our customers.

   We all have families to feed, bills to pay, and by charging for a product, it allows us to do that, and hence we can deliver more personalized service.

   This isn’t a condemnation of open source, but more a explanation of why most creatives aren’t too hot on giving away their time and abilities for free.

   Perhaps the paradigm difference between programmer and artist goes even deeper than we know, all the way down to open source vs. closed source, free software vs. paid.

   Or maybe not :)

10. Dushan Wegner said on August 28th

    So true. I have worked as webmaster for quite some time, which meant coordinating the ideas and wishes of management (“I pay it and I want more colors for my money”), the proposals of designers with black-rim-glasses (“there has to be a complete shift in the user´s interface-aproach”) and the tech-folks (“nope, that is the registrar´s/dns-provider´s/whoever´s-fault – but have you seen that the server is 20% faster now?!”).

    (Let’s not forget that we are talking about clichés here. There are people who see the larger picture while being great at their very specialized job.)

    My guideline is that there are two things you have to keep in balance:

    A) The User Experience – which sounds vague, but maybe is possible to define in these three questions:

    1. Is the user able to access his information in an maximally effortless way? (Which usually means: Is the interface intuitive and effective?)

    2. Is the software beautiful? (There are different kinds of beauty.)

    3. Does it feel trustworthy?

    Great (web-)apps aim at all three of these goals.

    B) The other thing a coordinator (webmaster, integrator, intermediary) should put in balance is the motivation of the partners in the website creation:

    1. The Manager (or customer etc.) – If he is not motivated and happy, your job is gone. Face it: Sometimes it has to be the flash animation extra. Because: Maybe it is the crappy flash-animation that helps that manager sell your project to his manager who is a complete moron, yet likes to see the company logo spinning around.

    2. The Designer – If she or he has a track record of successful design, trust him or her on the innovative approach – yet carefully. There rarely is only one right way to do things, especially in design. Beauty and appreciation often are something that is not appearent at first sight. And if something turns out to be very wrong and customers complain, you still can have it changed.

    3. The Programmer – Some psychology is needed here. Some of them deserve more the term Hackers. Crazy features go over stability and foresight. But: You don`t want to fire them as they sometimes bring up the wild ideas that put you ahead of competition. And then there are those who 4 months after project kickoff are still working on their table relationship plans. There has to be a balance here. If you are lucky, you will succeed in making them adapt stability, technical beauty and (cleanliness, compartmentivess etc.) fast development as their personal goal for your software.

    Well, that was my two cents… keep smiling! :-)

11. Yehuda Katz said on August 28th

    I’m one of that rare breed of designer/developer. I did a (long) stint as a newspaper designer for my college paper, racking up a number of design and general excellence awards.

    I also enjoy programming. A lot.

    One of the things that I find is that there’s usually an easier way to make things work than the raw coders think. For example, many developer types shun GUIs like Tortoise (the Windows svn client). It makes sense. They like having control of the code.

    But for folks who are interested in getting work done, and don’t want to know every little piece of every little thing they do, GUIfying everyday tools like svn can take a ton of the edge off getting work done.

    The discussion above can apply to new developers as well. Just because someone has coding skills doesn’t mean they ever used svn. Myself, I just started using svn around six months ago, and getting up and running was a bit confusing at first.

    Now, I can get any new coder who works on a project with me up and running via svn rather painlessly.

    The underlying issue is more about separation of concerns than anything else. Developers need to internalize that understanding svn is not actually related to understanding web development.

    Sure, it’s nice. But it’s quite reasonable for someone with good programming skills to have simply never encountered version control systems, and svn in particular, before.

    It’s even more reasonable for designers.

    In the end, it comes back to good documentation and a good community. If it’s easy to find good “Getting Started” documentation that doesn’t require a degree in technical writing (or experience reading API docs), the barrier to entry is dramatically reduced.

    And that’s a good thing.

12. Bob Aman said on August 28th

    Also known as: Why programmers need to be designers on the side.

    Previous commenter sort of beat me to it though.

13. Gabe said on August 28th

    This post is funny and scary. I came up as a designer, but I have a talent for programming, so I always found that’s where my skills were needed. For the last 6 years I’ve done 85% programming, 15% design.

    In real world teams you need to accommodate your people. I would never throw a designer at SVN. Maybe some Smarty or ERb templates if they were somewhat savvy, but most likely I would say just save some screens as HTML and have them design those as mockups and then re-integrate them into the templates myself. Yes, it’s more work that way, but you have to work with what you’ve got. If a designer knows CSS and how to create lightweight HTML that is uniform enough across pages to break down easily into a template then I consider that to be pretty good.

    On the other hand look at programmers. If a programmer isn’t a HTML/CSS expert, not to mention HTTP, browsers, and the rest, then the project is really going to suffer unless the designer can hold their hand the whole way through (which is particularly unreasonable in an open-source context).

    Create a team out of talented Dreamweaver designer, and a talented GUI programmer and see how long it takes to make a usable web application.

    I think the division of duties is not the important thing, but rather that team members have some overlap on which to relate. Even the use of ‘designer’ here is ambiguous, because there is a whole set of skills that a given designer may or may not have: browser compatibility, UI design, graphic design (vector / raster / animation), copy editing, usability testing, javascript / ajax flow. It’s never as simple as “Let’s get a designer to make it pretty.”

    The flip side of this, for web programmers as well as designers, is to diversify your skills. If you can create a team where all the members have a cursory understanding of the entire stack (or at least the adjacent parts) then your productivity can approach that of a single mind with no cognitive dissonance.

14. Tomas Jogin said on August 28th

    Amen, amen and amen. The problem lies, of course, in how programmers want to “pretty up” an application, whereas the designer, assuming he/she is any good at all, wants to make it more intuitive and user-friendly, first, and pretty it up secondly.

    John Gruber previously wrote something similar, also well wort a read: http://daringfireball.net/2004/04/spray_on_usability

15. tim r said on August 28th

    You have, of course, all heard of svn tortoise? http://tortoisesvn.tigris.org/ We’ve had all developers & designers using this without (too much of) a problem :>

16. Rida Al Barazi said on August 28th

    Very true, I experienced the very same scenario but worse, it was not an open source project it was supposed to be a paid web application..

    I guess this should convince both designers and developers to have a better common knowledge of each other work, designers should know have some development background and developers should have the same about design and UI.

17. Kuswanto said on August 28th

    LOL..i have been there. But i was using CVS on that time.

18. Kyle said on August 28th

    Love it man, love it :)

19. Justin Palmer said on August 28th

    @kyle: Hehe, thanks. It was your post that sparked this one. I thought this would help better convey the frustration.

    @heytowell: Thats pretty much how we develop Mephisto. We identify the problem, have a quick talk on how we think we can solve it and then the UI usually comes. After I have the UI checked in Rick does his part and we keep these short, fast iterations up until we’re comfortable with it.

    @Anonymous: I agree 100%. Designers who have a general understanding of the underlying technology will do much better in an open source environment. Designers need to be able to create and modify the constructs in templates. Whether it be a template language or purely the language itself, designers need to educate themselves on this.

    The problem here is that by the time the designer starts making design decisions his confidence level is at it’s lowest because he just spent 5 hours asking ‘newbie’ questions in the developers mind. He/She is less likely to defend his design decisions after that ordeal. And the process will continue to repeat itself if a) developers don’t show a willingness to help and b) Designers don’t show a willingness to self-educate.

    You have to show a mutual respect for each others profession. It’s like a marriage, it takes effort by both parties to make it work.

20. kentaromiura (mykenta.blogspot.com) said on August 28th

    firebug give me a error in your blog:
    

    element has no properties 
    prototype.js (line 416) 
    anonymous
    onmouseout

    btw I using firefox 1.5.0.1

21. Andrew Norris said on August 28th

    Nice post, and dead on.

    From a programmer’s point of view, I think the problem is that yes, a designer should have been involved when you formulated version 0.1 in your head and wrote your roadmap. But he wasn’t, because you didn’t find a designer until your project got far enough along for people to start finding out about it.

    So your main options are to: (1) gut the project plan to accommodate some really good ideas that require serious rethinking of key components of the application, or (2) ask the designer to try to put lipstick on a pig (“make it pretty”) and defer all the really cool major rethinking until you start planning version 2.0.

    While I can understand why designers would be less than thrilled about option 2, ripping apart your project to accommodate new ideas is hardly a panacea, no matter how good the ideas are.

    Usually, the best compromise solution in the short term is to brainstorm ideas for improving the project’s design, use cost-benefit analysis to figure out which of the ideas can be squeezed into the plan without causing too much collateral damage, and defer everything else until a future version—when you can incorporate a designer at the earliest stages of planning.

    Of course, working toward this kind of solution requires an awareness that the designer has valid concerns, and that design goes beyond producing pretty pictures for your icons. There are plenty of programmers that don’t know this.

    Personally, though, I think the most annoying programmers on this score are the ones who think they are just as good as a professional designer just because they taught themselves to use Photoshop. Yes, there are a few that legitimately have a professional-grade eye for design. But the rest of us programmers do a lot better when we admit our limitations.

22. lionel said on August 28th

    It is exactly what i daydream each time I use Gimp. The Gimp is so powerful, that no pro use it. Each ergonomic suggestion (from real user like professional design) is received with scorn and thrown away.

    It’s so sad that such a lovely piece of code is a mess at the ergonomic/user level.

23. Stephen Rainey said on August 29th

    I agree that design should start before the data model. This is the step where you figure out what all is needd and how everything is going to work.

    I have my partner/designer working off of a development server and handle all the SVN tasks for him. He understands rails enough to add actions to the controller and dig aroiund in the templates. I have no problem going in and committing his changes when I need to.

24. apotheon said on August 29th

    heyotwell said: “I’d be interested in seeing this same post from the other point of view: the Designer who has an idea for an application and tells the developer to ‘just wire it up.’”

    You already provided half of what you say you want to see: the designer half. You said “At times I’ve put it to developers like this: how soon did you start your data model? That’s when you should have started the UI design, or sooner.” Unfortunately, the magic of creating an interface before you have any clue what the specific data requirements of the software will be is effectively impossible.

    Despite all the wishful thinking that suggests design drives development, producing an application that actually does a passable job at its intended purpose requires a “data drives development” approach. Applications are all about data. You need to know on what data your application will be operating, what parts of it the user needs to see, what parts of it the user needs to enter, how to organize it, and so on, before you can design a usable interface.

    Let’s take another look at the dashboard analogy again:

    First, decide what you want your machine to do. Then, figure out the general engineering principles that apply. After that, conceive of an interface that will allow a human to operate it effectively. Finally, build the guts of the thing (“wire it up”) and attach the dashboard with final tweaks to the interface.

    This basically boils down to planning out your data model first, then coming up with a general concept for an interface, and finally developing the concrete interface and the controller aspect of your software concurrently. If you’re very smart about it, your initial interface design will actually be interchangeable with an API, and you’ll be able to swap out GUIs and more complex CLIs as needed without changing the underlying code.

25. Tim said on August 29th

    It just dosn’t matter.. As a developer I realize that the computer is under MY control. Syntax, languages, etc should not dictate how I want something.

    The designer brings the user experience into full view and solves many usability problems from the start.. As a team the designer in my opinion has alot more work than the developer especially with the lipstick method.

    However by bringing some complex UI functionality to the table it actually only evens the workload.

    I can’t tell you how many hours I spend trying to design something and code it.. when the actual functional code only takes minutes..

    It just dosn’t matter how hard it is for the developer to accomplish.. they have no more say than the designer.. that kind of team hands down creates a better product.

26. Ross Hill said on September 1st

    I literally laughed out loud, that’s so true. I believe it is a difference of personality that is attracted to the two different roles though – 90% of the time thats just the way it will be.

27. SKANOZA said on September 3rd

    It’s not a wonder Open Source is just trailing so far behind it’s own schedule .. and it always will as long as they have this hard-geek-ass attitude of thinking Development comes before design or that Designers have to “walk the development line”. That’s plain BS!

    If that were indeed true the Mac OS X would be fiction!

    Design before Development guys. Sorry programmers. Your job (as unsportively as you might want to take this) is to make a specific design work. Your logic-driven minds should understand, from that statement, that Design does indeed come first in the software cycle! And it’s NEVER going to change so long as building good software is the goal, face it and live with it!

    And while you are at it, realize that the best work done in the Open Source world today is [at best] only a lame imitation of what Apple does (if not a less flattering fact – what Microsoft or some other non-free software company does This article of yours also explains EXACTLY why Open Source work can never be immediately associated with ‘innovation’ or anything tangible results for the average home or office desktop. At best they may produce a ‘we-also-have-a-copy-of-this’ version of anything that non-free software companies do. Or run some backend stuff that never shows it’s face to the User.

    (Not that i support Non-free software but Open Source had better realize the “source” of all their ideas! And offer some ‘real’ help and support too, will ya? Don’t give bricks and cement to a guy who is looking for a house to live in!

28. Wolfgang Bartelme said on September 25th

    Great write-up – I had to smile continuously while reading, because I also made similar experiences several times :)

29. Jason A. said on October 2nd
    Although this article is now about a month old, I'm glad I found it. As a background, I'm a designer/developer (There's a reason designer comes first in the title) and I can't tell you how many times I've run into this issue. It kills me every time I land on a new open source project page and it's obvious that the design of the software, website and technical documentation was left as an after thought. Being also a developer who's worked hours on getting "that elusive feature/bug" to co-operate though, I can understand how you're so glad you finally got the software working the interface can wait. It's understandable, but it definitely shouldn't be excused. The other reason I'm glad I found this article is that I'm planning on doing something about it. The genesis of the idea came to me this last week and I've started to work to put the idea in motion. Hopefully, in a few months or so, I can count on some support from others who feel the same way as I saw in the comments above. More to come..

Sorry, comments are closed for this article.