The purpose of this article is to give a high-level insight into the UX process I incorporated for one of my latest projects; a website for the Police ICT Company.
The company was formed to provide IT strategies to develop Police IT frameworks across all the forces in the UK. They required a website would publish national policing IT standards and provide knowledge sharing facilities amongst other content.
It is important to state that after every stage of the UX process, feedback was sought from both the business and the end users. This is a fundamental necessity in UX design and helps fit into an agile structure. The feedback would be taken into consideration and acted upon if appropriate after further discussions with relevant key stakeholders.
Requirement gathering for business projects usually consists of finding out what the business wants and what the end user wants. It was already clear that there were to be three main end users.
Several face-to-face meetings were held, at first with the business and then with representatives from each of the three main end user groups. The meetings were documented along with completed questionnaires and placed on the project wiki for easy access to everyone.
With the project being in the public sector, I identified the gov.uk website as a valuable resource for three main reasons:
- Presenting information in a way that users can easily find what they’re looking for
- The design standard documentation they make available
- Their site adhered to WCAG 2.0 AA standards, which is what the Police ICT website would need to also conform to
Part of my role in the project was to provide the national standards for UX, so the gov.uk site’s design manual was an excellent benchmark.
Along with screenshots, I provided annotated notes to help me describe to other members of the project what sections of their site were most useful to us and how.
As part of the analysis phase, I created personas to illustrate the findings from requirement gathering and researching. I created one for each of the three main end user groups but created two for the largest of those groups to cover as much of the demographic as possible.
These were made available on the project wiki, so if there were any key decisions to be made along the way, the personas could remind everyone what the original requirements of the project were.
4. User journeys
The user journeys are extensions of the personas, highlighting the steps each of the fictional users take to achieve their goals. These can also be depicted as a flow diagram but I kept mine as simple written step process.
5. Site map
This is the highest-level of design, mapping out all the pages of the site and giving clear guidance of what goes where. I used Gliffy for this as it had a useful plugin tied into the Confluence project management software we were using.
6. Wireframes and Prototyping
With the site map in place, I could start laying out the elements on all the main template pages of the site. The site was to be responsive so the wireframes were always represented with three device sizes in mind; desktop, tablet and mobile.
It is usually a good idea to design with a mobile-first approach as it helps focus what content is most valuable to each page. This helps understand visual hierarchy and in turn makes laying out the sections of a page for more logical.
My favourite wireframing tool at the moment is Balsamiq so I utilised it’s capabilities to produce wireframes very quickly. You can also stitch them together to form a clickable prototype to give the users something to play with.
7. Visual Design
Funnily enough, this is my favourite stage of the process, where colour, fonts, imagery, textures etc bring the project to life. A combination of Photoshop and Illustrator were the tools of choice.
The biggest factor that I had to take into account was the accessibility level of the site set at WCAG 2.0 AA standards. Every element of the design (e.g. font sizes, colour contrasts, navigation etc.) had to be checked. Also, and corresponding code (e.g. any ARIA specifications) had to be detailed to the developers.
I presented three separate designs to the business and end users to identify which would be most suitable to take forward. The business had some brand rules in mind, most notably the use of purple, so these were also in consideration.
8. Style guide
Once the design had been signed off, I set about creating a formal style guide to hand to the developers to aid them with the build. A descriptive PDF was made available to them using Illustrator and InDesign.
I also chipped in with HTML and CSS code snippets for various elements.
9. Comms materials
One of my other responsibilities was to provide the business with communication material that complimented the new site. So this was another task after the visual design had been signed off.
These included business cards, newsletter design, email signatures, PowerPoint templates and Word templates for meeting agendas, letters and press releases.
There should never be a set design process to follow. Each project, and its individual caveats, should have a design process catered to its needs. Designing a web site for a mate will have far less stages than the ones I have described for the Police ICT Company.
With such a big project and especially with the public-sector factor, it was necessary to apply so many UX techniques and document everything along the way. As I have described so many stages, I hope that it helps illustrate the importance of each stage and their reliance on one another.