Prototyping

Intuitiveness and making a better intranet

The UX, hard work, and the fast feedback that can help design a better intranet.

In this guest article, Rob McWhirter delves into UX, hard work, and the fast feedback that can help design a better intranet.


A typical conversation about an Apple product:

“I find the Mac much more intuitive.”

“Why’s that?”

“It just is.”

I’m sure that you’ve heard something like this before. Whilst ‘intuitive’ digital design is something that we experience every day, it’s very difficult to define what makes a design intuitive or why it is easier to use than another.

Jared Spool, in a good post, points out that the phrase itself doesn’t really make any sense:

“When someone is asking for an intuitive interface, what they are really asking for is an interface that they, themselves, can intuit easily.”

It’s a confusing concept, one that is difficult to explain or reverse engineer, but one that is doubtlessly important – especially for digital internal communications. In fact, communication tools like Slack have attributed the user experience to their success.

There’s no doubt that some products are somehow more intuitive than others, and that this is important, but how can it be achieved?

 

Hard graft

Making a design truly intuitive is a long and fairly unglamourous process. It involves hard work and being prepared to stop being precious about your design: being ready to tweak it, or even scrap it altogether.

It comes from developing your product alongside users and not being afraid to change it based on their feedback. Here are a few practices that we stick to when designing our product, Twine.

 

Solve problems

When designing a new product like an intranet, it’s easy to begin with thinking what features you need.

You (or more likely your stakeholders) might find yourself saying: “We need documents, chat, messaging, a link to the newsletter, a 3D interactive map of the office, and, oh whilst we’re at it, we need an app!”

As more and more stakeholders chip in, your product quickly becomes bloated with features that solve internal political problems rather than the actual problem that it set out to achieve.

By systematically setting out the problems that you need to solve before deciding on tools you are going to use to solve them, leaves you with a better product and budget better spent.

As Brad Frost puts it:

“You don’t walk into a hardware store, notice a good-looking shovel, then say ‘Boy this sure looks like a mighty fine-looking shovel. I’m gonna head home and start finding stuff to dig up with this here shovel.’

“You’ll end up going home and making a huge arbitrary mess out of your backyard.”

 

Design and build quickly

The best way to understand whether a product meets people’s (and business) needs is to build it.

Prototyping has become is an essential part of the process. It begins with hand-drawn sketches and will quickly get to a point where we have something working (to some extent) in the web browser.

Getting into the web browser (rather than spending lots of time on Photoshop etc.) means that time spent making the prototype is time well invested, since the work is, in some form or another, used the final product. There’s a more detailed explanation of this rapid prototyping process in a post on our Browser Blog.

Working like this gives us a much better chance of hitting that ‘intuitive’ feeling that we’re after, since budget is used more efficiently and more time can be put into getting the details right and testing.

 

Test early

When it comes to fast, cheap user testing, carrying out informal interviews (guerilla testing) early on works really well. Using prototypes means that we can test ideas out and be a bit more adventurous with them, knowing that the design can be changed easily.

Often it’s the micro elements of a design that require attention: many of the usability issues raised within the testing stages drum down to bad terminology, inefficient signposting and the appropriate hierarchy of content. Making tweaks to this can make all the difference.

Throughout development of new features we interview users. We regularly test and revise micro elements, such as colour tone and terminology, based on the feedback.

 

What you can do

This recipe of focus, speed and feedback can produce beautiful results. From working like this first hand, I can say that it can go a long way to achieve that intuitive feel that is so essential to online tools like intranets and collaboration tools.

So, next time you find someone saying that a product is intuitive, have a think about why this might be and what decisions have been made to achieve this. You’ll probably find that it’s been produced using the above principles in one way or another.


Rob McWhirterRob works at collaboration platform makers, Twine. He helps the team to make better informed design decisions. He also likes hiking and golden retrievers.

He’d love to hear your thoughts over at @tweetsbytwine

1 comment
Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Previous Article
Intranet Now 2014 crowd

Call for speakers - intranet, digital business, internal communications

Next Article

Twenty words, not too many polysyllables

Related Posts
Close up of a rose
Read more

What’s in a domain?

Internet or intranet - the address people use to access your site conveys valuable brand and purpose information.
Read more

Why does your intranet exist?

A brief reminder about remembering the purpose of your intranet, and checking the relevancy of front page articles.
Dashboard
Read more

Dashboards as intranets – alternative designs (review)

Personal dashboards, that show real-time data and one's tasks, are probably the next necessary step for intranets, but these three layouts conceived by web designers are missing the rest of the intranet.