Feature Driven Development

I'll have a stab at this, but i know there are other members on this forum who have many more ideas on this (David Anderson, Gavin Baker to name a few ;)).

I think the 'official' position is that there is no hard and fast rule on how to do GUI's. I think Jeff's mentioned in the past he hires someone who is good at doing GUI's and lets them break down their area into what they can consider features and builds a feature list.

I think you are on the right track with your gui modelling. I would imagine some sort of state chart type diagram could be used as a 'model' (see the gui tool 'denim' for example). edges in the chart could indicate actions while nodes are pages and controls.

Development is usually done by seperation of concerns, so a pd/dm guy may expose an api for a ui guy to use etc. This is different to threaded development (develop gui/pd/dm logic).

Hope that helps :)

mark -

With the importance of experience design for most web apps these days, one cannot haphazardly create a UI on the fly.....there needs to be deliberate thought into the informational layout, interaction design and visual appeal of the UI. My firm's methodology is a direct reflection of the FDD mindset, except that our color modeling phase is replaced with a comprehensive UX Design phase. Here is a perspective I posted on a LinkedIn discussion:
-----------------------------------------------------------
"For my firm, there is a period of BDUF (big design up front), followed by our Scrum process. In developing Flex and AJAX-based RIAs, we aim to layout 60% of the app through wireframes, in order to articulate the common interactions, information layout, and flow. We'll then apply a treatment and create the UI comps. That is the BDUF part.

Prior to the start of our Sprints, we decompose the UI Comps into a list of User Stories which forms our Product Backlog. We then meet with the client Product Owner to prioritize them. The whole dev team will spend a half day to estimate complexity/LOE of each Story on a 1-5 point scale. We then decide on a "reasonable" amount of points to tackle during a two-week Sprint.

When we begin our 2-week Sprints, we take snippets of the UI comps for the User Stories created by our BAs. This occurs prior to the Sprint Planning Meeting. To clarify, during Sprint #2, the BA is writing stories in advance of Sprint #3. During the course of the storying writing, the BA will unearth the missing 40% we didn't cover during BDUF.

We arrived at this approach by studying an agile methodology called Feature Driven Development (FDD), which emphasized spending 10% of your project timeline to nail your object model before beginning your Sprints. I figure that our UXD process consumes 20-25% of the overall project lifecycle."
-----------------------------------------------------------
Add'l commentary:

My firm develops primarily in Adobe Flex. With Flex, we can embed a tremendous amount of business logic in the presentation tier. The big bonus is that rather than build a complete back-end, I can build a feature (e.g., search for book titles) and have the command hit an XML file which serves as a stub for the presentation tier. This is in lieu of building a complete back-end. Once the client has approved the flow and overall user experience, the XML stub now serves as a "contract" against which to build out the back end and database. This method is completely inverted from the methods of yore, where we started from the datamodel and worked our way to the UI. Its flip flopped.

Darrell Ross
Partner
Enablus, LLC
www.enablus.com