The approach taken with respect to any form of customer or client engagement mirrors our agile approach to development, in that it is based on transparency, flexibility and partnership. We find far more value is derived from collaborative prototyping sessions than the development and delivery of uninspiring documentation where key functional aspects can remain ambiguously defined in text.
Discovery & Analysis
Successful project delivery begins with a set of well defined and understood business and functions requirements. Our Consultants are experts in helping refine goals and aspirations into large pieces of work (epics), features and user stories and documenting these in the form of a structured requirements set, which is called a backlog.
In order to understand the needs of the various user types, our typical approach is to plan and facilitate a series of interactive workshops lasting half a day, involving between four and ten people representing a range of users and departments. On larger projects, we would expect to run a number of engagements with a different cross section of users in each session. This encourages discussion, builds shared understanding and provides the team with a first hand view of challenges and objectives.
The days of producing colossal amount of documentation before, during and after the software development process is over. The ‘BRUF’ approach (Big Requirements Up Front), which was probably inherited from the engineering sector, has proven to be ineffective, irrelevant and often downright damaging when applied to software development. In contrast, an agile flavoured methodology advocates a leaner approach not just to development, but to the associated documentation required to define, control and communicate the project.
At Chess we employ this agile methodology, combined with a healthy amount of common sense, to determine which documentation is appropriate. Not all projects require detailed wireframes for example, as it may be that the development is a natural iteration of an existing product where time and effort is better applied to development and testing than to user interface (UI) design. Equally, some projects that are light on development requirements may require the creation of a ‘style tile’ to allow the client to visualise how new corporate branding could cascade across an online presence.
Naturally, some of the fundamental documentation required to propose a solution, outline vision, present costs and articulate a plan will be reassuringly familiar. Outside of these elements, we will use the requirements workshop alongside our key principles of accuracy, speed, knowledge and quality to determine not just the scope of the project, but the purpose and structure of any necessary supporting documentation.
Design Driven Approach
Digital employ a design driven approach to the development lifecycle, and particularly to the requirements engineering phase of a project through the use of tools and methods traditionally associated with creative disciplines. In practice this means we place an emphasis on experimentation, rapid iteration of ideas and evolutionary processes in an environment that places the user, not the technology, at the centre of the development process.
Interactions and conversations we have with you as a client will not be in relation to heavy documentation, but to your thoughts and feedback on early stage prototypes, mockups and user journeys. We rely on collaboration, iteration, making and empathy as core to problem solving. This process precedes the subsequent Agile approach taken to development, which consists of short, value focused production cycles.
Technology can help shape growth, engage customers and allow you to operate in a more agile way. Internally, it can empower employees and provide an engaging path through which to creatively disrupt the industries we participate in. We do it ourselves in Chess, having rolled out various tools such as Microsoft Teams, Office 365 and bespoke business insight applications to 500 people in multiple locations.
A suite of tests can be undertaken against public-facing and intranet sites to determine the validity of Accessibility related mark-up. We identify these by comparing the site to the WCAG2 AA validation standard.
A report is created that summarises and categories issues, with priority placed on concerns relating to site elements associated with resolution e.g. header, footer, and navigation, as addressing these will likely have the most impact in reducing site non-compliance.
After dealing with common site elements, the focus of accessibility testing is directed to content that is generated statically or within a content management system through an iterative process of issue resolution and regression testing.
Depending on the nature of errors, it may be beneficial to implement a programmatic solution to automatically prevent future content issue re-occurrences.
It is recommended that having undertaken and established an initial baseline, a similar exercise is initiated on a recurring (perhaps quarterly) schedule so as to ensure ongoing accessibility standards adherence - website content is subject to change over time and any discreet alteration can introduce future errors.