I am myself a professional programmer that has some basic design skills, but I'll try to answer your question as well as I can.

A - I'm pretty sure most people design the UX/UI before they start coding (at least mock ups). If you have already coded all your backend, you might feel constrained when designing the UI or might realize too late that you oversaw some critical parts of your system. Let me illustrate:

Let's say you are building a "C.V. builder app". You might start coding with the assumption that the user has to be login to start building his C.V. However, if you imagine the UX first, you might realize that it would be nice to ask the user to register only once he wants to save his newly created C.V. That simple detail might have a huge impact on your code base.

B - Some resources & inspiration: http://uxmovement.com/, http://ui-patterns.com/, http://www.smashingmagazine.com/category/inspiration/, http://www.dribbble.com.

C - If you're good at UX/UI design but lack the Photoshop skills to bring your vision to life, it should be safe to outsource. In any case, make sure your designer really "gets" your vision.

D - I started learning to design and program at about the same time. Since then, I've put most my time into programming and although I consider myself pretty good at designing user interfaces, I lack the technical skill and experience to make them look beautiful. If you're the same as me, I would suggest spending some time trying to really master Photoshop or such tool. Also, some color/typography theory can't hurt.

> I lack the technical skill and experience to make them look beautiful.

It's called practice. I've known designers who have each won handfuls of AIGA awards. The common thread was that they never stopped designing things. Talent is a leg up only for the first few steps.

HN people have weekend programming projects; these designers had daily side design projects, in addition to their daily design duties. The amount of time dedicated to this was staggering. I think their only real talent was being able to self-immerse themselves so deeply in the subject without burnout.

[B] - Definitely some good resources I've used in the past (being a developer wanting some inspiration) - one more I'd add to the list is http://sixrevisions.com - I like to pop in there every few weeks to see what's new - they typically have articles similar to Smashing in topic

I’m about to go to sleep, but I just want to drop a few of my favorite rules of thumb. (I love UX and constantly bitch about bad interfaces, FWIW.)

- Visual hierarchies. Color theory. Understand both of these, and use them.

- Don’t use the words “me” or “my” in your interfaces (with rare exceptions like “✓ remember me”, which is de-facto standardized)

- Native controls/widgets give users lots of free platform-specific and accessibility functionality that they expect. Don’t implement your own text box / dropdown / scrollbars without a damn good reason.

- Use color sparingly, to convey meaning and/or draw attention.

- What is the purpose of each and every design element? Can it be removed, or does it have no purpose? Then remove it. (Maybe keeping one exception to the rule gives your site a touch of personality / a brand).

- Reading the OS X HIG is eye-opening. Don’t try to follow it online, though!

- Can stuff line up? It probably should.

- When should you show a throbber or “Loading…” message? The answer is not “whenever something is loading”. It’s “whenever the user must wait for something to load, or whenever an update or change of view as a result of a direct user action is not immediately visible.” And this should be minimized.

- Don’t half-ass buttons. If they hover or have an active (depressed) state, then the hover (“over”) state should look like a slightly lighter or darker version of the normal (“up”) state; the depressed (“down”) state should look physically depressed, if applicable; invert the gradient, swap the borders, or whatever.

It looks like I’m starting to list pet peeves instead of the big ones, so good night!

- Always show a useful fallback for empty views. Preferably visually distinct and "subordinate" to actual content (e.g. centered gray text instead of left aligned black text).

- Try to minimize the impact of destructive actions and try to offer the possibility to rollback potentially dangerous actions. Make dangerous actions look dangerous (e.g. make delete buttons red).

- Think about visual distance and distraction, especially in flowing text. Columns look good, but forces the eye to scan for the start of the next column when reaching the end of the previous. Don't place two equally important things right next to each other, etc...

Hi. I am a designer that is trying without too much zeal to learn to program. Here go some advice, no idea whether it helps.

First, i believe that "looking great" and "being good user experience" are actually very, very different things. Designers are good just at the first. The second remains a dark art for programmer and designer alike.

For example, thinking about which user input you need or could do without, which order to ask for them and so on, falls i believe neither there nor here. Which effect you should apply to the input box is utterly immaterial, and i would venture that a competent designer can make any kind of use-process beautiful to look at.

