Designing the Domain

The design effort follows the analyst's path and picks out the most valuable and critical elements of the original concepts. The design challenge is to lay these elements out and to describe their optimal arrangement in a functional specification. That description should resonate with all who are involved and interested. And when it does, scope is locked.

Building a Web Application

Beginning with a Concept
Analyzing Use Requirements
Designing the Domain
Building the Domain
People and Money

return to the leakyboat


Or far more than anyone ought to be able to afford to develop in the first iteration.

The concept document is the sum total of the initial brain storms that are intended to make certain that no worthy idea associated with the purpose of the domain has been omitted from consideration. For the critical eye and mind, the concept document raises more questions than it answers. And if it does not, it should. When the concept document is done right, it contains  far more than the eventual result should be .

Analysis of the notions contained in the concept document produce an understanding of what processes are critical to the successful implementation of the concept. Analysis shows whether and how processes contribute to the desired outcome of the development effort. Analysis also reveals how these processes work and what information is required to make them work.


"Scope creep" will always occur in every project. But when it becomes a remarkable problem, one can usually point to (1) a lack of discipline in holding to a design and development plan or (2) a poorly defined design and development plan.

A competent and comprehensive analysis will yield insight into how the domain described by the concept document should be designed and developed. It should also provide the foundations for development ideas beyond the first release. In doing this, analysis sets the first real sense of project scope: what should be included in the domain and what should not.  Design confirms this sense of scope, refines and then locks it. 

Create priority measurements that feel comfortable and make sense. These metrics may vary from one project to another. Some processes are critical and others are not. Some are pure entertainment not related to primary mission, others are purely utilitarian. In general, the constraints to including all conceptual functionality in the current version are time and cost. The highest rankings belong to processes and functions that are indispensible to the desired results and that yield the greatest value to the users. Lower rankings can be assigned to enhancements that can be added later. Lowest rankings can be given to those processes that are superfluous to the mission of the domain.

Each component of functionality should be assigned a  priority rating  based on its relative value to users and its logical dependency with respect to other functional components. Setting these priority values allow application designers to understand whether these processes should be included in the current development version, when and how less critical functions may be planned for a future iteration, or what should be dropped from the development plans altogether.

Such simplification is not always so simple. One must be careful to ensure that redesigning processes does not shear off necessary user and administrator controls over those processes.

Consideration should also be given to opportunities to change and simplify process if that reengineering  yields the same results . When joining related processes into sequential functionality, certainly the designer should seek opportunities to accommodate the use of technology to simplify the user's interventions.

These "hooks" are then ready to accept the attachment of a future application service component with a minimum degree of disruption to the existing application structures.

When the application designer has the opportunity to consider all possible processes to include and is able to set aside functionality that may be planned for future inclusion, the  structures of the domain can be designed to prepare for and more readily accommodate those future additions and enhancements . Whenever the application designer's attention is given to disciplined vision, development efforts down the road will likely be much easier.


The difference? A functional specification describes how a domain and its applications will work, what it will look like, and why it should be built. A technical specification describes how a domain and its applications will be built, and what technology options are appropriate for its planned use.

The designer's job is to describe the domain and its applications in the finished sense and in the way that will guide the developers to successfully complete the domain. This information is recorded in the domain's construction documents or system blueprints, the functional specification and the technical specification.  The functional specification and technical specification are intended to offer two different perspectives of the domain and its applications. 

Written in common non-technical language, the functional specification could be a dense textual document or a simple story board or something in between. It may be a detailed "requirements" document based on the analyst's discoveries and recommendations. Whatever its format and approach, the functional specification should describe the user experience and the desired outcomes of that user experience. What navigation and access options are available to the user? What information and controls appear on the pages of the domain? What events trigger functionality? How do these processes play themselves out? What data must the user provide to these processes? What happens when the user does and does not play by these rules?

