Transforming a government website with 200 content authors, tens of thousands of pages, and close to 100 different content templates into a responsive design system is tricky business. In 2013, we led a project to update and future-proof one of Canada’s fastest-growing municipalities’ main communication channel: Surrey.ca.
The responsive redesign achieved unanimous support from city staff, business stakeholders, council, and the mayor. Mobile traffic has increased by 300% since launch. The improved governance and content workflow processes have facilitated new collaborations between silo’d City departments. The Surrey Web Team described this as one of the most positive changes in recent history for the City’s external and internal communication. Most importantly, it created a sense of cohesion through a wholehearted responsive design process.
This project required a new approach. We needed the ability to connect deeply with everyone on our project team: client, vendor, and audience. We needed to get comfortable with imperfection, and fight through difficult moments as a team. We let go of our usual need to protect ourselves and maintain control, and worked together to solve our responsive design and adaptive content problems. Our collaborative creativity was a catalyst for changing the way the City communicates.
What you’ll take away from this talk:
- Understand how a responsive design process impacts team dynamics and workflow
- Learn how to encourage collaboration across departments and conquer organizational silos
- Hear how a responsive discovery can change a project (and why that’s okay)
- Get cozy with your customers, stakeholders, and content authors – we’re all allies in the fight to make the web a better place
159. WEB TEAMALL TEAM
WORKING WITH THE CITY OF SURREY WEB TEAM
BUSINESS UNIT
DOCUMENT FUNCTIONAL
REQUIREMENTS
DOCUMENT CONTENT
REQUIREMENTS
KICK-OFF MEETING
APPROVE CONTENT
REQUIREMENTS
GATHER CONTENT
REQUIREMENTS
CONTENT
REQUEST
BU MANAGER
BU + WEB TEAM:
Meet to discuss project
requirements and timeline.
Marketing should be present for campaigns
IT should be present for applications
2 MONTHS BEFORE LAUNCH
WT SPECIALIST:
Document all functional and
technology requirements
Sign-off by BU and WT
required
WT EDITOR:
Document all content and
editorial requirements
Sign-off by BU and WT
required
BU EDITOR:
Gather initial content and
functional requirements.
Fill out “Starting a web project”
questionnaire (forthcoming)
BU MANAGER
160. CREATE FUNCTIONAL
REQUIREMENTS
EDIT
CONTENT
PUBLISH
FINAL
APPROVAL
REVIEW/EDIT/ARCHIVE CONTENT
[EVERY 12 MONTHS]
REVIEW ANALYTICS
[EVERY 6 MONTHS]
SUBMIT TO
WORKFLOW
CONTENT ENTRY
AND MIGRATION
CONTENT
APPROVAL
BU EDITOR:
Migrate all new content
into OpenText CMS
1 WEEK BEFORE LAUNCH
BU EDITOR:
Migrate all new content
into OpenText CMS
BU MANAGER:
Approve all editorial content
1 MONTH BEFORE LAUNCH
WEB TEAM:
Compile analytics data from past 6 months
BU + WEB TEAM:
Meet with BU to review and recommend next steps –
edit or archive content
WEB TEAM:
Compile analytics data from past 6 months
BU + WEB TEAM:
Meet to review and recommend changes
WT EDITOR OR WT SPECIALIST
WT EDITOR + WT SPECIALIST
WT EDITOR:
Edit editorial content for
adherance to web writing guide
and semantic content (if neccessary)
in parallel:
WT SPECIALIST:
Build all necessary functional
and technical requirements