Why scalability isn’t always right
In 2004, Clay Shirky wrote a forward-thinking essay on what he called Situated Software; “software designed for a particular social situation or context”. He predicted that “the design center of a dozen users, so hard to serve in the past, may become normal practice… we’ll see a rise in these small-form applications”.
And he was right; the emergence of the smartphone, in particular, has given rise to a landscape in which whatever you need to do, there’s an app for that. But where we’re really seeing the value of small-form applications designed for their own specific social context is on intranets.
This month the winners of the 2011 Intranet Innovation Awards were announced. The UK’s Framestore firmly deserved their top billing Platinum award for their visual effects project management tool. It’s a custom-built workflow management tool, supporting the organisation’s core business by helping artists manage their visual effects projects. The in-house development team didn’t build the system itself – it’s a complex, third-party product – but rather they sought to, in their words, manage that complexity for their users and make it more closely meet their needs.
This is, to my mind, the holy grail of web projects; turning the difficult and complicated into a good user experience that precisely meets the needs of its user group. Each of the ten winners of the innovation awards managed precisely this feat, but in widely varying ways. Winning projects ranged from content which tells you it’s changed since you last looked to mobile sites which tell you when the next campus bus is due; each was designed with its own relatively small group of users in mind – not a generic set of users.
Like Shirky’s idea of situated software, this approach to intranet design does not embrace scale, generality or completeness as virtues; instead, the focus is on making a product which is designed for a specific group of people in a specific context performing a particular task or set of tasks.
And this is where so many intranet projects fall down. Analysts and managers fail to see the value in an application which benefits only a few hundred users performing a specific task. Instead, projects grow in scope until they’re attempting to meet the needs of myriad groups performing all manner of different tasks – and doing none of them well.
It’s argued that you need scale because web development is so expensive. Yet so much of that expense comes from the requirements of scale itself.
Design, development, testing and release becomes harder and more complex the larger a project is. If a project precisely meets the needs of 200 users, is it necessary to can it in favour of one which less precisely meets the needs of 2000? The former is cheaper and quicker to build, and will have a higher take-up by users.
This kind of thing doesn’t need to be personalised; it is personal to the group from its very inception. The bespoke nature of situated software – or intranet development – means it’s guaranteed not to work at the scale generic apps do, but for that same reason it can work in ways generic software can’t. Framestore’s animation workflow app isn’t going to scale – but it’s because it doesn’t scale that it meets the needs of its users so well.
The Framestore app, like almost all of the Intranet Innovation Award winners, was developed in-house. Designing for your own users and not generic users, development is grounded in the user community from the start. The result is form-fit tools which more precisely meet the needs of users.
It’s only by meeting user needs, delivering tools that work for your users, and for the way they work, in order to help them do their jobs better, that you can make your intranet work for your business.
what about a scalable intranet that can be tailored by the user, for the user? facebook is kind of built to some extent in this way; it provides a basic platform that everyone can use in the same way, but you can also build your own apps to work for you.
this is going to be our approach with our new sharepoint intranet. we’ll allow people to develop their own web parts and use certain areas as they require, but the bits we need standardised, and scalable e.g. knowledge areas, will be.
will report back to let you know how we do with this approach… we’re still in the planning phase right now!
Personally, I’m not convinced by personalised intranets, on the basis that only a tiny minority of users ever actually use such functionality.
Facebook is a good example – in theory, almost anyone can create and add apps. In reality, hardly anyone does this and the only apps with traction are Farmville et al.
At Interaction the other week, James Robertson noted that take-up for user-personalised functionality is typically 5-10%. Like macs or phones, people like them to *just work*; they don’t want to have to customise or create.
So to make an intranet deliver for your business, you have to make it meet user needs – understanding what your users need to do their jobs, and delivering that. So I’m interested to hear if you have any more luck with your personalised approach.
That’s precisely my point – we are making something that is tailored to the majority of users needs, but there is a minority who will want more.
If you think of facebook pages as an example – brands have built bits and pieces on top of their pages to make it do exactly what they want. This isn’t changing the fundamental platform, but is allowing for ‘added value’.
I love that if you create a page/group/event in facebook it all looks the same – this is what we’re aiming for too. It also has a positive effect on usability, as users know where things are.
What we don’t want to do however is limit it’s potential. All these ‘extras’ will come through a central team, who will offer support, and if it’s a useful development we could make it available to other departments too…