Design for people
The people using your site and their needs should always be put first. What do they want to know? What do they need to know? What is the best way to consume this information? Where is the user when they are accessing this content - in a library, at home or on the tram?
We need to make sure we fully understand what content needs to be communicated and the technical limitations placed on delivery of that content through their environment or devices. Without this understanding we risk designing a website that is not useful or relevant, or something that is difficult to consume.
Design should be invisible
Good design should go unnoticed by the user. Content should be consumed effortlessly without distraction. A key to achieving this is to design using real content as opposed to placeholders. By using real content examples we discover hidden problems and issues. Design is about communication, not decoration.
One. Thing. At. A. Time
Humans are able to do one thing at a time. As our users are humans (most of the time), they are not able to process more than one thing simultaneously. It is our job to prioritise content and build hierarchies into it in order to present our content in a linear way that is easy to digest.
There should be always a clear difference between the main content on a page and secondary content. Help people by providing them with suggestions about where to go after consuming the main content. Build pathways for people to follow.
Make it simple
Websites are often inherently informationally complex and it is hard to make them appear simple. This is exactly what we should be striving for in the display of our content and information architectures.
We provide information and services that are of great importance. By working hard to make sites simple and usable, we give people an experience that is efficient and doesn't waste their time. Especially when we are creating sites and services that students and staff _have_ to use, we must ensure that we optimise continuously. With great power comes great responsibility.
Iterate. And never stop.
By starting with the basics - a minimal feature set and an early release - we get the chance to test with real people early. From there it is easier to add features and refinements using constant feedback.
In most cases it is better to avoid 200 page specifications documents as these can turn into a bottleneck, or worse, fail to address the real users needs completely. Working iteratively minimizes the risk of large failures.