When putting together a reasonably complicated website, in what order do you tackle things?
In the past I've listed the functionality I want the website to have, then mocked up web pages by hand and sent them to a designer. Then when the design would come back, I'd send the Photoshop files to a programmer to hard-code and turn them into an actual website via a particular CMS.
I'm not sure this is the best way, however, for a bigger project. Especially when you want the website to process more technically difficult things like logins, database retrieval stuff etc. Should the order of events instead then be: 1. Define functionality 2. Test functionality via coding 3. Design 4. Coding ...?
Be interested to hear how people go about planning and building a reasonable-size website taking in aspects such as functionality, design and coding.
Ed
Project scope/requirements > Information architecture (wireframes) > Design > Code > Profit
Basic but wild idea -> freak coding spree -> some ads -> slight disappointment (except for the freaky coding buzz)
If the basic functionality is going to be the big challenge, then it's comforting to at least have a proof of concept before wasting time on making it look nice.
If the functionality is pretty standard (and I would consider logins and database retrieval stuff to be standard and simple from a coding perspective), then you can focus on a nice design as a first step after scoping and defining functionality and IA.
In other words, I would say start with the problem/obstacle/challenge that is most likely to cause this project to fail and that you fully control (in the sense that lack of revenue might make it fail, but that's harder to control).
My brother worked for years at HP on a product that had a hardware component and a software component. The research engineers kept saying the biggest problem was figuring out the software and they needed to nail down the software and then build the hardware to spec. The managers kept saying that once they had the hardware, the software engineers would figure out the rest. Needless to say, I'm telling this story because after millions of dollars building the hardware, the software engineers never could figure out how to make the thing work.
That's very interesting. I always decide what functionality I need first, then get a design that will work THEN code to make the design/ functionality happen.
Depends how you define design, I don't think it can be divorced from usability. You also need to stop programmers from thinking too much, they have a habit of that.
Design the site, show the programmer what happens when a user... etc etc and tell them to get to it.
>Depends how you define design, I don't think it can be divorced from usability
Yup.
The same could be said for the designer... some are more artistic, some are more functional. If you know what you are doing, I think you can mock things up and then give them to an artist, and you are good, because the basic 'design' and UI will be apparent to everyone. But if its a usability issue, you need to invest in mockups to get the flow and functionality down first... THEN give it to an artist to make it pretty.
yeah provided you have a designer who understands websites, I would design then code, unless it's something so amazing that development might have to change the way you expect things to function.
If the designer doesn't understand websites and/or IA, then probably best to get another designer :)
I think that you should be thinking at least as much, or if truth be told much much more, about how a "customer" will feel rather than how a web site will function.
>how a "customer" will feel rather than how a web site will function.
I'm not sure I would say its all 'one in the same', but imo it is all intertwined; it's gotta 'work well', 'look good', and 'feel right' to make a sale.
Additionally, imagine if you had a really difficult concept you needed to get across to the user...
I would start with a mockup. No code involved. Get the whole thing right and clickable if need be and then test it on users. THEN code.
Appreciate all the advice. Will get to it! ;D
http://th3core.com/talk/web-development/wireframe-applications/
Topical, as a new version of Axure's been released this week.
If the user journey might get complex we prototype in balsamiq first. It's so quick that it is rare that you don't get value from doing so. You can even publish to clickable html if you want others to dick about with it and give feedback. We use this a lot for "will anyone get this???" checks.
On a complex custom development...
The only way I have found to get design and programming working in harmony during development when using specialist teams is to do due diligence right at the beginning before production is even started and booked into the studio. It takes time upfront and you need to have conversion, usability, marketing, layout and basic logical programming skills to do it successfully so if you get caught at any point you may want pass this back and forth between your team for collaboration. On a large project I can take a between 1-3 days on this alone, researching competitors, design, examples, sourcing pre existing code where applicable, creating and mapping out the concept etc etc.
I write a usability, technical and feature review and white map areas of functionality with design reference where applicable. All under one document. This is then sent to the programmer to review the feature set and layout and to come back with any issues to make sure everything is possible (well as much as you can at that stage).
It then goes to the client for sign off, discussion and adjustment. If there are any changes it goes back to the programmer for a final in depth review, last chance to preempt any potential hiccups. Once signed off if goes to the programmer for final checks and this is the last stage the client can make major changes before it goes into production and it is also sent to the designer for mock up.
I then work with the designer for quick visual mockup, a mix between quick jpeg mockups in some places, straight to html framework mockups in others, html and basic css is completed by the designer (and is some cases visual javascript) and files are then transferred over to the programmer after being signed off by the client. If it is a big job then this can normally be staged (I discuss this with the programmer beforehand when organizing the studio schedule).
If run well the project goes smoothly, it can also hinder on instruction and content provided by the client (unless we are providing content-if we provide this is done throughout the production process, in some cases this starts before), if the client hasn't thought about the project and not paid you to think for them and start changing things in the middle it all falls apart. Delay in delivery of assets such as logos, content sitemap etc also drag a project on and can affect aspects such as feature sets when paired with the content. So generally I make sure the client provides the main sitemap and main page/feature set content before development begins, enough to get the site started with, this shows that they have actually thought about what they want and committed and also avoids jobs being dragged on for months because the client is wanting certain aspects to go live when they have got around to creating the content. They don't like it, but it gives them a better product and a smoother more efficient and cost effective development in the end.
The ones I have broken this rule with in the past have been the ones that have taken 2-3 times longer to develop and end up lasting months messing around and because of ill thought out change requests during development, the product isn't as solid at the end as aspects have had to be patched in rather than constructed within the whole framework from the start. So I have lost jobs because I have refused to proceed until due diligence has been done by the client but the ones that get it and get on with it generally have a solid product at a great price that works and a pretty smooth development and experience within a realistic and maintained schedule. I have less headaches, last minute all nighters fire fighting and maintain control of the development and schedule. So I feel this aspect although not touched upon in your question, is vitally important in the project plan.
Once programming is in place (generally content is being added as well at this point) design is signed off it goes to client review for final tweaks and programmer/designer for final polish and bug tests, then live.
Hope this helps and saves you some headaches along the way. I have learn't the hard way over the years much to my detriment of sanity and pocket to stick to my guns regarding my system and schedule, as soon as things start getting moved around, it all falls apart. Lets hope it helps you avoid this lol.
Good luck
Thanks for posting that Leona. Very kind of you to go into such detail. Will try and follow your advice. Cheers, Ed
Mobile first