What is a Web Systems Design Consultation?
A Web Systems Design Consultation provides answers to key design and technology questions, and defines what the end system will look like. The many details, ideas, and technical considerations must be reduced to their essence to speed systems design.
What are the goals of a Web Systems Design Consultation?
The goals of a Web Systems Design Consultation are to help you:
- Speed project completion by adding clarity to your web systems design.
- Reduce implementation costs by defining and recommending key existing and emerging technologies.
- Determine the best short-term and long-term paths to realize your goals.
- Define progression of milestones, and the major tasks in each milestone.
- Define the priority of milestones and of individual tasks.
- Define what needs be done, and just as importantly, what does not need to be done.
With these details and answers, a significant systems leap forward can then be achieved in a short time. This is the overall goal of the Web Systems Design Consultation.
What happens during the consultation?
The consultation involves two in-person meetings on two separate days. Each day consists of two 2-hour meetings, with a 1 hour break in the middle.
Business/system goals are defined first. The goals will be used to prioritize project tasks/milestones or define systems details.
From a technical and design perspective, we would help you define and determine 3 primary systems design areas:
- Define all primary Objects in the system.
- Sales Order / Sales order line
- Product / Product-inventory
- Customer / Supplier
- Shipment
- The primary actions that would be performed on those objects.
- Add / Edit / Delete
- Various actions related to interaction with other system objects
- Add sales order line
- Process sales order line
- Back-order item
- Invoice Customer for a sales order
- Define how the objects will work together, and consider the technical implementation details such as programming language, database, platform, and software that can be leveraged.
Some examples from an online shopping cart may include:
Examples of the most common action types are:
Specific examples from an online shopping cart may include:
The time between meeting days will be used to create the initial (draft) documentation.
During the second meeting, the initial draft documentation will be reviewed to add details.
What happens after the consultation?
Additional phone calls or email correspondence may be needed to clarify any additional details. The results of the meetings and correspondence will be used for completion of a documented summary of what was discussed and decided during the meetings. The summary documentation is finalized and delivered.
Documentation Methodology
In the past, you may have experienced receiving a massive technical document that is meant more to impress than to communicate. We feel that since the purpose of the documentation is to communicate answers clearly, we keep the documentation simple, but detailed. Our focus is on strategy, systems design, ease-of-use, collaboration, and quick understanding. Therefore, you will not have to wade through a massive document full of charts, pictures, graphics, and filler technical jargon that would be more at home on a marketing brochure or sales proposal.
Examples:
- System objects are defined in plain language, with details as to how they interacts with the system.
- System objects are often described by actual database table definitions and their associated fields and notes.
- Actions are described in plain language, with definitions, and how the objects interacts with the system.
- Simple text-based wireframe models are devoid of actual graphics or styles that would distract from the system design process.*
- Systems design details or recommendations will be included in a summarized format.
To get started, call us, or Request a Quote.
*If graphical wireframes or other graphical designs are desired for presentation purposes, we can create them for you separately.