The world is full of developers who believe that a functional specification can be by-passed and that after twenty or so minutes of conversation with stakeholders, they can begin to lay down code. The buyer of these services should consider this to be a big red flag. This is not the basis of a solid development agreement. No agreement is possible whenever there is no explicit statement detailing mutual expectations or what should be produced.

The designer relies heavily upon the analysis and use cases to assemble this description of the user experience. The designer also relies on the business or subject matter experts to confirm that the functional specification accurately describes the desired application(s) and the manner in which they should operate.  The functional specification is certainly composed for the sake of thoroughly thinking out the design of the domain.  Ultimately, non-technical stakeholders should be able to read and fully understand the functional specification and say "Yeah, that is what we want this domain to accomplish and how we want it to behave." Technical developers should be able to read, understand, and say "Yeah, we can build this and there won't be any surprises."

A domain and its applications could be developed to the functional specification and still fail its purpose if the wrong technologies are applied in development and deployment. It is also possible to spend way too much time, effort, and money on technology. Again, this is a case-by-case assessment. I can think of no good reason why technology options should be selected for technology's sake. Technology options should only be selected to fit the purpose of the domain, its applications, and its intended use.

The technical specification of the domain will have less meaning to the non-technical stakeholder than the functional spec. Still,  the technical spec is a critical component of planning because it describes the technology requirements that must be adopted and imposed to make the domain and the applications operational as intended and described in the functional specification . The technical spec will therefore respond to questions about development platforms and languages, media, data repositories, data structures and normalization, network and server services, latency and bandwidth, traffic, scalability, hosting options, related systems and systems interface.


Not commonly found on the public network.

Except for  highly specialized and narrowly defined application domains , there is no single user filter through which the design of a domain and its applications should be viewed. It is therefore useful to read through a functional specification a number of times, each time identifying oneself with a different perspective. Users and stakeholders can bring many purposes, interests, and agendas to the project. All of these things should be carefully considered to ensure that all or most needs are being addressed.

Typically, there may be three (or more) common classes of external users and stakeholders asociated with domains on the public network:

  • For example, buyers and sellers on an auction site who are both primary users but engaged in different views and interests of interaction.

    Primary users of a domain are those who actually and intentionally interact with the domain and its applications. Within this group there may be  multiple roles , as well, with unique interests and sometimes complex performance requirements associated with each role.

  • A secondary class of domain users might include folks who directly or indirectly associate with primary users but who do not actively interact with the domain and its applications. They are distinguished from primary users by their desire not to participate and from casual browsers by their habitual return to and interest in the domain.

  • A third class of domain users are the casual browsers who wander into the domain from the results of a search or a hyperlink found in another domain. These folks come in for a quick look and, if nothing compelling is found, are gone, never to return again.

An even richer mixture of interests may be commonly found among the internal users (i.e., users belonging to the host enterprise) and stakeholders. A few examples of perspectives that might exist on the internal or administrative side of the domain:

  • User service and support staff may be primarily focused on the external user's experience and satisfaction with the domain. Issue handling and escalation priorities are set roughly according to the three external user classes described above and an assessment of the importance of the point of failure.

  • Data administration staff is primarily attentive to the integrity of the content being added to the domain repository from outside users. There may be a number of functions to perform in this regard. First is database administration. Second may be moderation of content contributions. Third might be validation of content or user qualifications. The list goes on.

  • The perfect finished domain has yet to be written and so there will always be application development staff engaged in planning and building the next version and modifying the processes that handle data as it is brought into the repository, and as it is requested and processed for presentation to the user.

  • Enterprise marketing staff is primarily concerned that the target market is aware of and being adequately served by the services available on the domain.

  • Enterprise management staff is primarily responsible to ensure that all other users and stakeholders are on the same page with respect to the use and success of the domain, and its applications and data.

All these interests and probably others need to be served by the design of the domain and its applications.

When the construction documents are complete, the required effort has been defined. The next step is development.

Return to Top.

application design, web design, functional specification, technical specification, scope creep, development plan, requirements document, interface design, user experience, navigation, business process, business model, application requirements