What are your principles?
I recently surveyed the University’s digital development & management communities on what was important to them. In this post I’ll share the results and a few opinions on the value of design principles.
We did some work on philosophy and principles in August within the Programme team at an awayday, and the hands-on workshop I facilitated there lead me to think a bit broader.
Then (co-incidentally) I became involved in a project proposal for the development of digital standards as part of the Digital Transformation initiative, which prompted me to try out a quick survey with the University’s digital communities.
Working within our team, it was clear pretty quickly that we all broadly felt the same way – putting our customers (the web publishing community) first, using evidence to inform our work, and ensuring sustainability of services were important to us all, regardless of role or specialism.
But what about the rest of the University? All the web publishers, project managers, developers, service managers and so on who work so hard to maintain a digital presence for our organisation? Were there any trends in what drives attitudes and behaviors?
Design principles survey
So I ran a quick survey, which was open for a week in mid-September.
I took a look at the principles that other teams publish (the Government Digital Service being the main one, but there were others) and created a list of 18 which was randomised when presented to each survey participant. I asked them to pick the 7 that were most important to them, and add others at the end if they had suggestions. I also asked a few demographics questions.
Government Digital Service design principles
As usual with this kind of survey, we see that a small number are significantly more popular than the rest. We haven’t seen the accentuated long neck and long tail but this is mainly due, I believe, to the small(ish) sample of 111 respondents and the relatively large number of choices I allowed each participant.
111 colleagues across the University contributed their opinions on what’s important when it comes to design principles.
| Principle | Votes | Cumulative % |
|---|---|---|
| Start with user needs: If you don’t know what the user needs are, you won’t build the right thing. Do research on an ongoing basis. | 70 | 10.1% |
| Understand context: Don’t design for a screen, design for people. We need to think hard about the context in which they’re using our services. | 54 | 17.8% |
| Make sure users succeed first time: Create a service which is simple to use and intuitive enough that users succeed the first time. | 51 | 25.1% |
| Do the hard work to make it simple: Making something look simple is easy. Making something simple to use is much harder — especially when the underlying systems are complex — but that’s what we should be doing. | 48 | 32.0% |
| Provide ongoing support: The work doesn’t stop when something goes live. We must care deeply about the running of products and services, from their inception, deployment and throughout the time they’re operational. | 48 | 38.9% |
| Be consistent, not uniform: We should use the same language and the same design patterns wherever possible. This helps people get familiar when interacting with us. But this isn’t a straitjacket or a rule book. We must improve or change in the future when we find better ways of doing things or the needs of users change. | 46 | 45.5% |
| Understand security and privacy issues: Evaluate what user data and information the digital service will be providing or storing and address the security level, legal responsibilities, privacy issues and risks associated with the service. | 46 | 52.2% |
| There is no “done”: Perfection is a mythical state. Indeed, “Perfect is the enemy of the good”. Enhancement of services and user experiences is an ongoing process, and development needs to be continuous. | 45 | 58.6% |
| Iterate and improve frequently: The best way to build good services is to start small and iterate wildly. Release early, test them with actual users, add features incrementally, delete things that don’t work and make refinements based on feedback. Iteration reduces risk. | 42 | 64.7% |
| This is for everyone: Accessible design is good design. Everything we build should be as inclusive, legible and readable as possible. We build for needs, not audiences. | 42 | 70.7% |
| Build digital services, not websites: A service is something that helps people to do something. We must uncover user needs, and build the service that meets those needs. Of course much of that will be pages on the web, but this isn’t about building websites. | 33 | 75.4% |
| Make things open, it makes things better: We should share what we’re doing whenever we can. With colleagues, with users, with the world. Use open standards and common platforms where available. Share code, share designs, share ideas, share intentions, share failures, share learning. | 33 | 80.2% |
| Design with data: In many cases, we can learn from real world behaviour by looking at how existing services are used. Let data drive decision-making, not hunches or guesswork. | 30 | 84.5% |
| Use a multidisciplinary team: Sustainable multidisciplinary teams that can design, build and operate the service, led by a suitably skilled and senior service manager with decision-making responsibility, are essential to a successful ongoing service. | 25 | 88.1% |
| Consider the end-to-end service: Be able to test the end-to-end service in an environment identical to that of the live version, including on all common browsers and devices, and using dummy accounts and a representative sample of users. | 20 | 90.9% |
| Work in the open: We must share what we are doing as often and as freely as possible because scrutiny from users and colleagues makes us more effective and improves our products and services. | 20 | 93.8% |
| Do less: We should only do what only the University of Edinburgh can do. If we’ve found a way of doing something that works, we should make it reusable and shareable instead of reinventing the wheel every time. | 19 | 96.6% |
| Digital by default, but plan for being offline: Plan for the event of the service being experienced offline, whether than be due to temporary downtime, or the needs of a particular user. | 15 | 98.7% |
| Requirements are assumptions: We must view every feature or development requirement on the basis that it is a hypothesis. We believe that by delivering that feature we will achieve an outcome that supports our services. On this basis we must measure the effectiveness of what we do. | 9 | 100.0% |
Top responses put the user first
It’s notable that the top three choices, accounting for 25% of all votes are user-centric. They all focus on designing for user needs and prioritising their success interactions.
- Start with user needs: If you don’t know what the user needs are, you won’t build the right thing. Do research on an ongoing basis.
- Understand context: Don’t design for a screen, design for people. We need to think hard about the context in which they’re using our services.
- Make sure users succeed first time: Create a service which is simple to use and intuitive enough that users succeed the first time.
The next four most popular took the cumulative total to just over 50%. So in total 7 principles attracted over half of all votes.
- Do the hard work to make it simple: Making something look simple is easy. Making something simple to use is much harder — especially when the underlying systems are complex — but that’s what we should be doing.
- Provide ongoing support: The work doesn’t stop when something goes live. We must care deeply about the running of products and services, from their inception, deployment and throughout the time they’re operational.
- Be consistent, not uniform: We should use the same language and the same design patterns wherever possible. This helps people get familiar when interacting with us. But this isn’t a straitjacket or a rule book. We must improve or change in the future when we find better ways of doing things or the needs of users change.
- Understand security and privacy issues: Evaluate what user data and information the digital service will be providing or storing and address the security level, legal responsibilities, privacy issues and risks associated with the service.
Notable principles falling just outside this top group focus on the importance of accessibility, and a recognition that there is no end state in the development of digital services.
Respondent demographics
There was a good response across the colleges and support groups, with the largest number of contributors perhaps unsurprisingly coming from Information Services.
Similar numbers contributed from across the University’s colleges and support groups, with slightly higher numbers from Information Services.
The largest group contributing was the website and content manager community, which again is unsurprising given it’s probably the largest group among those of us involved in digital management.
Staff in a range of roles relating to management of our digital presence contributed
Of those who chose ‘other’ and went on to describe their role there was a roughly equal split between those who undertook more than one of the roles I offered as options (note for next time – allow multiple selections) and those who had a more specialist role; for example accessibility advisors, open educational resource specialists, librarians and even our Chief Information Officer, Gavin McLachlan.
Trends in response by role
I took a very quick look at responses when roles were filtered, and a few things stood out:
- Across all groups, the top response was always to start with user needs.
- Designers and developers put greater importance on security and privacy, accessibility, and open source principles.
- Website managers cared far less about open source (it was their bottom item).
- Project managers and business analysts didn’t vote much at all for principles around iterating and improving, there being ‘no done’, and providing ongoing support.
- Service and product owners felt the opposite and allocated a lot of votes to iterating and improving, and the importance of continuous development. They also prioritised accessibility and security.
Conclusion
As User Experience Manager, it was incredibly heartening to see how strongly the digital communities feel about the importance of putting users first.
Prioritising user experience is the unifying principle between us all.
It’s also important to recognise the differences in opinion among the community, which can be a cause of tension in development teams involving these roles. The reality is, our roles value different things (compare project managers to product owners, for example) and what is important to one community is almost irrelevant to another.
This suggests a few things to me:
- We need University-wide service and design principles that set out to us all what the organisation values and wishes us to prioritise.
- We need to work in cross functional teams as a matter of course. It’s the only way to enable us all to get a proper understanding of others’ roles, values and motivations.
- Most importantly, we need to act on our shared principles, and start prioritising the user experience through our working practices.
An inconvenient truth
The awkward question to ask then, is why do we do so little about understanding, communicating and optimising the user experience? Other organisations (admittedly not in higher education, typically) have user experience teams, directors of user experience, Chief Experience Officers, even.
I believe I’m the only person in the University with a role primarily focused on UX. Possibly I’m the only person in the sector in Scotland. And certainly one of a select few in the UK. (I’d love to be wrong about this. If you work in UX in higher education get in touch, it’d be great to collaborate with you!)
But more important than job titles and roles is working practices. Great user experience doesn’t happen by accident, and it doesn’t come through leaving it to ‘genius’ designers. It comes from adopting tried and tested methodologies that foster shared understanding of, and empathy with, our users.
We, as an organisation and as a sector, need to do this much, much more.
2 replies to “What are your principles?”