As for making beautiful, i have found no way to develop this except by endless boring practice. The best illustrator is generally the one who has done more illustrations. Rules or techniques (as in crutches) tend to give good results in the very short term and become stifling very quickly.

If you lack the stamina or interest to simply draw, i guess this is not a bad thing. The other way to see the thing is that you'll eventually get better at it.

That said, designers do tend to develop a variety of manias and sensibilities that, well, seem to be related, vaguely, to their craft. If you're willing to try to get that, i would recommend a very, very old book. I know this goes directly against what you were looking for, but, again, that is my opinion: Symbols and Signs, by Adrian Frutiger. (Amazon has it, not sure if it is bad form to put an amazon link here... Also, i do only know the Brazilian edition so i can give no advice about that...). Maybe this book can come out sounding like full of rules, but that is not the point.

Another, more recent book that is also incredible, but even more paranoid (the guy goes pages and pages discussing commas, then semi commas, then colons, and i just love it!) is The Elements of Typographic Style by Robert Bringhurst.

Finally, designers always do end up getting a bit of cognitive psychology, and it is a good thing, but no self-respecting psychologist could purport to understand the human cognitive system, so i would say avoid the ones who are too sure of themselves like how-to guides to Gestalt, those are just gimmics. Find something that is serious about cognitive science, but not serious enough that you'll sleep, and that is it. You can always go back for more...

As a friend of mine says - marketing and good UX is like laying grass out for the goats. It must be easily reachable and in digestible chunks.

1) Mock-ups. Supposed to be mocked upon. Take a good page design you like, import it into Photoshop (or w/e) and start boxing the important elements. A lot of well designed sites are on the 960px width bandwagon (even Apple's homepage + most YC startups). Short answer - look up Blueprint CSS framework and 960px grids on Noupe.com

2) Mockingbird is awesome! Just worry about the creative flow first, then put it on a grid.

3) Like a special effect or design on a site, google "jquery site-name effect-name" will usually net some good plugins. Learn and repeat. Don't know what effect-name is? Firebug it :-)

I am by no means a true designer, but I feel that the only thing stopping you/me/anyone is the labeling. When you feel that happening, just think of Iron Man, he designs the whole stack ;-)

Some Quora questions I was looking at yesterday that you might find helpful (I plan to comb through these and pick out books and blogs to read more of):

What are the best books on UI/UX design for software engineers? http://www.quora.com/What-are-the-best-books-on-UI-UX-design...

What are the best resources for learning bleeding-edge web UI and UX design? http://www.quora.com/What-are-the-best-resources-for-learnin...

What are the best design blogs? http://www.quora.com/What-are-the-best-design-blogs

What are the best books written on design? http://www.quora.com/What-are-the-best-books-written-on-desi...

Hey Dan, I would definitely recommend reading these sources for getting a comprehensive understanding about general design principals and core ideas:

The Gestalt Principles The guiding theory in understanding how the human brain process images and visual data. http://graphicdesign.spokanefalls.edu/tutorials/process/gest...

Web Typography Great resource for understanding typography and especially for the web http://webtypography.net/

A List Apart I am sure you are already familiar with this awesome publication by the Happy Cog crew and other contributors. To me this covers most of the on screen design issues in today's world and it keeps on evolving which is awesome. http://www.alistapart.com/

I Hope this help!

Part A - I always make few screens in Photoshop before coding. These screens include form, items listing and generic text page. These are not complete and finished designs, they just help me to visualize stuff upfront, and to design some common elements (buttons, form controls etc). After that I customize every screen based on content it displays.

Part B - There are many sites that write about UI and UX, they should be googleable :)

Part C - I'm doing both development and design of our apps. I think that designers that don't code can't really design good app because you must have all of the interactions under control, and for that you must understand how things work both on server side and client side. I don't think they should know how to setup server and deploy app, but there must be some understanding of how things work.

