My team, in conjunction with partners across Microsoft, shipped a new Office Developer Center experience at http://dev.office.com this morning.
I’m incredibly proud of the work we all did. This was a hugely complex project that saw us combine six different developer centers into one, consolidate a little over 200 pages down to 24, re-write every single page, and simultaneously reset the global experience across 11 languages.
This was arguably the most challenging project I’ve worked on here at Microsoft and presented the thorniest information architecture problem I’ve ever encountered.
The Office family of products spans multiple products with their own hierarchies of brands and tasks for developers. At the top level, there is Office, SharePoint, Exchange, and Lync. Within Office alone there is Access, Excel, InfoPath, OneNote, Outlook, PowerPoint, Project, Publisher, Visio, and Word. Microsoft is also asking developers to write apps for Office and for SharePoint, and the development details are a bit different between Office and SharePoint. Add in Office 365 service content, and you have many different pivots you could apply.
Then we had to consider that we’re always balancing between the past, present, and future when we’re talking about development. There is a huge audience of developers who have written code to older versions of Office, a smaller set that’s targeting the current version, and then Microsoft is trying to guide developers to be set up for the future evolution of the platform.
The challenge here boiled down to: what information architecture would expose the breadth and depth of the product offerings, feature current and future development options, and not alienate developers targeting previous versions?
We had many, long discussions around the right pivots here, and in the end we decided to stick with the top-level product names as the main pivots for the navigation, and placed app development messaging on pages where it was product-relevant.
How’d we do?