

Ask HN: Advice on a good workflow for web developer/designer - joshuahornby

As a young student trying to make it in the world of web design/dev I feel I am missing a trick somewhere (as my blog post yesterday kind of touch on http://joshhornby.co.uk/blog/wireframing/) In my eyes wireframing isn't needed but after some feedback I have been told other wise. What is YOUR workflow? what apps can't you live with out? Do you design in photoshop then move over to code? Do you mock out each page with pen and paper then code? I seem to lack inspiration even though I seem to live on dribbble. I think this is due to my workflow, so please help a poor young web designer!
======
obviouslygreen
In my experience (about 12 years of practical web development, so certainly
not as much as some here), wireframing is most useful when applied to projects
that have a "what" but not a "how."

Whether it's an internal/personal project or something for a client, it seems
to me that most ideas usually fall under "conceived by interface" or "other."
If someone wants you to build a web forum, chances are that idea is based on
how they want the forum to work and what the user interface should involve; if
they want you to build a penny auction website, chances are good (based on
several actual requests and one actual paying client) that the business model
and not the UX are the driving force behind the project.

For projects that do lend themselves to wireframing, I've heard of several
great tools -- Mockingbird is the only one I can recall -- but I am a pen and
paper guy. As a developer, I think it removes me from the "I'm programming
now" mindset that immediately jumps to data models and dependencies.

I do think this is more useful for general site layouts, though, than for
completely building a site on paper (or in whatever medium). As a designer,
this may not be your first concern, but the practical reality of user
experience is that requirements are never the same at the end as they were
during the beginning, so high-level concepts and ubiquitous elements like
navigation are (hopefully) more likely to stick to The Plan than the details
of each page.

Basically, separating user workflows and specific site functionality from
wireframes helps to make sure your wireframes are both useful and more likely
to stay flexible and relevant throughout development.

~~~
joshuahornby
Thanks for the reply. What is your basic work flow when starting our a new
website? photoshop? wireframe? straight to code? Also where do you get your
inspiration from?

~~~
obviouslygreen
Sure thing. Keep in mind, though, that this is from the perspective of a small
development shop, and design is not our forte.

Whether it's for myself or a client, the first thing I always do is a
requirements document. They're not always (read: almost never) complete, but a
simply-formatted list of features, grouped according to relevance and what
goes where, is a great place to start and often helps to bring up potential
issues or required but glossed-over features that might not otherwise have
come up until the project had already started (this is particularly important
for clients as it helps avoid incomplete estimates).

After that, ideally, we take the requirements to a front-end and/or (again,
very ideally) UX designer, if available. They throw our requirements into a
large black cauldron, stir in Eye of Newt and perhaps an Honest Politician or
two, and later we get back templates that might resemble parts of the final
product.

In the case that budget or time doesn't allow an actual design phase, we tend
to just build a simple base template (lately on Bootstrap) and jump into code.
I'm not advocating this; it's far from ideal. It generally works out if you
have a very solid understanding of the project and the relevant design
considerations, but leaves you very much open to coding yourself into any of
many corners.

From there, most projects are just a long series of build, show 'n' tell,
iterate on feedback, feature creep, rinse and repeat.