Part D - When I started working as a developer, I worked in web studio that also did great design. But they also gave me the ability to try and design stuff along them. They taught me about typography, layouts etc. I even did some print stuff because I wanted to learn it. Little by little pieces started to fall in place. I'm far from great designer, but I can design things that are nice and usable. The biggest problem is that I really like boxes. When I'm designing stuff I'm automatically placing things so they can be easily sliced. But I'm working on it.

My advice is to just start working on some designs, and to find some friendly designer that will help you with constructive criticism.

I very impressed with level of design work of Rails Rumble winners. Are any blog posts from contestants about design process, tools, resources they used (stock images, templates) and so on?

I do both and I am trying to help other hackers figure out more about design as well.

A: I usually have a vision in mind for the project or the feature. To do this I try and break it down into smaller parts and optimize for the one thing I want the users to do for that part. For complicated designs I go through ideas on a notepad before I settle on something. The most important part of this process is to understand why a certain design element needs to be put in. If my design elements lack purpose I take them out.

Once I have that then I go about building stuff. Sometimes the end result will differ from the vision in which case it might literally be "back to the drawing board".

B: I haven't found too many recent ones. But I generally prefer patterns like these - http://developer.yahoo.com/ypatterns/

C: I'm generally against outsourcing UI/UX. I think specific icon and graphic design work can be outsourced. To me UI/UX is the app itself and early on you don't necessarily have a clear view of what it is going to be.

D: I started off as a developer and found the need to incorporate better design. I started by trying to understand what I like and why I like it. I found a couple of big problems: there weren't too many good resources that catered to our type, most design advice wasn't practical enough and improving my taste took a long while.

I'm putting together a series of posts on what I learnt, hopefully that helps people out. Feel free to get in touch via Twitter or email.

As the designer in a three person startup (the other two are coders), I can give some information on our process.

A - Our design process starts with a discussion of feature ideas and requirements from the code side. Then work goes in parallel until each team has a workable mockup/prototype. This period of work alone is critical to the development of the app from the visual and user experience side of things. It also gives me freedom to try lots of new ideas. I'll usually do a couple of revisions based on comments from my co-founders, and then get some outside opinions.

B - I fear that user interface and usability comes more from trial and error than reading. I haven't found a good resource for the technical side of design, but olalonde's link to uxmovement.com looks great.

C - Our startup has 2 coders and 1 designer. We're a rails shop, and I know enough ruby to implement my designs. This mix usually works really well as far as delegation of work. I'm not sure how standard this is.

D - Can't say much here since I started on the design side and have more recently been programming.

As an aside - if you're comfortable in css and are adding a new page or feature to an existing site, I've found that it can be fast to prototype in html rather than Photoshop/Illustrator.

I think that all developers should be able to design layouts that make sense. Pure programmers (writing algorithms, optimizing, scaling, etc.) don't really need design skills.

You definitely need product developer(s) on your team if your startup is consumer facing at all. In such a small (2-3 person) team, everyone needs to do multiple jobs, so if none of you have decent design skills, then start practicing now.

Part A - Usually a proof-of-concept happens first either in basic wireframe mockups or basic/ugly code. Once you'er clear on the product you want to build, then full designs are done in Photoshop or, once in a while, direct HTML.

Part B - I would mostly ignore that stuff. Simply look at great/big sites and see what the do right, but more importantly look at what they could improve and do that yourself. Basically, make your interface design as simple as possible while having the minimum feature set to make your product useful - finding that balance is where you become a great product developer.

Part C - Don't outsource your design. If you commit to design as a core competency in your development team, then you understand that design is not just visual - design encapsulates everything that the user experiences with your product.

Part D - I started off as a cartoon animator in college, but found I was better at coding, then I realized that to make great products, I need to have great design. I didn't have a design monkey, so I started creating my own designs (poorly at first) taking inspiration from products I enjoyed. To overcome obstacles in design, I simply take the worst part of a page/workflow and fix that first... repeat until the product is due or there aren't any cringe-worthy features.

A fun way to learn a little or at least get inspired is to check out LayerTennis on fridays:

http://www.layertennis.com

