The ultimate intranet design journey for happy employees/customers

How user experience designers can navigate common hazards in intranet design

syfte
syfte blog
4 min readJun 22, 2017

--

When thinking of the steps involved, or how to kick-off the project, designing or redesigning an intranet is no different to any other project.

At its most basic, an intranet is a tool for storing and retrieving information. A tool for a specific type of task, it is used at work during the working week, on a working day. Armed with the information I need, I’ll get the job done then put the tool away.

Well, that’s one hypothesis.

Don’t be fooled into thinking we already know our users

It’s true we may have demographic data, but that doesn’t tell us anything of their experience at work. What do we really know of their needs or their habits, or their irritations?

Consider the working environment. Is it noisy or quiet? Is it well-lit or dark? Spacious and private, or congested? Are there physical impediments? How when and why do they access the intranet? How often do they go there and what do they use it for? Are they satisfied? Did they get the job done in a timely manner? Was the experience straightforward and simple — or is it laborious and convoluted? Ask if they can easily describe their steps to a colleague. Is it predictable? — how so?

Honestly, at this stage the only thing we know about our user, is where to find them.

Yes an intranet has a captive audience (so use it) and plenty of content. Perhaps it has a brand or corporate identity that is consistent with the strategic goals and organisational values, but does it have a content strategy? Establishing a unifying content model fit for a diverse, multi-departmental user-base, is one of our biggest challenges.

Talk to the Project Manager and get agreement on the definition of success

Pause for a moment. Review the context of the project within the organisational structure and understand the strategic goals and organisational values. Talk to the Project Manager and get agreement on the definition of success. Knowledge of these things helps keep priorities in focus. Make sure the content strategy is in place or at least in progress as this will impact the information architecture through every interaction and step of the user flow.

Plan your research. Capture your intentions and the reasons behind them in a short summary and timeline that you can share with your team. Conducting research and responding to it intelligently takes time, so working in a team with an awareness of your works’ critical contribution to the projects’ success is a strong place to start. Don’t assume they already know. Empathy and humility live here.

Get to know your audience, including stakeholders

A customer journey map will require an understanding of the users’ environment, their triggers and motivations. It can signal opportunities for doing things differently or simply streamlining what’s already there. Use this to communicate insights to the wider team, and refer to back to it often, throughout the design process.

Remember, stay focused on the purpose and be true to the research. Generate ideas through an idea sprint, from which you will storyboard or wireframe to visually address pain-points and suggested features. Review the ideas with your users and regularly present the feedback and test results to your whole team if possible.

Share your work openly

Intranet projects are especially vulnerable to hijacking by stakeholders and interested parties not directly involved in the research or the decision-making. Often well meaning, they can delay or even derail a project with features and change requests that are not researched or tested, and ultimately unnecessary. Sometimes distractions come from an impatient Project Manager who is weary of UX. Make your recommendations difficult to ignore by sharing them along with the rationale behind them, with the whole team.

Working on an agile project recently, I was surprised to learn that in isolation from the experience research I was doing, a lone Business Analyst was writing user stories for back-end development. More than a guide for scoping and quoting, these untested user stories were the blueprint for a database structure, which would impact much of the front-end design too. With distinct siloed teams, many UX and usability issues were created at this point, and were already ‘too expensive’ to fix by the time I learned of them.

User stories must articulate multi-viewpoint requirements, and therefore cannot be discrete and shouldn’t be written by a single author. Like any user insight, user stories need to be communicated and reviewed before development time is committed and must take into account the research that has gone before.

NN/g have a good article about how to include UX in agile user stories.

Sometimes it takes stakeholders time to see the value in good UX. An ROI (measured in happiness, time spent, productivity, engagement, personal development) is hard for some to quantify — especially given an assured and safe audience.

There’s always another way

It is disheartening when decisions are made that are blatantly bad for the user with whom we have built a rapport. But on observation, managers with decision-making authority, are not only amenable to bite-sized research reports, timelines and plans — they also love publicity and especially love winning awards.

There are many opportunities for businesses to compete and promote their product in a marketplace that values best-in-field business applications. Regardless of the incentive, demonstrable UX research and responsiveness is crucial to any submission and its success. Most importantly, it’s our customer who wins in the end.

If you’d like to know more about intranet design that will help your business, get in touch!

--

--