One of our projects at work is in the requirements gathering/initial scoping phase. As with many web-based projects, determining the UI the customer wants determines a large part of the functionality the customer would like to have. That is, pictures can be worth a thousand words when it comes to building a requirements document. :)
At any rate, this is a good opportunity to write about one key aspect of building web applications more quickly and effectively: Do the mockups first, and then building a functional site will be much easier. You might also consider this the prototyping approach. If you can get a mostly-complete design of the UI, down to the fields that will be displayed and how they will be displayed, and then hand that design to the person doing the server-side development, construction will go much more quickly. At that point, the developer basically has to fill in the blanks, and once the mockups are made real, the developer is done.
Now, if you want bonus points, get the developer to review the mockups before they go to the client for review, and you'll get the added benefit of early warnings about the complexities involved in actually implementing the design the designer is proposing. For example, the developer may look at the design and realize to present the data in the way the designer envisioned might require numerous queries to a database or non-trivial amounts of calculation per page load. Small suggestions from the developer to the designer at this point regarding changes to the UI can end up in a proposal to the customer that will be easier or quicker to implement or have a greater chance of success. Of course, the developer may also react to the design by realizing the underlying data model needs to be adjusted to support the desired UI, which can help solve architectural bugs early on while they are still relatively cheap to fix.
As if there weren't enough bonus points already, here are a few more... This can be a great process for everyone, especially if you have a team that works well together and the team members respect the input and talents of the others. The designer gets a certain amount freedom to be creative in deciding how the data should be displayed and how the user will interact with the product, the developer gets to make suggestions for improvements and/or gets an early idea of what the implementation will look like, and the project manager gets buy-in from the technical team on the proposal to the customer (because the technical team helped create the proposal).
Of course, in the end, you are also making a great start with everyone (including the customer) being on the same page about what needs to be done. And once you start with a (commonly understood and accepted) end in mind, the experience of getting to that end can be much more enjoyable.
Comments