Each round, each layer, ask yourself "do I like that or not"? and then try to articulate why or why not. Why is this layer: http://layertennis.com/100910/07.php not as effective as the next volley: http://layertennis.com/100910/08.php For example, I didn't notice at the time that the quote had six letter 'O's in it, but now that I see it it's hard to miss. They create a lot of repetition a rhythm that ties them to the shape on the other side. The symbol and the text relate to each other even before considering the meaning of the words.

Seriously, one of the hardest parts of design is to learn how to form strong opinions and understand your reasons for them, without being arbitrary. Design is just a million tiny decisions.

Part A - I am on the side of completing as much UX up front as possible. Bad visual design is something that no one can ignore. I think that ideally before you even have done the "black-text-on-white-background" prototype you start with UX.

Part B - Steve Krug has a couple of simple concrete usability books. Other than links I have seen mentioned. http://ilovetypography.com/ learning good type will help a ton with design http://www.useit.com/ Jakob Nielsen is kind of the godfather of usability, some people love him, some hate him, either way you will learn something from this guy. Also, going through tons of websites and critiquing them by yourself or with peers, writing down everything that works well and doesn't work well, that you would change. Do little usability tests on your sites, even on sites that aren't yours with family or peers.

Part C - I don't know as much about startups. I do know that having a designer on hand is much nicer to work with than outsourced. Ultimately I think it would be like dealing with anyone else outsourced in terms of reliability.

Part D - I actually started as a designer, and IE 6 crushed my soul. I am still very interested in UX though. I think starting as a programmer, I would just try to recreate designs you think are appealing. I would also try to learn the grid system. Use CSS frameworks as training wheels that have a solid grid, and decent typography (eg. Blueprint). I started constraining myself to HTML and CSS, and I think you should too, leave Photoshop alone until you can make decent designs in just HTML and CSS. Then, when you are completely comfortable using the two, then look to PS to add details that you can't achieve otherwise. The big obstacle you will run into, is that you will feel like you aren't making as good of designs as designer X. Design in my opinion is much more personal and emotional than programming so don't let that get to you.

Good Luck!

A) I start with mockups, then the polished design and at last the programming. For users, the interface is all that they have, then the UX stuff needs to be defined very early (in my case). I like 37signals "epicenter design" approach. Start with the more important pages and with the more important information chunks of these pages.

B) useit.com and my collection maybe http://www.delicious.com/egogol/ui

C) have someone good for design in your team. If you can't, exchange your programming hours vs design hours. Ideally it should be a collaborative process.

D) The important thing is that the user gets the things done. The UX determine how the programming process should work.

BONUS) Test a lot. Test your mockups, test your design, test your running app. Every step will reveal different problems.

I am a programmer with fairly advanced photoshop skills. I am not a good designer. I know this because when I see good designs, I realize I NEVER could have come up with that.

If you're a programmer, you should be able to nail the science half of the equation. As for the art half, I would just shamelessly rip cool things you find when searching "css inspiration" or whatever ["great artists steal"].

It's easy to go overboard reading about UX and all the articles completely over-analyzing the topic. Unless your product is centered on revolutionary interface like hipmunk, you're probably safe just using established interaction patterns and getting feedback from "normal people".

Just see if your non-techie friends can handle it. If so you probably have enough to launch. Most big sites were ugly at launch...

I work both sides of the coin. I have a degree in fine Arts, but have been a software guy for many years.

I put in an initial design when I make a HTML mock-up. I tweak it until I think it is good, then start to code the actual functions.

As I work with it, within a few days, the constant usage and testing show me what is wrong with my design. I then often iterate, updating the design whenever it starts to annoy me. At the start of the project, this is often once a week. After a few revisions, I slow down, and by the time I've been working with an app 6 months, it is fairly stable.

In terms of how you actually make your design, the KISS principle remains valid. It is much easier to add small UI elements to make a page more interesting than to scale back from an over-engineered design.

I've been working since posting this and haven't had time to properly read or reply to your comments, but wow - some really fantastic stuff here, from some very respectable people. I am going to have a great time reading and exploring what people have said, once I get a moment to sit down...

