Friday, July 20, 2007

Web App Development Methodology

System Design and Web Design

System Design

There are many methodologies that deal well with clarifying requirements and then designing and building systems to satisfy those requirements. You have your use cases, stories, functional specs. You create logical designs that model the domain, examine how actors interact with the various systems to fulfil a business requirement. You can then start building and testing your code. Somewhere along the way, some web pages or windows forms get created out the back of this process. If developers have their way, they are usually logically correct, but terrible to use. But they do the job - don't they?
What do you mean there's a high drop-out rate?
How did I devalue the brand again?

Web Design

The other perspective that web app development gets approached from is UI design. The business go to the designers with some high level requirements, and they start the page design. Usability tests, rich interactions, brand, UI design principles, Flash demos, sitemaps, user flows, copywriting, graphic design, detailed UI specs; these all feed into a wonderful, engaging, on-brand customer experience. And then you build that code stuff on the back of the screens. I mean, the screens are the most important part of the whole thing.
Aren't they?
What do you mean you need some requirements?
And now you need to change the page flow...?

The Train Wreck

Usually these two flows happen in parallel, on the whole independently, and then towards the end of the project, there's a big crash when the two worlds collide.

What we need is...

What we need is a methodology that allows these two, largely disparate disciplines to work in harmony. User requirements need to feed into use cases which need to drive both the customer interactions with the system (usually web pages) as well as the interaction between various systems and business processes. The problem is, I'm having real trouble finding anywhere where this is taken into account. It generally seems to be either the web designer's approach or the system designer's approach. However, to be effective at writing enterprise-scale web applications with high quality systems and also a rich and engaging customer experience this is an absolute must.

High Level Idea

So how might this work? Taking the Unified Process as a starting point, we really should start out by clarifying the requirements. This is before any design starts from any perspective. Then out of the back of this you will get the use case diagrams which show the interactions between actors and systems. Customers can interact with systems via many channels: phone, web, letter, fax. These all need to be clarified and mapped onto the business processes. This should give you an idea of what the interactions are, what channel they use, and what data is required both in and out. Then you can start the system design and the web page design. There will be parts of the use cases where the actor is the customer and the channel is the web. These will give you the interactions and data flow required to start designing the customer interactions required on the website. You can then produce wireframes from these and subsequently add page-level detail, rich interactions and perform usability studies. All based on the use cases. It seems quite simple - does anyone actually do this?


No comments: