Ask HN: Advice on a good workflow for web developer/designer
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!
3 comments
[ 3.5 ms ] story [ 17.1 ms ] threadWhether 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.
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.