Why do we model?

It has been a week since I published my Visio template for designing SharePoint sites for everyone to use freely. Judging on the many positive referrals to the article, the many Google search queries for ‘visio + template + sharepoint’ and the massive increase of traffic to my weblog, people seem to appreciate this design aid. And I’m glad for that.

But of course there are enough SharePoint architects who don’t have the need for modeling tools (or at least mine), and that’s fine. But today I stumbled upon an article by Lois & Clark called “Should we model?”, questioning the need for modeling SharePoint sites in detail.

They base their opinion on three arguments:

  • It would take the same amount of time to communicate which webparts a SharePoint site contains, by creating a real SharePoint site as it would take to design it on paper.
  • SharePoint designs are short-lived, since site administrators and content managers are free to manage the contents and structure of their site.
  • The level of detail is too high to use as interactive sketches. Clients are reluctant to suggest changes because the design looks official and definitive.

Sounds like enough reason for them not to model SharePoint sites. So why do we?

The average SharePoint portal or site Tam Tam implements, involves more than just creating pages by adding and customizing standard components. For example, if you have to design an employee directory for an organization with more than a thousand employees, over different locations or even countries, you need more than a simple list. You need decent search options and a browseable interface; thus a custom component. And like this, we design various tailor-made solutions for specific situations, using both custom and standard components.

You want to design a component like thisEspecially those custom solutions you really want to design, for the client but also for the development team. No offense, but most developers come up with very different solutions than interaction designers. We have tried to just describe the interface and functions, but it’s a common fact that the people of today don’t read very well. So the designer, the developer and the client all have their own conception about the application. Result: disappointment all around. We use prototypes to visualize solutions, to check with the client if the solution will solve the problem, and also to check with the developers if it’s feasible and efficient.

Naturally we don’t design every ‘standard’ SharePoint page. Of course we don’t assume that the layout of the average page will remain to match the original design after deployment. And yes, we also use the old pen and paper to sketch the first impressions. But if we create a detailed design of a SharePoint based application, we use convenient Visio templates to be able to concentrate on the custom solutions, rather than waste our time on the basics. And by sharing those basics, you could too. (But that is up to you ;-))