views:

249

answers:

2

We are currently starting a bigger project. What're your suggestions for best practices of workflow?

We are planning to rebuild from scratch (the existing product is outdated by years, regarding visual and internal design and programming). While the product functions (a Rails based web project) are already set, the question is: What is your workflow from here on? The most interesting part is: How and when do you do your screen design?

We are planning to do it in the following order:

  1. "Pencil and paper" screen design: Just layout what the screens should look like and visualize the functions and visitor pathes
  2. Hand out the layouts from point 1 to the designers, have a talk to them, and let them work in parallel to programming on the designs
  3. First implementation, simple color-less HTML layout based on point 1 (automated tests, functionality, BDD, TDD)
  4. Integrate the designs with the product prototype
  5. Work out the rough edges together with the designer team to finalize the product
  6. Release a beta product for the customer to test

Do you have similar workflows? Are there suggestions for improvements? But the most important for me: How exactly do you do point 1?

While this is not exactly programming-related I still think this should belong on StackOverflow as this is important for anyone doing bigger projects. From the past we know that good screen design is always a critical and hard point if trying to do that while programming, and even harder to deploy it after the prototype application has been created.

Update: I found Balsamiq Mockups to be a very helpful tool to do the mockups. Still there's an open question how one would best visualize visitor pathes.

Update: We had been successful using Balsamiq Mockups to create a design pleasant to the customer and we managed to successfully integrate this into the existing web content. The customer is so comfortable with the new ideas that he is planning to redesign the complete web site.

+1  A: 

I like your workflow. It should lead to a decent result.

A few ideas here:

  1. Let the designers know and understand your presentation model. What pages there are, what information and control elements will they have, what is the role of each of them, what is the purpose of the page and what message should it communicate to the user. If you let the designers work alone then they will design something to reflect their vision of the project and not your design. You'll end up redoing everything or trying to adapt one part to the other.

  2. Users will only see and understand design. They know nothing of implementation. If they see a button they will think the feature is there. if you plan to go agile while cooperating with the users during development, hide out elements that are not implemented yet. Feed them results one step at a time.

  3. If you can have users nearby do screen design together with them in iterations. There is not much work for designers yet, when you are basically deciding on the layout. All those colourful effects and polished buttons should be done after the layout is stable. Otherwise it will be a waste of the designers work.

Developer Art
+1 for your first idea being a good point. Thanks.
hurikhan77
+2  A: 

I really like the model of extreme programming. When dealing with new products user requirements can quickly change over time and this is a proven method which keeps the design "up to date".

  1. Have the users write up functions that they want for the application. And have the designers agree upon a general layout.
  2. Write up a general wire-frame that both you and the user agree upon, I like to do this in smart draw or some sort of rapid gui development platform. (no functionality at this point).
  3. Write the code for the GUI based upon the wire-frame and write sequence diagrams and class diagrams.
  4. Based upon these design start to fill in the functionality behind the GUI
  5. Release betas throughout the process of adding functionality to select users who can help guide future development

The benefit of this design is that at any point in time you can re-work the GUI and incorporate new functionality. The idea is to have a general plan at the beginning that can be adapted as user requirements change.

Steve
My answer by the way is MY implementation of XP. It is important to understand how it should work so you can make it work for your team. http://en.wikipedia.org/wiki/Extreme_Programming
Steve
Indeed, XP is what we intuitively did back at the university. In a work relationship it is sadly not always possible to work that way.
hurikhan77