• Group into 5-10 groups
• Name the groups
List of 20-50 pages
Decide on 5-8 groups
• Plain English
• Mutually exclusive
• Cover everything
• Provide 5-8 group names
• Place within groups
Thanks kevin, my name is I’m simon jones. I’m head of design and user experience at smallworlders so ultimately though my job is to design an intranet that will engage.
However, as most of us either have found out, are about to find out, designing an intranet can be tough.
So where do you start? Well, early on in my career it looked a little bit like this:
Who wants a blog?
Well, clearly there is a more effective way to do things.
So how do we achieve this? What on a practical level should we do? How do we engage these users?
Well, you may be surprised to know the answer doesn’t lie with the design team.
In fact, this presentation is not even about visuals at all, although they are important. There are loads of examples of great-looking intranets and functionality out there. So go and take a look
But this presentation really is about the process that feeds design.
So, how DO you get from an embryonic, old, sometimes neglected intranet, to a fully designed modern, evolved digital platform that will provide those reasons to log on, return and lead?
Sometimes it can be quite daunting because there are loads of people to please, so many ideas, so many theories.
But I like to say, if you trust the process it will work.
And here is the process that we have evolved up to now.
Start with a kick off.
Do a bit of research. As much research as you can. Its invaluable, and I’ll explain why .
Do a workshop to generate ideas and run through that research.
Make sure all those ideas are attractive to the various types of engaged user that dan mentioned earlier
And to re-visit the scope to make sure we can still do everything we want withing the timescale and resources at your disposal.
Then finally you can get onto the design, build, and launch and all of that stuff.
Today I will take you through the process up till design.
For the most part this will be entirely independent of which technology or platform you use, so it will apply to most large and small scale projects.
…and here is a simplified overview of what I will take you through today.
So lets start with the research.
The first step of the research is really to identify as much as you can about the existing set-up.
Who should have input as stakeholders? And what do they think should be on there? What platforms and content do people currently use? What exists currently in the digital workplace? Often there are other systems in place that cover the sorts of things an intranet typically does, so should they be replaced? Or complimented? ..and what data sets are there? How will we find out what has worked in the past? What do they tell us about our users?
I’ll go through these one by one.
So. Lets start with the stakeholders.
We need to speak to anyone who is ultimately a decision maker or influential in this project. If they are not directly part of the team, if they need to feel like they are involved? Well, now is the time to include them, and here are the sorts of things you need to ask.
How would they describe the new platform? What business needs does it address? Who will use it? What will make it a success, and how would you measure it?
Its important, with these interviews, to figure out which users to speak to, and what their concerns might be. You might not always get the same opinion from different stakeholders. And often, when you ask those users you might get a different set of requirements.
But I’d like to draw your attention to the first 2 question they are particularly important, as they tend to tease out the actual reasons to log on, versus the more exciting elements. And I’ll take you through an example, now, where the difference between the answers was quite stark.
This example is from one of our clients at De Beers.
The stakeholder in question described the platform as a modern social system with great content sharing and conversation enabling functionality so everyone in the organization could share ideas and help each other.
Well, this was a valid and admirable goal, and those would all fall nicely under reasons to return. However, when I then asked about the business needs it addresses – I got a different response.
Finding files, and Accessing campaign assets and guidelines.
As you can see those answers are very different. And it’s those needs that form the real draw for those conservatives and sceptics who wouldn’t come to this platform for a social community or to share information.
Which is why we designed the homepage like this.
So with the stakeholder interviews, make sure you get past the exciting stuff because there lies the reasons to log on.
Wedge will talk a little bit more about content strategy later on so I won’t dwell too much here.
The main points you need to look at here
are exactly what you want to migrate from the old to the new system? We like to aim for 10% migrate, 90% delete, because there’s always out-of-date content, and a new platform is the right time to ditch some of that.
Any content that worked well in the past or failed miserably?
How often do you expect new content to be created?
And of course, you need to know what other projects are planned in the future that could have an impact on this one.
As far as data goes, you need to look at anything that will help you figure out whats popular with your users, who the movers and the shaker are, those enthusiastic ambassadors dan talked about.
You also need to set up some benchmarks that could be used as KPIs for the project.
And as Kevin has gone through a lot measurement of this earlier, so I’ll move on.
On to the most important part of the research phase, which involves investigating your users.
There are loads of techniques research your userbase. Ultimately you need to find out not just what they currently do but why they do it.
What motivates them, what do they need to do every day, that you can solve. And what issues do they have when they try to do it?
I’d like to take you through a few examples that highlight the importance of this stage of the project. The first was some research we did for a platform at Heineken called the brand stage model.
This is a platform to “Capture & Report Market Brand Plan information”
Imagine its your tax return, but for brand managers.
So we interviewed the main stakeholders and identified 2 main goals that they wanted to achieve with this year’s update, which we do every year. The goals were
More efficient input More markets using the tool
We didn’t have much time or budget for research so I ran a combined remote usability test and user interview at the same time. This lady was one of the participants.
One of the things that came out from the interviews was that actually the platform itself was easy and intuitive. No major problems with usability. There were lots of tweaks we could do obviously, there always are.
But fundamentally it was nicer to use than excel, and people enjoyed using it.
The main problem that they found was that they didn’t know what was required, so they couldn’t delegate the data collection. They just had to go through the tool to find what was next.
There was also no indication of timing required, so a lot of them missed their deadlines because it took them longer than they had planned.
So at the end of this, we discovered that the greatest impact we could make to achive those 2 goals was to create a welcome pack.
Not to improve the site itself, but a pack that describes who and where to get the data from, how long it is likely to take, so you can plan ahead, and the data that they will need.
We’re still working on this at the moment. Its quite a recent project, but this is very much the direction we are going this year.
The second example I’d like to highlight is with a trust at the NHS,
Some of the stakeholders were very clear that mobile is a top requirement for their staff, as a lot of the front-line staff spent time away from their desks, if they even have their own workstation to begin with.
So we asked users what their priorities were.
We presented users with a set of options and asked them to pick what they were interested in the most.
And look at that.. only one said mobile. All they wanted was to know that the information they need is available when the site down to do their paperwork.
And here again is the difference between those reasons to log on, and the more nice to have functionality. We suspect that once we have provided the right information at the right time, they might be more interested in mobile, but for now the priority is clear.
So that really shows the value of doing your research properly. It can be quick you don’t have to spend much time doing it, but you need to speak to your users and your stakeholders to get the overall picture.
This book, I carry around with me still. I call it my bible and it contains a cataloge of all the basic techniques involved in research, and what information they gather. I recommend you read it not to change career and become a UX grand master, or unicorn (as theyr’e called), but to get an understanding of what is involved and the value of upfront research.
So lets move on to the next step.
Gather all the project team and maybe a designer or developer,
Yes even these guys!,
in a room and run a workshop. Its important for all the key players to grapple with this stuff early on in the project so that everyone understands the issues. I’ve found that developers can the most excitable about new ideas, so why not get them involved early? Certainly for the first part.
So lets go through this top 3 and I’ll explain roughly how you do it.
The First step is to review the research and come up with as many solutions as you can to the problems that have been exposed.
All ideas are encouraged. There’s no bad idea. Note them all down on a post-it. Try to group them into general functional areas – such as user information, reference materials, paperwork etc..
Once you’ve done that, you can then prioritise these post-its.
Take another look at the business needs from the stakeholders and the user priorities. Sort all the ideas into must have, nice to have and future potential.
Be strict. You can’t have everything. If it doesn’t fit in the high priorities, its got to be nice to have. And even if you are strict, you’ll find the must have column tends to overflow a little. That’s ok at this stage. At least you will have focused all your ideas around the core high-priority solutions.
Finally, if you have any time left, its nice to end with some sketching.
…. This is a really good way of revealing everyone’s internal image of what they might be expecting. It is also a bit of fun at the end of a long afternoon.
So, the day after your successful workshop, everyone is happy with all the ideas and how they have been prioritiesd. But there are 2 more processes you need to go through to get your final list of features and functionality
The first is to look at what will engage specific user types
Yes more re-arranging post-its. But it is worth it.
You need to organize those must haves. Think about which functionality will attract which level of engaged user. The Skeptics, Conservatives, Pragmatists, Visionaries and Enthusiasts. What are the reasons to log on, return and lead?
Take a look through Dan’s presentation on slideshare again, or read through the e-book for some ideas. For now here is a checklist for now with some hints at how to organise all those must haves.
And if find you don’t have anything that will engage the enthusiasts, maybe dip into the nice-to-haves.
This will take some discussion amongst the team, but in the end you will have a clear idea of your priorities.
So. …after all that, you will need to re-visit your scope.
Take everything you’ve done and work out what should be done, how long it will take and therefore what can be done within the timescales and budget you have available.
Create a functionality brief for your design and build teams, ask them to place realistic timings behind each feature. And when they have any questions, you’ll have a lot of information to inform your answers.
The great thing about running through this process, is that you can always refer back to the original business needs, what the users need the most, and what we know will engage them the most.
…and at the end of this, you should have a complete realistic list of everything you want to achieve, ordered by priority. …so what do you do with this list?
Well, that brings us on to the final part of this presentation. The design phase.
But even now, we don’t jump straight into the visuals.
The first step is to figure out your site structure and navigation. The architecture of the site. Making things easy to use is one of the key reasons to log on, and will keep people coming back too.
The best way to do this is through card sorting.
Crowdsource your navigation.
Remember these guys? Now is the time for them to shine. You’ll be amazed at the differences in how people think.
Our favourite tool is OptimalSort, though there are others. Its not free, but going free or doing it yourself in excel is bit of a false economy because the analysis tools it offers save you so much time you easily make your money back! Learn from our mistakes here.
So. The process is….
List 20-50 pages, features or ideas – these are taken from that final list of features you have created. Try to keep the the same level of granularity. An obscure policy update is possibly to granular, whereas HR is to general. Try to keep themall somewhere in the middle.
Find 15-100 users.. There doesn’t need to be many, but the group should be representative of your organization.. Of different departments and seniority.
The first step is the open sort. Present your list of functionality and ask people to group them into 5-10 groups. Once they’ve done that, ask them to name the groups. 10-20 participants is enough, but if you have hundreds, even better! You’ll find lots of little gems in the group names that you will never have thought of, as we did with our own intranet. Your users don’t even need to understand all the names – in fact that provides it’s own insights.
The next step is to analyse the groups and try to find a set of 5-8 that:
use plain English, are mutually exclusive (as much as possible – there will be some overlap, but try to reduce this as much as possible) cover everything. (‘other’ and ‘General’ are the worst word in the dictionary)
Once you’ve settled on them, you can then run a closed card sort. For this sort, offer up the same set of functionality, but ask people to place them in your sparkly new set of groups. You’re looking for 70-100% matches in the most important functionality. If you find that most of your functionality has 50% or lower matches, it means people won’t agree on where to find things and you should re-look at those groupings. The closed sort is a really good way of testing that your initial sort has worked well.
So.. Once you have settled on your navigation you will have an idea of what pages will exist, and roughly what they should contain.
So.. Time for some nice visuals surely?
As I’m sure you all know, you shouldn’t start of designing the visuals.
Its best (and quickest) to work out your page structures first. Create some skeletons, or wireframes of your pages. Like this one we did. It doesn’t have to be flashy, just provide enough information to convey what should be on the page and what the key goals are for the pages.
And… although your stakeholders, project managers and pretty much everyone involved is most excited to see the homepage, I recommend you start from the inside out..
Start with the content. The end point.
Here is where users find what they’re looking for, so make sure it offers what they need.
Once you have nailed that, zoom out to the section page, or section homepage.
Make sure you provide an easy way to access all the content in that section.
Finally, after most of the site has been wireframed, you can bring it all together on the homepage. And by then, you will know all you need to know about the content you are directing people to.
Try to groups the homepage into the same structures you have grouped your navigation into. The homepage is your primary real-estate to educate people about the site and what it contains. Make sure it represents your site.
You can test all of them by putting them in front of people and asking them to describe what the page does, what various buttons and controls do, what they expect to happen next.
You can do this in a very lo-fi way by printing them on paper and showing them to people in the office, or you can plug them into some prototyping tool like axure that allows for more detailed interactions
This way you can get an idea of the journey users expect to go through. If you can match what you create to their expectations, they’ll find it so much easier to use.
And so.. Finally. Once the wireframes have been designed and tested, we can enlist the help of these guys.
Your priorities start to re-arrange and focus less on the functionality that you may previously have thought of as exciting. And more towards that content that may be considered dull, but is in fact essential to users jobs. Start with this,, and you will have an engaged site.