Loft will use a staged process to generate the artefacts required to ensure successful delivery of the Customers’ requirements.
Loft will initially perform a Visibility Study to build understanding of the global processes that drive ATDW’s business successes and motivations. This is done to ensure we deliver the desired outcomes and that our solution incorporates the required flexibility to be relevant and applicable over a longer time frame. During this stage Loft will require access to key decision makers for the project to ensure the best outcome, detail such as:
High level discussions to define Customer Desire (Objectives) descriptions and the scope of the solution;
Definition of initial Customer Use Cases specific to the context of the solution;
Definition of identified Process Segments specific to the context of the solution;
Creation of a Involvement (RACI) Schedule outlining the availability and required exposure of key Loft and Customer stakeholders;
Setting of initial Scope of Works and set Customer expectation.
Loft specialises in building highly flexible systems that can be scaled to meet multiple process issues, and to that end we focus on guiding our customers to a scope that answers very specific requirements first, whilst knowing that we can easily expand once we have met your expectations and solution adoption has occurred.
Loft utilises a three-tiered approach to the creation and version control of design artefacts. Our design team builds Concept & Functional, Graphical & Experience and Technical specification documents simultaneously using a highly collaborative methodology.
Functional Document (includes Functional Design, Systems Architecture Supporting Document and Systems Architecture Diagram);
UI/UX Document (includes Artwork, UX Supporting Document, Style Guide and Prototype);
Technical Document (includes Module Design, Metadata Repository and Data Structure). To strengthen this process we use an iterative release model for each document, supported by Customer interaction as defined in the Involvement Schedule:
Alpha Release: Internal Loft activity, often rapid and may produce clarification requests for Customer stakeholders;
Beta Release: Customer stakeholders are provided the full documentation set and encouraged to challenge and raise variations;
Version Release: Customer stakeholder has approved a set of design documentation a ‘frozen’ document set is released upon which Development and / or Implementation can be delivered.
This cycle of Design and Release is modelled to support multiple solutions in the pipeline. Our goal is to get the Scope of Works completed and implemented as quickly as possible and into action so we can continue to improve our solution in line with your business objectives through additional engagements.
The Design stage is commenced in accordance to any opportunities identified during the Visibility Study and as approved by the Customer.
Our Development process follows the same methodology of our Design process, with all code and development artefacts being iterated (via testing and review) upon using the Alpha, Beta and Version release cycles.
Since Development often does not generate easily recognised artefacts for Customers, Loft will perform guided demonstrations of progress during user acceptance testing sessions and will contact the customer at key milestones to keep you updated.
The Development and Release stage is commenced once a Version document set (Functional Document, UI/UX Document and Technical Document) is released and Customer approval is given.
To implement a finalised Loft solution, after client’s user acceptance testing, a range of support and software solutions can be selected by the customer based on a Software as a Service (SaaS) model.
Application specific Helpdesk and Support can be provided in accordance to an agreed Service Level Agreement (to be negotiated separately with the Customer).
Each stage will include two (2) Customer review iterations on the Design & Development Beta revision documents and one (1) Customer User Acceptance review of Version 1.0 documentation.
Any additional Beta review beyond these two (2) will be deemed as a variation and will attract additional cost.
Once Version 1.0 documentation is released and provided for final acceptance, any additional review beyond the one (1) will be deemed as a variation.
At the completion of a successful Engagement the Customer can expect:
Engagement Documentation (Involvement Schedule, Use Cases, Scope of Works);
A full version release Design document set (Functional, Graphical, Technical);
A Scope of Works plan for Development and / or Implementation;
A final version of the solution application or new functionality;
A Service Level Agreement defining application support.
The consultation is aimed to gather the information required to produce the following;
Requirements Management Plan
Requirements and Risks Registers
Supporting UX Documentation
UI Documentation / Kit
Visual UI Prototyping
UI / UX Prototyping Collaboration & Review
Product Development Estimate & Schedule
A high level document stating the concepts, aims, stakeholders and an overview of the proposed project governance and role authorities.
This document is used to record the necessary information to effectively manage the user requirements gathering process. Early investigative work aimed at defining business benefits based on the user expectations for a new or modified system (software / application / website). The document will list the types of requirements necessary to achieve the business benefits that will in turn shape the final solution. High level risks and assumptions are also discussed and listed as part of generating this contents.
These documents are a product of gathering and refining detailed business, user and system/functional set of requirements and risks. The registers are created to support the Requirements Management Plan and are a result of frequent communication with key stakeholders to determine specific feature expectations, ensuring the final concept conforms to the client needs. These are detailed documents, describing the functionality of the proposed software solution.
Creating the wireframes is the framework for the concept. Creating a defined hierarchy of elements to improve the usability and functionality for the end user. By eliminating the colour, imagery, and other details, the focus is on the layout and functionality of each element on the page and the structure required for the best user experience. These also assist the client in being able to visually identify which elements are more important than others.
Use-cases are used to identify, clarify and support the concept requirements. The use-case is made up of a set of possible sequences of interactions between the system and users within an environment and related to a particular goal. A use-case holds the functional requirements in an easy to read and tracking format. A use-case helps the technical team to visualise at how the system will be used.
Creating the user interface for the concept. A design document referencing the approved wireframes. This document applies the visual elements (Branding, Icons, Fonts, Colours Pallets, Button, Images, Sliders etc.) to the user experience created within the wireframes. The document (created in ‘Sketch’), produces vector based files that can be utilised by the technical team. A user interface ‘kit’ is produced to create a standard across the entire concept.
Using the UI document, a visual prototype is produced (created in ‘InVision’). This prototype links all the visuals of the concept, allowing a user to navigate through the system’s screenshots. This enables key stakeholders and end users to navigate and ‘use’ functions of the application (e.g display [visually] functions like taking a photo, pressing on buttons, etc.).
Using the finalised prototype, key stakeholders are able to collaborate, observe and document user behaviors to make informed ‘UI / UX’ updates based on the data collected. It enables a visual ‘Checklist’ to confirm all functionality description within the functional documentation are included. It allows for identification of the other components that play into the experience, create a more holistic view of the product’s experience from the customer’s perspective. Additionally, the prototype will allow for collaboration with the technical team.
This is the final step before the actual development of the software can begin. The schedule will list all the major delivery milestones and phases of the proposed system with high level estimates of the work required. The schedule is based on the client priorities and the functional requirements to create a fully testable system at each milestone. The subsequent work builds incrementally on top of the core model with each milestone delivering a more enhanced version of the system.