As web practitioners, we try to define ‘best practice’. We are seeking to convert our clients’ needs and wishes into tangible solutions. Should we do this by choosing better platforms, like a reliable content management system or a groovy new front-end framework? Additionally, can time be saved and efficiencies be found through better requirements gathering?
I would like to explore, in this short article, some of the many ways that good systems can help web practitioners deliver more coherent and relevant results, with a few examples.
Website creation is not simply a passive process where the client lists various ‘must haves’ and the agency they have hired obediently creates a website. Needs are often things which the client may not yet be aware of, or are addressed by functional solutions the client was simply not aware were possible. Which systems, if any, should you as a web practitioner adopt to give your clients the best result?
I am going to approach this subject from the point of view of a small agency, since it’s often best to write from experience. I work in one called bu-s.com – and by small I mean a couple of guys – a designer and a developer (me). That’s simplifying our roles perhaps, since being small, we need to man all the pumps. So since we’re lean and mean, we don’t need distractions like silly old systems, right? After all, we’re busy adding projects to our pipeline and handling our current projects. Who has time for laying out elaborate plans?
At bu-s.com, we tend to discuss such things; such as whether we are actually talking about a process rather than a system or vice versa.
System (a definition)
“a set of principles or procedures according to which something is done; an organized scheme or method.”
Process (a definition)
“a series of actions or steps taken in order to achieve a particular end.”
Maybe we’re looking for a combination of these two definitions, since we need to have a defined set of procedures (which we can also intelligibly explain to the client) and these procedures tend to be done in a logical sequence.
System can be a catch all term in this context. It’s probably more than simply sitting down with your client at the start of a project and asking them to open up and tell you their company’s darkest secrets. If your client is telling you lots of relevant stuff about their business, thus helping your work: that looks like the start of a requirements gathering process, excellent! If you’ve found a nice front-end framework, great. Frameworks generally aren’t our thing at bu-s.com, but hey, you need to navigate these issues for yourselves.
If you can justify your choices to yourselves, perhaps you have the beginnings of a system and if that system can be put into an understandable explanation, why not have it set out on your agency’s website? It’s a selling point and it can only show potential clients you have a sane methodical approach.
As there is more to the force in Star Wars than just light and dark sides and midichlorians, we at bu-s.com feel the best systems take a holistic view of a web project, including all its aspects. Projects have a beginning, middle and an end, thus requiring systems which observe this progression and ensuring certain actions are taken by our agency at each stage. By the way, if you don’t know what midichlorians are, just watch Phantom Menace. Actually, on second thoughts, just google it.
So, for this article, I thought I would look at a couple of examples of systems and processes. I also felt I should draw from experience in different fields in order to demonstrate that systems benefit many different kinds of project, whether they involve content curation and creation, design principles and even the code we create to make things work.
The esd-toolkit provides the various local governments in the UK with a system to ensure that all their various services are ordered logically, and in such a way that citizens can browse to the different services, such as Litter collection and Libraries, without an intimate foreknowledge of the content. There are lots of different local authority services and these don’t simply follow a linear logical order. The esd-toolkit allows many routes to the final destination. Just look at the edinburgh.gov.uk website to see the fruits of the toolkit. The various Edinburgh Council services are sensibly ordered on the homepage and throughout the website. UK councils decide individually as to how explicitly they refer to the this system, such behind drop down, concertina menus or as explicitly as City of Edinburgh Council.
The UK local government community worked together for ten years in order to perfect this system. The effort was worth it, since all users of local government services can expect to find the same basic structure for services on most local government websites. This has benefits both for those maintaining local government websites, as well as for the user of the services.
I remember when house styles were something to define and then guard carefully, especially in the days of print. We didn’t want people externally, or internally for that matter, badly implementing the brand. The agency tasked with the creation of the branding and the subsequent laying out of the house rules, would present their client with a glossy brochure with the styles, pantones, fonts etc. carefully laid out with dos and don’ts. Brad Frost alludes to these carefully set out rules in his presentations on pattern libraries. He sets out a model of breaking styles down to the ‘atomic level’ on websites. Showing how one group of page elements relate to parents and so on. This level of detail not only clarifies the implementation of UI and branding for the designers, it can also clarify the logic of the design for the client. Regardless of whether the client pays a great deal of attention to these efforts, it at least demonstrates the level of care taken by the agency to get things right.
Brad Frost also shows how this attention to detail can extend to coding conventions: where there is agreement on how CSS classes are written by the agency, whether for a specific project or arguably for all an agency’s output. For instance, do you use underscores between classes, camel case, one long word etc? As a project gets bigger and perhaps new participants get involved, these systems really start to make sense.
In order to get a clear picture of what the client wants us to do at the start of a project, we need to start extracting the requirements from the collection of thoughts that often exists in the ether. These are not necessarily self-evident and require a bit of detective work. Requirements gathering is a long established discipline within IT and should also be part of the armoury of web agencies. In large IT projects, this can become a large but necessary time investment. David Benyon, among others, describes the process of capturing the needs of an organisation and then extracting discernible requirements, followed by abstracting these into user stories. In doing so, we learn how the product should behave in its interaction with the user. Before creating models such as flowcharts and UML diagrams, the business requirements of an organisation are included before abstraction into generic user stories and functional modelling. Capturing the business requirements can be done through interviewing the client or their colleagues. Record this conversation (with permission of course) and then go through the conversation with a colleague, noting the requirements you find within it. It helps to take purely subjective biases out of the analysis – also, two heads are better than one for picking out important details. This is different to simply taking a list of the client’s perceived requirements. We are seeking to understand the client’s current business environment and through this, their interaction with the technology in question.
At bu-s.com, we have created our own process for taking a project from inception to completion. It aims to give the client the reassurance that we are not simply taking pot shots at an answer, but the result is based on reasoned analysis.
Steps in our project process:
1. Initial conversation/conversations.
2. Visual inventory – A mood board with very structured and specific questions.
3. Engagement document – A contract, quote, payment schedule, suggested approach and initial research findings all rolled into one doc.
4. Element collage & strategy planning
a. 1st Iteration – Initial concepts and ideas based on initial research. Identifying objectives, audience, and key performance indicators
b. 2nd Iteration – Development of initial ideas and concepts which were successful in the first instance.
a. Prototyping – Prototyping designs, processes and content.
b. Testing – Testing code, functionality, accessibility.
7. Post-launch review – Check-in around a month after the project’s completion
The steps in our process balance the need for accurate requirements gathering and the expectations of clients. As Ben Usher Smith mentioned in his article on progressive enhancement, we need to manage the client’s expectation regarding turnaround and the need to reach the ‘core purpose’ of a project. Through setting out our process on our website and evangelising progressive enhancement and requirements gathering, we can produce results that exceed expectations and help to make a better web.