Often the hardest part of developing an application is getting agreement on what exactly it should do.

Intent Driven Design (IDD) is an approach that simplifies and standardizes the process of getting detailed technical requirements from non-technical business users so you can develop more complete and consistent requirements in less time.

The Importance of Intent
One of the most frustrating elements of application development is having to continually change the way an application works because of conflicting requirements from different stakeholders. Most such problems come from the lack of a clear focus for a site. You have to agree, in writing, with all of the stakeholders - why you're building the site, who will use it, and what their motivations will be - before you can even start to discuss how the site should work. If you don't, you are guaranteed weeks of wrangling as different stakeholders disagree on fundamental design decisions or priorities because of the lack of a shared vision for the site - often after much of the application has been coded.

The goal of IDD is to provide a standard but lightweight approach to capturing all of the key information that you need to specify a site. For a simple site, you might be able to go through the entire process in a couple of hours. For a more complex project, you might be discussing the issues raised for a number of weeks. Either way, you should end up with a well-structured set of somewhat traceable requirements that you can provide to your development team, and use to turn the high-level business objectives into the appropriate code to achieve those agreed objectives.

No Silver Bullet
In his classic book "The Mythical Man Month," Frederick P. Brooks wrote an entire chapter about an important distinction between "accidental difficulties" and "essential difficulties." For example, memory management/garbage collection is accidentally difficult - it is a problem that can be solved with a smarter programming language (Java or C# instead of C++). However, building a flexible object model for a real world application is actually difficult - there is no "silver bullet" (methodology, IDE, code generator, etc.) that can make this fundamentally difficult problem simple.

So, IDD is not a silver bullet. It doesn't make it easy to specify complex systems or to handle conflicting requirements. However, it does allow you to clearly and consistently document why you're building the system and what each group of users is expecting from it. It also allows you to "start at the beginning" with a formal process that lets you lock down the objectives which drive the tasks, which drive the screens and actions, which, in turn, drive the data model and the scripts required to implement the requirements. In short, it tries to simplify the process of capturing requirements in a way that doesn't require a degree in computer science to understand!

How Big Is Too Big?
It is often better to build a small project to meet a limited, but valuable, business intent than to try to put your entire business online, delaying the benefits of your supplier extranet or online store, while trying to decide exactly what format your online job application form should take or how to track vacation days online. I have found that if I have more than three to five major intents for a given phase of a project, unless they are being handled by independent teams, I'm probably going to end up with problems.
Too many intents make it hard to keep the focus required for developing a great site, and they increase the likelihood that different intents will conflict, leading to a "nobody likes it, but nobody hates it" kind of compromise design. Overly ambitious projects are also much more likely to ship late or even to fail to ship at all.

This doesn't mean that you can't specify complex applications using Intent Driven Design. It does mean that you might want to break down large, complex projects into smaller projects, and run through the IDD process for each phase. My general rule-of-thumb is that, if the coding (excluding specification, testing, revisions and deployment) for a phase takes more than a couple of weeks, the phase is too big. With application generators becoming more common, there are very few collections of 10-to-20-use cases that take more than a couple of weeks to implement (assuming two-to-five-use cases per programmer over the two weeks, and a maximum team size of five developers before you need a more robust methodology).

These estimates exclude "rocket science," where you're trying to solve fundamentally hard technical problems (such as seamlessly integrating Hibernate with ColdFusion). They also exclude "lab experiments" where issues like performance or load are critical and you may need to build a couple of prototypes before you find the right approach. Such projects can take orders-of-magnitude more developer time to complete, but can still benefit from the IDD approach.

Business Intent
The first step in IDD is to write a paragraph describing the business intent. Why bother building the site? What exactly will it do for your organization? Writing down and agreeing on the business intent upfront makes many of the later decisions easier by creating a shared focus. If the intent is to increase your online sales, the job board and the HR benefits pages are not essential to that intent so they can be pushed off to phase 2.

Roles
What people (and computer systems) are going to use the site? From a requirements-gathering perspective, it is usually best to break down your audience by the collections of tasks they will want to perform (as opposed to by demographics, psychographics or other such approaches). A given user will often perform multiple roles, so you may well have users that are both customers (for buying things online) and administrators (for managing site content), or are both sales people (for accessing the sales reporting system) and employees (for accessing HR benefits online). Roles in a typical project may also include one or more classes of administrators, such as data entry, content editors, approvers and reviewers, and may also include various reporting-based roles.

Roles are not always performed by a person. To capture all of the tasks that the system needs to support, you might also have roles for scheduled tasks, imports, exports or any web services and other interfaces that you provide.

Role Intent
Once you've identified all of the roles, the next step is to document the key reasons why each role would be performed. By documenting why a customer would choose to order online, or what business information a manager is looking for from an online report, you will be able to make better design decisions regarding trade offs such as balancing ease-of-use with flexibility. Also, if there is no good reason for someone to use your website, they probably won't use it. You will only achieve your objectives from your site to the extent that you help your users get what they want out of it. Don't worry if not every role has a meaningful intent, but do go through the process as you'll capture distinctions that will help when you're working on the detailed design.

Compare your role intents with your overall business intents to make sure they are consistent. If you want to increase revenues and your customers want to place orders online 24/7, supporting that intent will meet their needs and yours. However, if your customers want to be able to find the lowest cost supplier, that is probably not an intent you want to support within your site as it is unlikely to help you increase your sales.
For a medium-sized e-commerce system, you can probably document the business intent, roles and role intents on just two or three sheets of paper. Indeed, with a small team (one to five developers), if you have much more than three sheets of intents, you will probably find it hard to deliver a system that can achieve them in a timely manner.

Essential Tasks
Once you have a list of roles and their associated intents, the next step is to figure out what functionality your system must provide to help achieve your business intent by helping your users achieve their goals.

A task is just another name for what most programmers would call a "use case." We've found that by calling it a task, our non-technical clients grasp the concept more easily. A task is a series of screens and actions that allow a user to achieve a valued outcome. Examples might be "order products online," "check order status" or "compose email newsletter." The specification for each task should include any alternate paths (along with their screens and actions) for different choices and for handling error conditions.

Now, instead of having the usual "wouldn't it be cool if the site could . . ." discussions, you can come up with a much more focused list of tasks by asking what exact tasks the site must support to allow each of the roles to achieve their intents, and in a way that helps the organization get what it wants from the site. I tend to focus on essential tasks (as opposed to "nice to haves") as I prefer to deliver the absolute minimum amount of software required to meet a useful set of business and role intents. If you want, you can add "nice to have" tasks depending on the time and budget constraints on your projects, but classify your tasks into essential, useful and optional so that you can deliver the most important functionality first.