It seems a shame that all this expertise be confined to the bowels of the HN news list (which isn't search engine indexed, right?) - would it be acceptable to make some attempt to compile it into a (properly referenced, ofc) blog post or something that the rest of the world can see? What do people think about that?

Thanks for your responses, I am very impressed.

Dan

Also, why Ruby project pages mostly look beautiful or at least like someone tried to make it look pleasant, and every Java project (except Octobot) has absolutely no CSS?

One reason that Rubyists are Rubyists and not Java developers is because they care how stuff looks rather than solely how it works. Given this, there's an aesthetic culture that doesn't exist so greatly in other spheres.

You should check out this talk that Jason Putori, the designer for Mint gave titled "10 Things: Design for Non-Designers".

http://vimeo.com/15066599

These are great questions. Exactly the ones I am asking myself right now as a non technical guy trying to work out which piece of the puzzle to start with in building out my project .

There's Jakob Neilsen, of course: http://www.useit.com/alertbox/

For your part B advice, it's almost a one-stop shop.

Hi Dan,

First off: I gave a talk on this very topic at DjangoCon EU 2010. Video: http://djangoconeu.blip.tv/file/3685673/, slides: http://www.scribd.com/doc/32311867/Design-for-Developers.

A) there always comes a point in any project when I have that "fully baked" feeling -- a stage where I feel like I have spent enough time putting myself in the users shoes to understand how they can best accomplish their goals. Sometimes this comes quickly, and sometimes not -- it truly depends on the project. I don't go further than sketching until I've reached this phase; sketches are cheap and I don't need the high resolution which photoshop affords. Generally, I'll spend some time in photoshop after the sketching stage to work out a visual design "langauge" -- what's the colorscheme, what visual conventions am I going to use throughout the site, etc. I'll take one or two "core" parts of the site and mock them up in photoshop to figure out how the visual aspects affect the design, but I won't do every single page in photoshop -- it's a waste of time.

B: I don't know. There's general stuff about performance from Steve Souders, and overall I think resources like ALA are probably a good starting point.

C: It depends on your product, but I'd argue that good design is something that happens primarily before code gets written. The frontend of your app should inform your backend, and vice-versa -- ergo a designer co-founder is an extremely important asset, IMO. Every project with design "added later" looks like it had the design added later, not baked in from the start.

D: I'm a designer/developer combo, coming from a formal background in computer science.

I guess I started getting into graphic design and photography during high school. Learn about graphic design for print since it has a lot of history; the web is still in its adolescence and is heavily informed by this history. Don't neglect to learn a little about typography. In the end the web is mostly about reading words, so it behooves you to learn the art and science of arranging words on a page so as to maximize legibility and beauty.

The biggest obstacle to learning this stuff is a broken understanding of design. It's a discipline like any other; you might not have the aptitude to become a master but you can learn the basics and become proficient, just like you did with code. It took you a decent amount of time to become a proficient coder; don't assume that three weeks of reading will turn you into a proficient designer. Stick with it, learn the terminology so you can start to read things written for an audience of designers, and don't forget to actually do stuff yourself -- like in code, there's no substitute for sitting down and grappling with some work on your own.

A) At what point? From the beginning. You said it yourself, you go through notebook pages with UI before even writing code. You need to have a structure in place before you begin anything. Sure you can morph it as you go, but you need a direct connection to what you are trying to achieve. At the same time you're coding some functionality, you should be thinking about how this is going to be displayed. It's of course not necessary to do any of the graphics or styling at this point, but it works better if you give it some thought and try to form some type of layout and broad design ideas as you go. It's worth doing photoshop mockups when you reach a point where the application development can benefit from being graphically beautiful (which can vary immensely... every project is an island). You draw the line at the first moment you can. If and when you reach a minimum point where your application could be used by the masses, freaking ship it. You can fix and add features later, but the moment you have enough to ship that thing out the door - do it. Software is never "finished" anyways, so you'll need to keep going at it anyways.

B) Almost all the information regarding UI usability and user experience holds up regardless of age. The concepts are the same now and when it was written. There are also a LOT of resources written in the last few years, so I'd disagree that all the information is old. In any case, it really doesn't matter, you're still going to need to come up with your own conclusions for your specific case. No amount of UI/XI reading is going to allow you to skip having to do you're own testing and to draw your own conclusions on what works for you.

