Methods of working
Getting a digital solution off the ground is a multi-step process that involves active collaboration between various teams. This document aims to provide an overview of the tasks involved and details what goes into developing a solution. During the engagement, I end up accumulating (and delivering) the following documents and assets:
Project brief - created from our initial meetings, conversations and helps design the initial scope of work.
Statement of work - this document becomes a contract and describes the rules of engagement. It is intended to be enforceable by law and lists all the details of what is being built as well as:
Project objectives
High-level scope
Agreed KPIs
Team roles and responsibilities
Client RACI (stakeholder) matrix
Milestones and timetable
Risk factors and mitigation
Escalation points
Warranty Sign-off processes
Budget, costing and payment schedules
Experience design approach - this document is a narration of the product strategy and formalises the project vision. Detailing the research and theory of why we’re building what we’re building. A project of any scale should not begin without the right level of planning and strategy. This document makes sure our approach is understood, and nothing is lost in translation. Items include:
Project hypothesis
Usability review
Data Analysis
Web Analytics
Expert Interviews
Surveys
Behavioural analytics
Task Analysis (Jobs to be done)
Content Audits
Information Architecture (site-map)
User Testing Plans
UX assets - when we talk about UX assets, we mean elements that define how the product should function. The data we collect provides the foundation for behavioural archetypes, experience maps and depending on the size of the project, the following items:
User Flows
Content Flow
Wireframes (template definition)
Cross-channel user management
Pattern Library
Component functionality
Basic functional prototype
UI assets - when we talk about UI assets, we mean elements of how the product should look, feel and interact. Depending on the size of the project the following items are usually created:
Component UI design
Interaction documentation and visuals
Tone of voice documentation
Digital guidelines
High-fidelity functional prototype
Solution architecture document - this is a technical requirements document that defines the platform, its architecture and the functionality of what is to be built. It serves an essential role in communicating with stakeholders, engineers and ensuring successful outcomes. Documentation requirements differ based on the technology and methodology used to complete the project and other factors, but it will usually cover these areas:
Solution Overview
Business Case
Feature Backlog
Technical Solution
Logical architecture Diagram
Architecture Principles
Physical Architecture
Environment development
Legacy system management
Software selection
CMS Solution
Platform Choice
Integration
Technical Risks
Non-Functional Requirement documentation - this document specifies the criteria for the operation of a system. It typically details:
Accessibility
Browser and device support
Backup and recovery
Platform maintenance
Performance expectations
Platform availability
Deployability processes
Security measures
Monitoring support structures
Law Compliance
SEO
Operations and business as usual training
QA strategy - this document describes all activities and collaboration procedures that are required to execute the project successfully within its constraints and ensures expected quality.
Content migration plan - this is a more detailed document that lists the mapping of content architecture and taxonomy to the new platform.
Client project team
To help us during this process, we would need the following client stakeholders available during the project:
Agency project delivery team
Our deployment and engagement methodology differs from project to project. But usually comprised of members from the Client services, Project Management, Design, User Experience, Business Analysis, Data Science, Software Development, Content Management and Quality Assurance teams.
Project track
Project tracks are planned in a way that reflects an Agile delivery approach, an example of a plan we expect to follow, looks something like this:
Post-launch Optimisation
Once we deliver the final build, we don't just wash our hands of the project. What we suggest to most of our clients is our site monitoring and optimisation package so we can support you going forward. Our packages usually include:
Site Monitoring - we create quarterly reports that are tracked against business goals (KPIs). The purpose of these reports is to provide actionable data and insights to help the business make key changes and adjustments.
Search Engine Optimisation (SEO) - with access to your Google Analytics platform we can monitor performance and action insights. Our goal is to optimise content and increase site traffic.
Behavioural Tagging - based on an agreed set of KPIs we can tag your digital channels to track user behaviour. This will help us Identify barriers to completion and journey pain points. The goal is to see what we can do to improve visitor retention rate and favourable user sentiment.
A/B and Multi-variant testing - with data and insights gained from the business and our Site Monitoring, we can suggest content approaches and test against multiple hypotheses. The goal would be to determine which layouts, call-to-actions and design elements are most compelling to different user groups.
Content Strategy - using a combination of social listening, industry trend knowledge and SEO, we will be able to provide recommendations on how messaging and content could be improved and see whether the topics you're talking about are resonating with your audience.
Last updated