
Ask HN: Visual Design for Hackers - DanI-S
Take a look at the Rails Rumble 2010 entries: http://railsrumble.com/<p>There's a whole stack of apps there, developed within 48 hours by small groups of people. They're not all beautiful, but there is (to my eye) a pretty high standard of presentation for most of them.<p>I am sure I am not alone in feeling like there's this chunk of knowledge I'm missing - in terms of how, and when, to go about making something beautiful.<p>I'm fascinated by the concept of optimizing user experience - it certainly has the potential to make or break an application's popularity. If you can spend valuable time tweaking code to make it more appealing to the compiler, why can't it work in the other direction too? Though I don't think it's reasonable to expect myself to be incredible at both, I'd like to be able to put together a prototype that looks nice. After all, I wouldn't show people code that I knew was bad and ugly.<p>Part A - I would love to know - how does this aspect fit into the flow of the project? At what point do you start turning things from black-text-on-white-background into a beautiful and intelligent layout? I'm sure it's usually incremental, but is there a specific point at which you decide to shift focus over to implementing your UI? I know I usually go through many notebook pages of UI ideas even before I've written any code. Is it worthwhile doing mockups in photoshop at this stage? Showing different designs to people and asking for feedback? Or do you usually do this after your core functionality is built? And where do you draw the line, say 'this is ready enough for now!' and release the thing?<p>Part B - In terms of user interface and usability, there's a lot of information out there. Much of it, however, is from the early days of graphical computing and the web. There are still great things to learn from stuff like Joel on Software but I'd like some good information about user interactions and expectations in the AJAX era. There must have been some more wisdom accumulated in the last decade! I'm looking for some shoulders to stand on - 'our experience showed us that you should never do &#60;xyz&#62; because users find it confusing'.<p>Part C - I've always been curious about how small teams of people manage to cope with the graphical elements of web application building. Does a team of 2-3 people in an early days startup usually contain a designer/artist? Is that something you can reliably outsource? Is it ever a good idea to have your design done by someone else and then shoehorn your view code and javascript into it (for a prototype/beta), or should it always be a closely collaborative process?<p>Part D - Finally - I'm interested in any of you people who can see BOTH sides of the coin. If you started off as a programmer and then learned how to make stuff sexy and usable - what put you on that path? Where did you start learning? What were your major obstacles, and how did you overcome them?<p>Looking forward to hearing what everyone has to say.<p>Dan
======
olalonde
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.

~~~
sudont
> 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.

------
alanh
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!

~~~
aloneinkyoto
\- 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...

------
mrpsbrk
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...

------
samratjp
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 ;-)

------
alialithinks
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...](http://graphicdesign.spokanefalls.edu/tutorials/process/gestaltprinciples/gestaltprinc.htm)

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!

------
retro212
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.

------
yatsyk
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?

------
jayair
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.

------
mgeraci
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.

------
davidcann
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.

------
joeld42
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.

------
DTrejo
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...](http://www.quora.com/What-are-the-best-books-on-UI-UX-design-for-
software-engineers)

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...](http://www.quora.com/What-are-the-best-resources-for-learning-
bleeding-edge-web-UI-and-UX-design)

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...](http://www.quora.com/What-are-the-best-books-
written-on-design)

------
bobbywilson0
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!

------
earlyriser
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.

------
PhrosTT
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...

------
synnik
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.

------
DanI-S
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

------
swah
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?

~~~
petercooper
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.

------
LeBlanc
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>

------
redwoods
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 .

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

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

------
idan
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.

------
sp4rki
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.

------
enra
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...](http://www.thevisualclick.com/notebook/2010/10/2010-rails-rumble-the-
design-process-of-commendable-kids/)

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.

------
wushupork
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.

------
sahillavingia
Actually, I'm doing this thing where I'm offering hackers around 5-10 hours of
design work per week (plus additional direction help and the like) for a
percentage of the company. Normally around 1-5%, depending on a bunch of
things including valuation.

I think it's a great deal. If I get 3% of your company, and my design help
increases the value of your company by 10% (that's ridicolously easy, too!)
you've already made a net profit out of the deal.

What do you think?

~~~
spokey
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.

