The former occupies every hour (and more) of work and the latter means I'm seldom at home without a paintbrush in hand.
This website project has been mammoth in that it has been a total rebuild. The only content we're reusing are archived press releases and blog posts. Making a 200+ page MVP website read (and look) as if it is all one publication requires a lot of coordination.
It's made me realise that I feel most energised when working on a number of digital projects simultaneously. Flitting between web, email and social media marketing helps me feel in touch with what is going on in the business and wider world.
Being so focused on one project for such a long period of time takes its toll. I'm so blinded by HTML code and the same page designs it's hard to say if what we're working on is still any good!
This is why a project of this scale needs prototyping. This is essential in giving senior management a view about how the website will look and read. Outside of the web team I've found it's impossible for colleagues to visualise an end product which exists in 'Gather Content' combined with templated designs and UX notes. These stakeholders struggle to imagine a finished product which could lead to misunderstandings or scope creep.
For them, there are lots of different ways to showcase a prototype as a proof of concept. They could be as simple as a design mockup (an old favourite of mine as a way to be clear in agency briefs). But, whilst these are good for validating visuals they are poor for testing usability.
Then there are wireframes. These are typically lower quality visually and so quicker to produce. They are good for testing visual hierarchy with users and whether they know what to do on the page. But they offer little in terms of testing aesthetics.
We've decided to go all in and hand code an HTML prototype. This has proved great for testing usability, visual hierarchy and navigation. It also allows testing across devices. The only downside of this approach for me has been the time it has taken to create. Especially as richer design or interactivity has been added.
In fact, we've had to be very clear where the HTML prototype ends and the CMS begins. Otherwise the former grows into a bigger beast than first intended and absorbs time from actually building the live site!
Being able to gather feedback on a version of the website that is 75% right means that we're now not working in isolation anymore. We can bring fresh eyes to the project to help identify any issues with styling or content. For our working prototype we've tried to involve as many stakeholders from around the organisation as possible. These include:
- Senior Management
- Editorial Council and Department Heads
- Wider marketing and Communications colleagues
By involving them people in the creation of the prototype they now feel a sense of ownership over it. This means they are less likely to criticise and more likely to defend it to others.
Ultimately the aim of this prototype is to gather constructive feedback from stakeholders and real users. To avoid the risk of non-constructive feedback we've circulated a survey with a list of predefined questions. This helps to improve the prototype by educating stakeholders about where they should focus.
Of course, we're regularly checking this feedback. We then discuss the more objective comments and see if anything needs and further follow up conversations. We're then putting the relevant changes into practice as we populate the CMS for final go live.
Once this new website is live and the home improvements are finished I intend to have a rest. It would be nice to sit down over Christmas and get fat on mince pies, turkey and fine wine.
I haven't the heart to tell myself yet that this is where the REAL work begins on both counts...!
0 comments:
Post a Comment