7

I've been having a debate with my peers as to which is the best process to use when we're designing web apps. Our development phases are working well but I think there's room for change in the design/requirements gathering phase.

I feel that there should be a phase for requirements gathering, then a wireframing phase, then development concurrently with graphic design. Others say development should start immediately.

Are there any resources or studies out there that can explain why you would use one process over another? I am having a hard time trying to convince others why extra phases in the beginning will help us in the long run.

Improve this question

6 Answers 6

Reset to default
8

Having development start immediately is seriously asking for trouble. I've done it once and have seriously regretted it.

The chief problem with that approach IMO is that the organization starts committing programming resources right away and becomes very reluctant to make necessary UI adjustments later on because, see, the software works "well enough".

Sometimes, the UI adjustments are minor, such as tweaking the page's layout or improving the workflow. But sometimes, the needed UI changes can be so extensive so as to require scrapping most of the UI already in place.

One example is adding support for undo/redo. This feature is very difficult to add after the fact. It requires that you can provide visual feedback to the user about which action is being undone. If some of the interaction takes place inside dialogs or via menus, and the changes that these interactions affect are not visible on the screen, then you must scrap a good chunk of the UI to become undo friendly.

Here are just two reasons as to why the UI should be designed first:

  • It saves money. Not having the UI figured out first is a near-guarantee that some work is going to be done twice. At least.

  • It forces the stakeholders to understand the scope of the project and requires them to sign off on the UI design beforehand. This will help avoid featuritis by encouraging stakeholders to exercise restraint when requesting features.

I hope this helps.

Improve this answer
1
  • 2
    I'd like to add that in many situations, you don't have enough information about the capabilities of the UI until development proper starts, making this a sort of paradox (which comes first if both depend on each other?). To solve it, I tend do as much UI work as possible up front, but then move quickly into iterative development of both the app logic and further UI details so as to discover limitations and new ideas as soon as possible.
    – Rahul
    Commented Jan 6, 2011 at 9:30
2

Since you ask explicitely for studies (+1 just for that!):

I haven't found a conclusive study over the entire process (e.g. saying "27% of project resources spent on design is optimal".)

However, e.g. Code Complete cites a lot of studies supporting a solid design phase. Though it comes from desktop development, the studies are acquired from a wide range of projects and are applicbale to web development.

The main line of attack is the project cost of errors: errors made during the design phase cost most, especially if detected late.

(And no, not having a design phase doesn't mean you can't make any design errors. That's unfortunate, isn't it?)

Improve this answer
2

What we generally use on larger projects where I work seems to be effective (though it's more used in our web shop than in the broader IT projects). I start with needs analysis and requirements gathering and nothing else.

When I get through a signed-off draft of high level requirements (I'm a UX/PM guy), I'll usually have requirements that focus on what the app has to do, but I'm not the best resource to complete technical requirements so I pass it onto our development lead, who does detailed tech requirements, including pseudo-code and the like.

While those are being done, I do a first cut of wireframes and an interaction spec. I'm starting to do more lo-fi prototyping at this stage, as it allows me to get feedback from stakeholders without detailed mockups. It also allows me to revisit my wireframes and make any adjustments based on the lo-fi prototype. Once the wireframes are finalized, detailed technical design is usually getting along and we can finalize the interaction piece too.

Only at this point do we typically put the time into visual comps and only after that's signed off do we build a high fidelity prototype. The good thing is that, by this time, we've got several rounds of iterative feedback, tweaking and ultimately sign-off completed.

Our high fidelity prototype is a pretty accurate representation of how our final app will work, so building the full app is a relatively short phase. Of course, you then need potentially alpha, beta and prod testing and tweaking cycles, so ...

Hope this helps.

Improve this answer
2

Since you asked for resources as well… Here's a resource which I would recommend to read: a book called How do you design?. Maybe you'll find it a bit too general for your needs, but I found it useful when searched for a good design / development process myself.

It provides a short description (mostly visualized) of many design processes, starting from very general ones. Design processes specific to software design & development (totally applicable to web application design) occupy the second part, but I would recommend to check the first one as well.

http://www.dubberly.com/articles/how-do-you-design.html

(The book seems to be in ‘beta’ since 2005, and perhaps will never be finished… Or maybe I'm missing something and it's already published. Anyway, PDF is free to download.)

Improve this answer
1

This should answer some of your questions.

getting to the customer why everything you think about user centred design is wrong

Improve this answer
3
  • I see personas more like defining the parameters for the range of hand shapes your hammer is likely to be held in--and using that to base the grip of your hammer on. And focus groups have nothing to do with making an inappropriately-spec'd prototype (prototypes/mockups need to be made based on the functionality you want to test; a Styrofoam hammer handle might be perfectly acceptable; a 2D cardboard cutout is not). If you were designing a hammer, then the "focus group" would be actually getting a group of hammer users together to get their input. Your analogies are way off.
    – Lèse majesté
    Commented Jan 8, 2011 at 22:37
  • 1
    It doesn't really matter how you choose to interpret my hammer example. It's supposed to mean what I wrote and the basic point is that. When testing wireframes on normal users you are really not testing where it matters.
    – ThomPete
    Commented Jan 9, 2011 at 21:11
  • "placebo for uncertainty" <- NICE term! Thom...I agree. There's an issue with 'premature testing' that happens all to often in my experience. Calling it a placebo is probably the nicest thing to say about it.
    – DA01
    Commented Jan 11, 2011 at 14:51
0

Just based on personal experience...you don't want to start full blown dev from the start. Nor do you want to wait to do any design or dev until after the wireframes are finished. The key is that everything has to move in parallel collaboratively.

On top of that, there's tons of dependencies...the particular dev enviorons, agile vs. waterfall, complexity of the project, etc.

Improve this answer
2
  • I'd have to say that telling them design shouldn't wait until after the wireframes are finished needs qualification. Design of what? Technical design and development could start independent of UI/UX work, but IMHO starting visual design before you've got structure and interaction nailed is asking for trouble.
    – jameswanless
    Commented Jan 11, 2011 at 0:22
  • It's asking for trouble if you wait much of the time. Interaction design can't happen independent of visual design, wireframes, code, and back end logic. Everything has to work together. One aspect of the process influences the others. Building web sites isn't an assembly line process. It's an iterative, collaborative process. Now, that doesn't mean aspects of the project can't begin independently of each other, but sooner or later they have to come together and the sooner that process is considered, the less likely you'll find major hurdles as you approach the finish line.
    – DA01
    Commented Jan 11, 2011 at 14:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.