Interview for Senior Developer at Barnsley Council

The slides I created for an interview for the role of Senior Developer at Barnsley Council

Transcript

2. Building our new website ▪ New site: http://new.barnsley.gov.uk ▪ Project 12018 ‘Web Development’ ▪ Part of CSO programme
3. About me ▪ Senior developer at Barnsley Council ▪ Web developer for 15+ years ▪ Worked mainly in the public sector (NHS and Government) ▪ Passionate about the web (and making it accessible to everyone) ▪ Attend and talk at web events across the UK ▪ Hosted ‘The Digital Barn’ for the past three years (Barnsley’s first and only web development conference) More info at http://mwatson.co.uk or catch me on Twitter @mwtsn
4. This presentation ▪ The project requirements ▪ Applying change management ▪ How I ensured the project was completed to plan ▪ Working with others to deliver the project
5. Requirements
6. The drivers ▪ Future council programme ▪ The key driver was to save money ▪ Less maintenance ▪ Online transactions ▪ Allow customers to self serve ▪ SOCTIM survey 2013 results ▪ Digital by default (GDS standard) Our web presence Photo credit: Mick Coulas http://www.revel-ink.com/mickcoulas/
7. The CSO Work Package deliverables ▪ Rationalisation of external websites and an active management approach for new requests ▪ Consolidate web content, reducing maintenance and improving readability ▪ A fundamental content review and refresh ▪ Convert paper based forms to eForms
8. Technical requirements ▪ Produce one website for the council ▪ The website needs to work on our modern web infrastructure ▪ Needs to take advantage of Responsive Web Design to render across devices ▪ The website should provide information, be complemented by a suite of seamless eforms and applications ▪ HTML templates should be created for improved customer journey and enhanced readability
9. Technical requirements ▪ Produce one website for the council ▪ The website needs to work on our modern web infrastructure ▪ Needs to take advantage of Responsive Web Design to render across devices ▪ The website should provide information, be complemented by a suite of seamless eforms and applications ▪ HTML templates should be created for improved customer journey and enhanced readability TFS, C# (ASP.NET MVC Razor Views)
10. Technical requirements ▪ Produce one website for the council ▪ The website needs to work on our modern web infrastructure ▪ Needs to take advantage of Responsive Web Design to render across devices ▪ The website should provide information, be complemented by a suite of seamless eforms and applications ▪ HTML templates should be created for improved customer journey and enhanced readability TFS, C# (ASP.NET MVC Razor Views) HTML5, CSS3, OOCSS (SCSS)
11. Technical requirements ▪ Produce one website for the council ▪ The website needs to work on our modern web infrastructure ▪ Needs to take advantage of Responsive Web Design to render across devices ▪ The website should provide information, be complemented by a suite of seamless eforms and applications ▪ HTML templates should be created for improved customer journey and enhanced readability TFS, C# (ASP.NET MVC Razor Views) HTML5, CSS3, OOCSS (SCSS) Separation of concerns
12. Technical requirements ▪ Produce one website for the council ▪ The website needs to work on our modern web infrastructure ▪ Needs to take advantage of Responsive Web Design to render across devices ▪ The website should provide information, be complemented by a suite of seamless eforms and applications ▪ HTML templates should be created for improved customer journey and enhanced readability TFS, C# (ASP.NET MVC Razor Views) HTML5, CSS3, OOCSS (SCSS) Separation of concerns Design, UX, IA
13. Change
14. Too many cooks ▪ 200+ web editors (200+ different writing styles) ▪ No change control, things broke regularly ▪ Irrelevant, out of date, duplicated or missing information ▪ Navigation influenced by ESD or whoever owned that content ▪ 5000+ PDF documents (many out of date), not accessible ▪ 50+ websites ▪ Not enough control as a web team Our web editors Photo credit: Practical Project Management http://http://simpleprojectmanagement.blogspot.co.uk
15. Introducing configuration management ▪ Must ensure content meets scope of requirements, fits into information architecture. ▪ If there is no justification for content, it should not exist ▪ Content must be subject to full change control, assessing impact on other content, and systems
16. Culture change ▪ Initially locked out all web editors during Umbraco upgrade ▪ Identified a core team of 6 trained web editors, giving them the ultimate responsibility for their sections. ▪ Locked down a lot of CMS functionality ▪ Met with alot of resistance, complaints and escalations... very frustrating ▪ BUT Support requests are now minimal, a lot less firefighting
17. Culture change ▪ Initially locked out all web editors during Umbraco upgrade ▪ Identified a core team of 6 trained web editors, giving them the ultimate responsibility for their sections. ▪ Locked down a lot of CMS functionality ▪ Met with alot of resistance, complaints and escalations... very frustrating ▪ BUT Support requests are now minimal, a lot less firefighting Unfreeze Change Refreeze Lewin’s Change Management Model
18. The plan
19. Project 12018 Work package plan (P2 Gantt chart)
20. Product backlog
21. Did it all go smoothly? ▪ Not quite, we had some issues ▪ Met a lot of resistance from services who did not engage with the process ▪ Web editors were not always permitted to work on the website ▪ Pull on resources from Review and Development work packages meant editors were not always available ▪ Other projects moved and unplanned work got in the way at times ▪ So, how did we do?
22. Lessons learned ▪ Agile approach meant that items could be taken out of a release and put back into the backlog ▪ Because of a lack of engagement from service we had to take a change of tact with our delivery methods ▪ Switched to a JFDI approach ▪ Gave service chance to have a say, if they didn't engage we just delivered best practice ▪ Service got their say at the end of the release
23. Working with others
24. Key stakeholders ▪ We asked as many people as we could what they thought of the website, including council members and service leads. ▪ We asked people what they wanted the website to be ▪ We condensed the feedback and arrived at the following website vision: Our website will give people quick and easy access to our services and clear information about life and work in Barnsley “
25. Third parties ▪ We worked with ‘The Workshop’ to help us define a process ▪ Other local authorities are doing the same, Shropshire is a key player with project WIP ▪ GDS (Government Digital Services) released a lot of guidance from their learnings with GOV.UK ▪ Met with (physically and digitally), these organisations, and watched their presentations to determine best practice
26. The service (the experts) ▪ Service identified stakeholders and test groups ▪ Service helped to identify ‘tasks’ that stakeholders may want to perform ▪ Identified service needs, and transactions ▪ Continuous feedback during release cycle
27. Peer testing and review ▪ Blogged about it ▪ Used social networks and forums ▪ Spoke at events, asked user groups (meetups) ▪ Asked friends and family ▪ Asked the consultancy (Workshop) ▪ Asked work colleagues (including editorial group, and the service) ▪ Used newsletters, surveys and banners on the website to ask members of the public Photo credit: Kimb Jones http://kimb.me
32. Any questions?
33. The outcome (Just a few features, we don't have all day)
34. 40% of our customers view the site on a mobile phone
35. What page am I on?
36. Designed to be mobile first
37. Works on tablets too
38. New print view
39. And of course desktops
40. Landing pages
41. Why do I need all that navigation?
42. Just the important things
43. The F pattern
44. The F pattern
45. The F pattern
46. Ideal reading width
47. Ideal vertical height for scanning
48. Ideal vertical height for scanning