2. Information Architecture
Understand your users, your data structure and your channels.
You can think of an FSD as a blueprint to an architect: a guide to understanding how something will function, and the expected behavior of that system
We create an FSD after the initial wireframe and quoting phase of our development process in order to map out each feature’s specific functionality and the correct user flow for different user roles (aka Administrator, logged in User, anonymous User, etc.)
FSDs created at the start of each project are a collaborative effort between the development team and the UI/UX design team.
The development lead takes in the initial project requirements and estimates scope of work required to build each feature.
The UI/UX team builds the initial wireframes, and mockups to give a visual representation of the features and user flow.
The development lead and the team review and confirm that the planned data functionality match the approved designs.
On completion, the document is delivered to the client. After client feedback and approval, milestone dates are assigned to each leg of development as outlined in the document.
At TD, we combine Functional Requirements and Use Cases, and User Stories to give a combined expectation of the project flow and features as a whole.
Functional Requirements are “system shall” type statements, outlining general functionality, for example, “The system shall allow users to register and create a profile” or “The system shall have report options which can be exported by the Admin”.
Use Cases are a series of steps, presented in their order of action, to give a sort of ‘play-by-play’. Example: “User logs in and is redirected to the pricing page, where they are prompted to select from three drop-down menus, which contain: xxx”
When the document is delivered to the client, it is then the client’s job to make sure the folowing rules are observed.
This necessary process confirms that the design and development team are on the same page as the client, making sure expectations can be fully met, and the proper functionality will be developed (as predicted during the quoting process).
Ultimately the end goal of the FSD is to meaningfully align a client’s feature desires with the design and development teams functionality, usability, and logic. The functional specification document helps to keep each software project on track in order to deliver milestones that work as expected and are carried out on time.