We're building a website: Wireframes and Use Cases

Like every profession in the world, website development is filled with insider words, acronyms and abbreviations (for example, UX is short for User Experience). My education into the world of website buzz words was like anyone learning a second language. First of all I was bewildered, then I tentatively picked it up and used it very, very hesitantly ("is that what you mean by UX? Is that thing I'm pointing at right now an example of UX?"), then I grew confident with select words and phrases ("the home page will aggregate content", "the responsive design will showcase the aggregated content on tablets"). I never even used the word "aggregate" before March last year and now my life is one big aggregation.

I've basically spent the last year and a half nodding sagely in meetings while people say words I don't understand and then rushing to Wikipedia to find out what I've just agreed to (I'm kidding- sort of). 

Sometimes Wikipedia didn't help. Here's a description of the web application framework Django that the Interaction Consortium are using to build our website:

"The core Django MVC framework consists of an object-relational mapper which mediates between data models (defined as Python classes) and a relational database ("Model"); a system for processing requests with a web templating system ("View") and a regular-expression-based URL dispatcher ("Controller")."

Sure.

Us and them

A massive gulf exists between my humble grasp of words and terms like "responsive design", "information architecture", "UX", "content management system", "agile development" and the world of actual programming, building and engineering. And it begs the questions: How do we find a shared language for developers to discover accurate insight into client needs? How do developers convert these needs into a meaningful system of functional explanations and granular steps necessary for engineering?

There are three very important solutions to this question. First, choose a development team that doesn't consist of egotistical geeks who play the jargon game to bewilder you into submission (M&G has been very, very fortunate in choosing a smart friendly team with Pure and Applied, Toben and the Interaction Consortium). 

The other two solutions are wireframes and use cases. These valuable development tools have helped us discover exactly what we want in collaboration with the website team. 

Crossing the gulf 

Wireframes represent the interface without getting swamped in design detail. This sketch concisely articulates the user experience in a visual language shared by designers, engineers and lay people. But because wireframes are simple and don't get bogged down in design detail their focus is function, and the process is discussion and intensive reiteration. 

Early wireframes sketch - early-December 2012.

Finding our way

As you can see above, we were still juggling with our original conception of the website. The directory of places and associated events leads the content on the homepage. The carousel features individual places and underneath are buttons that take us to museums, galleries and Aboriginal cultural centres. There is generic content in What's On and News (Video, Event, Touring Exhibitions) but there's no commitment to a style of content production, no definitive approach to the homepage. We're missing that X factor that makes the website stand out.

The X factor

Final wireframe for the M&G NSW homepage.

You don't need to know anything about the magical wizardry that goes into website development to immediately see the difference between this version of the public home page and the one above. When users come to our front door they are greeted by a selection of stories (interviews, onsite travelogues about regions, exhibitions, festivals, opinion pieces and videos highlighting programs). The content is thematic and formatted (Ask a Curator, Off the Beaten Track, Hidden Treasures), invites users to visit individual museums or galleries or highlights the connections between organisations. Simply put, the front door is like a "magazine" rather than a directory.

But the genius of the above sketch is the right hand column: despite all the exciting content this ubiquitous feature provides users with a consistent doorway to your places, trails and events across NSW. If the user doesn't want the stories on the page they still have direct access to the hard data. 

Why wireframes work

These very visual tools allowed everyone to collaborate and agree on functions intuitively rather than abstractly. It gave everyone a real sense of what the website would be like and provided the necessary detailed script for designers and developers to work off.

What happened next?

Pure and Applied finished the wireframes in January and Interaction Consortium converted them into Use Cases.

What exactly are use cases?

"In software and systems engineering, a use case is a list of steps, typically defining interactions between a role (known in UML as an "actor") and a system, to achieve a goal. The actor can be a human or an external system."

Thank you Wikipedia. 

In early February, Alastair Weakly and Simon Johnson from the Interaction Consortium laid out all the use cases on our meeting table. It wasn't long before we ran out of table:

Alastair Weakly, IC and Katie Duncan, M&G lay out the use cases.

The use cases close up.

A couple of use cases:

"As a sector editor I have an easy way of picking opening hours times."

"As a user I can see a list of the organisations mentioned in an article at the bottom of the article (created manually not automatic)."

We can break down these sentences into their "Actor" who is defined by their user status to our website. So a "sector editor" is the person chosen by an organisation to upload content onto our website, a "user" is anyone visiting the website. The rest of each sentence describes an action related to a goal. 

The list of use cases need to be comprehensive and exhaustive to define the scope and goals of the project in minute detail. M&G and the developers prioritised some use cases over others (though most were regarded as must-haves) and with a clear list of functions the engineers had what they needed to start building the beast.

But enough about the research part of the process. Next week we'll look at the sexy stuff: the design of the website.