C) In the web industry the designer/artist is generally also the guy that codes your Html/Css/Jquery. A front end developer is generally the person that designs interaction and pretty screens. The back end guy is the one doing the algorithms, database work, etc. You can outsource everything, though the results are usually not even on the same league as the worst results you can get from a good team that clicks working together. You can always have a contractor come in and work with you or your team if needed, and that can sometimes be a better compromise than outsourcing per se.

D)I started as a programmer at an early age, but I was also an artist. What put me on that path is that I wanted to know how to do everything. From Photoshop to Rails to C to server security and deployment. I started learning by doing. Don't look for guidance man, just work on a project and when you need something you're not comfortable doing, freaking do it anyways. Need to do graphics, test layouts, a/b testing? Read on it and start doing it asap. At some point you'll become decent at it, and then one day you're actually good at doing it too! Obstacles? There are no obstacles, only challenges. Challenge yourself and you'll come out a winner.

We participated in the Rails Rumble with Splendid Bacon http://splendidbacon.com and I did the design and most of the fronted ui. (I wrote a summary about the process: http://news.ycombinator.com/item?id=1803155)

A) - Usually in our projects or in my projects, I try go with the design first, starting with describing what we are doing, why, for who and how.(The Five W’s Of http://52weeksofux.com/post/890288783/the-five-ws-of-ux). The concept, being 5 lines or 5 pages, sets the background for the whole project.

From there I try to go with sketches, or wireframes to iterate the views or the interaction flows. Then start doing the ui in Photsohop. When I'm quite set with the UI I start implementing that and iterating the interface along the way. After that, or about in the same time we start coding the features.

B) - I'm not sure how much wisdom we have accumulated. About some things sure, but natural multitouch interfaces or multimillion user web services are still quite new. If we would have followed Jacob Nielsens advice on everything, we woudn't have sites we have today.

I think the best way is to keep updated what's out there and from there you can get inspired to find your own solutions. That's why I have iPads & iPhones, try to use most of the new services to understand how they work and how they're built.

I try to learn from other people and their process (like with simple todo app, Cultured Code produces a lot of sketches and mockups http://culturedcode.com/things/iphone/makingof/ and one of other Rails Rumble attendees described their process: http://www.thevisualclick.com/notebook/2010/10/2010-rails-ru...

C) - In our company we usually have 2-3 person teams, where one of them is a designer, which is something I would recommend. Personally I think the best is if the designer can also implement the design, because Photoshop mockup is not the actual design, the app or it's interface is. For best result, you need to be charge of the whole interaction.

D) - I'm not that sure which way around I got started, I had some classical arts education as a kid, and later started making websites and developed some web services. I'm quite bad programmer, altough in addition to html&css I can handle javascript, rails and php.

I think the first step is to know what's is great and what isn't so you know how well you're doing in your own projects. So develope your taste by surrounding yourself with great design. And like in any other learning, the key is just practice. If you have coded hundreds of features, then by the same time I might have done dozen of designs.

For me the hardest part still finding the right process for some cases. Sometimes I'm able to see the whole thing right way, and sometimes I'm just stuck or feel that something is wrong with the design without knowing what.

Hi Dan

I also think that the stuff that came out of Rails Rumble looked pretty awesome especially done in 48hrs. I created ShelfLuv in about that timeframe as well and see both sides of the coin to use your terminology.

Part A: To me the design and UX is first and foremost. Especially w/ a hackathon - think of your product like a runway fashion show. On the front side it just needs to look and work perfect. Under the hood for me, out of the gate doesn't matter as much as long as it works and isn't slow to the point that it affects the user's perception of the product. I typically try to think of the user's interaction/perception/experience first. Mockups in Photoshop are pretty useful to me, but so are HTML mockups. It all depends on what I am trying to achieve. A visual experience - playing around w/ that would be best served to me by toying around in Photoshop. An interaction experience, mocking variations of that in jquery is best because I can click around. I can touch and feel my app. However I mostly start everything with sketches on pieces of paper or my notebook. I try to draw different variations. I look at how other webapps/apps do them. With ShelfLuv there werent many ideas or variations. I didn't start having variations until I had something working to show. If there's nothing to show yet, I feel that people have no baseline with which to compare. It's a lot easier for most people to say A is better than B, than to just show them B and ask them if this is any good.

