First published on the University of Bath Digital Marketing & Communications blog
The University of Bath has an in-house digital team. There are currently 11 of us and we are a mixed-discipline team of designers, developers and editors.
In recent weeks, the Digital team has been taking a hard look at what we do and how we do it in the interests of being more effective. We’ve run retrospectives of our work, been in conversation with folks we do work with and for around campus, and we’ve studied the way other digital teams work.
Our team provides digital products and services related to study and research, which are used by the University’s students, staff and partners as well as by the general public. When we looked at other teams in the digital industry (who provide products and services), we saw some had written down a set of principles that they worked to and this practice resonated with us.
From what we understand, delivery (or design) principles have many benefits. They draw a team together and provide a common thread throughout all its work. They help end-users understand the efforts that have gone into content, designs and features, and how the team might develop things in the future. And, they serve to manage the expectations of delivery partners and senior management about how the team is organised and what motivates it to work to the best of its abilities.
As we have reflected on our past work and the sort of team we want to be, we have zeroed in on a set of beta (or trial) delivery principles of our own. Here’s what we are starting with:
1. Put users’ needs first
The products and services we deliver should be driven by the needs of our users, not what suits us as providers. This means investing the time and effort to regularly engage with users and the contexts in which they interact with what we produce.
2. Make decisions based on data
Simply stating a user’s needs is insufficient, we must have evidence to make it compelling. We have been hired because we have good opinions and instincts based on professional experience. But we need to counsel these with sound qualitative and quantitative data, and use that data to make objective decisions about what to deliver and when.
3. Release iteratively and often
We will not store up ‘big bang’ releases because that is frustrating for the users and risky for the organisation. We will start small with the minimum viable product, we will test it and we will release it as soon as possible on a timescale of days and weeks, rather than months or years. We will repeat the process many times over, adding to our products and services based on feedback, tests and changes to technology.
4. Keep it simple and consistent
We run a big site with many supporting many channels, which draw in a diverse set of users who have an expectation of quality associated with the University of Bath domain. We will do the hard work not to over-think or over-complicate things. Whether a user is new or experienced, task-driven or browsing, they will able to get started quickly, flow through the process with ease and trust the integrity of the results.
5. Do the hard work behind the code
The success of a great digital product or service doesn’t rest entirely on what appears on screen. To deliver accurate, pleasing and sustainable products and services means investing in simple instructions, efficient workflows, accurate monitoring and great support. Often this can all be provided by the Digital team directly but we also expect to work hard with our partners on getting this right.
6. Work in the open
We will share what we are doing as often and as freely as possible because we believe that scrutiny makes us a more effective team and our products and services better. This extends from our product backlog through to the data generated by our output. We will ensure that we provide updates, explain our actions and demonstrate where and how we have taken on board feedback.
Now that these principles have been written down and shared, the hard work of putting them into action begins. We will apply these principles regardless of the scope or scale of delivery. We will apply these principles to our delivery regardless of whether we are a designer, developer or editor. We will apply the delivery principles regardless of whether we are working completely within Digital or with people outside our immediate team. And you can hold us to account when something we produce seems to be falling short of these principles.
There is no orthodoxy or set of rules to follow when choosing principles. Delivery principles are context specific, based on who’s in the team, what the team is having to do and over what period of time. Our principles are based on best of breed examples in the wider digital industry but have been adapted for the specific circumstances of this University’s Digital team.
As we develop as a team and work our way through our backlog and goals, we expect these principles to evolve. They will change based on our own direct experiences and on the feedback we receive from our users and co-producers. As and when substantial changes take place, we’ll keep you updated. Please also check back for posts capturing case studies of these principles being applied to real products and services that you can click on and use.
We’ll always keep the latest version of these principles published on our wiki.