Intranet Design and Governance
Over the last 3 months, one of the projects we’ve been working on at PebbleRoad is the revamp and redesign of a client organization’s intranet.
The organization has over 700 staff, most of them at the headquarters, but a significant number of them in their other locations spread all over Singapore.
The role of PebbleRoad was to conduct research, then redesign the structure and the layout (wireframes) for the new intranet based on the research. Another company would then use our design to do the actual implementation of the intranet.
We’re almost finished with our part. Although I can’t divulge too many details at this point, it’s been a fun and fulfilling ride so far.
As part of the research, we had to conduct many interviews with different staff, to understand their work habits, their informational needs, and so on. As of now, we’ve interviewed close to 10% of all staff.
Personally, those interviews weren’t just to find out what problems needed to be solved or even to understand the users – what was more important was that those interviews gave me an opportunity to have personal contact with those who will be using the intranet that I’m redesigning, to actually care about them. I’m not redesigning the intranet for some faceless silhouetted entity called the user; I’m doing it to help make the lives of these nice people a better.
Which makes the work alot more meaningful. It makes me want to do a better job.
But creating a wonderfully-designed intranet is only the start. What is equally important is how the intranet is cultivated, so that the benefits of the intranet can be maintained or increased, in symbiosis with the organization itself.
To help with that, we produced an intranet governance guide:
This guide describes a set of processes that need to be in place and a set of actions that need to be taken to sustain and grow the intranet. Without these guides and checks, we risk diluting the very efficiencies and productivity gains that the intranet is designed to provide.
My colleague and I had much discussion over this guide. I hope it’ll be useful for others who are maintaining intranets, or are planning to do so.
Which Comes First: Design or Research?
Since I’m into design (I’m a Design Consultant after all), I was pretty interested in PingMag’s interview with Ken Okuyama. While he’s mostly into product design (he’s behind the lovely design of the Enzo Ferrari), and I’m more into information and experience design, there’s always something I can learn from other design fields.
What stood out to me the most was how he typically starts his design process:
I put everything in my brain down on paper, stick all of it on the wall and judge objectively the best possible solution for the problem. Then I start the research after. Not before. Once you know, you cannot go back to “your ignorant yourself.” But the ignorant yourself is the best creative partner you have.
Where I work at PebbleRoad, we normally do it the other way round – keep an open mind and do the research first to find and understand the problem, before embarking on the design.
Humanized described our design philosophy very nicely in a recent post on interative:
Coming up with a solution is often the most straightforward part of the design process. That isn’t to say that creating the solution is easy, or doesn’t require a deep knowledge and honed skill set. It’s just to say that when you have a set of requirements and a well defined problem, you know where you stand and where you have to get to. It’s mostly straightforward. Much harder is the implicit problem of figuring out exactly what the problem is in the first place. If the problem is vague or ill-defined, the design solution will be too.
So far this has worked well for us, and it makes sense too, since we don’t really want to design something for the wrong problem.
But Okuyama has a valid point about “your ignorant yourself” being the “best creative partner”. Is that the key to the really groundbreaking and mind-blowing designs?
Something to think about, and something I’ll definitely try out in my next project. But that would never work if we forget his qualifying statement, which I deliberately left out from the quote above:
You also need the courage to adjust your original idea once it’s proven to fail.
μεταcole 
1 comment