Part B - I find that a layperson is immensely useful in this arena. One of my sounding boards is my wife. She's very intelligent but is not what you would call a techie or designer type. Alot of times I just want to use icons but many nontechie people will have no clue what these icons mean. Of course it's a compose icon - it's a pen and paper.

Part C - I would say you can outsource visual design, but it would be hard to outsource the interaction design and how the app works. Interaction is a process that can be very iterative. You try something, it doesn't work and you try it again.

Part D - I am an engineer by training but started focusing on user experience and interaction about midway in my career. I felt like I could have the most impact on users through a great product experience. I started by reading a lot of blogs and sites of great designers. I look at and try a lot of web apps and sites. I also buy a lot of iphone/ipad apps to see how they work and what they've done. Major obstacles for me is that I'm not a graphic artist and I can't design from scratch. I know designers who like to create textures and stuff from scratch and to me I feel more like a cobbler of design elements rather than an original creator of design. I will put this design element together with that element. I'm basically pretty handy at tweaking and modifying in Photoshop but ask me to create stuff in Photoshop and Illustrator from scratch using the pen/brushes/paths and I'm lost.

I'm not sure if this comment is quite appropriate on this thread (as it is a borderline commercial offer and quite possibly off-topic for the OP's question), but I think your model is interesting and I'd love to know a little more.

1) Is your 5-10 hours/week offer indefinite or for some fixed period? Are you capping the number of start-ups you are working with? (This offer doesn't seem to be infinitely scalable.)

2) Do you see this role more as employee-working-for-stock or as angel-investor-contributing-design-skills-instead-of-money? Maybe another way of asking that is: are you taking direction from the founders/owners or are you offering advice/support as you see fit? Are you OK with a founder who only wants you slice up a PSD she designed or are you looking for an adviser role?

3) I think there is a lot of sense in pg's advice around giving up a small percentage of the company in exchange for a much greater chance of success, but I'm not sure it is obvious that your offer is a "great deal" for the founders as you state.

I'll accept that in some cases a good design can increase the value/success of a company by 10% or more but I think in this specific scenario (early stage start-up, possibly with long-hanging fruit design challenges):

a) A 10% improvement in the current value of the company probably isn't worth 3% of the eventual value of the company if it is successful. That is, it may be easy to take a company from $1000/mo to $1100/mo through 5-10 hours of design, but barring major oversight I think it will be a lot more difficult to take a company from $10M to $11M through graphic/web design alone.

b) On the founder side of the equation whether or not the design work will increase the value of the company more than it cost is really only half of the question. The other half is comparison shopping: is there a cheaper way to do this?

For instance, if you assume a modest $500,000 exit then 3-5% is $15,000 to $35,000, which may be a roughly competitive rate for design services (e.g., that's $60 to $100/hr if you assume 50 5 hour weeks). Obviously if you assume a $1M exit those rates double. If you assume a $5M exit those rates grow by an order of magnitude, and I hope I'm not a cheapskate in thinking that $600 to $1000/hr is a disproportionately high rate for all but the most remarkable web designers and even then is probably only appropriate for the most design sensitive web apps (whichever those are).

I may well be wrong, but I have a hard time believing that for most start-ups a bit of early stage design work really provides an additional 6-7 figures of valuation in the long run. Is that what are saying is "ridiculously easy"?

c) A moderately successful start up should be able to afford market rates for design services, and I'd guess that it is rare for great rather than merely acceptable design to be the difference between moderate success and failure. Why shouldn't a firm just limp along with an acceptable design until they can afford a great one? (And if they don't have an acceptable design yet they can certainly get one for less than 3% of the company.)

In other words, I think the major challenge to your offer isn't about whether or not design can offer a 10% improvement but more about whether or not 3% of the company is the easiest/cheapest/lowest risk way to get that improvement.