Adapted from Mark Gerow, Law Technology News
The law firm website may be the first place current and prospective clients go to learn about your firm’s services and attorneys. Therefore, the site must convey the expertise and values of your firm, not only through words and images, but also through the site’s design and function. As Marshall McLuhan famously wrote, “The Medium is the Message.” So make sure that your website’s design and implementation are both aesthetically and technically sound.
In this article I will share the story of my firm’s journey to upgrade its website from Microsoft Active Server Pages to SharePoint 2010, including key lessons learned along the way. Many of these lessons are general in nature, and will apply regardless of the platform you choose. Others are specific to SharePoint, and were the result of overcoming one or more limitations in that product. What follows is the tale, with its many twists and turns, of our months-long odyssey to design and build our new website.
The impetus to create a new website began, as it so often does, with our marketing department. At the outset, the specific platform to use was not a primary consideration, although the use of SharePoint was preferred if it would meet all performance and feature requirements, because we already used SharePoint for our intranet and extranet.
Under the leadership of our chief marketing officer, the Marketing and IT departments met to discuss the best way forward. We looked at websites (both legal and non-legal) that had elements we liked or disliked, and discussed the reasons why. We also drafted a top-ten list of candidate website development firms that could help us build the site, which we subsequently narrowed to five.
During the vendor interview process we saw several examples of well-designed SharePoint 2010 sites that convinced us that SharePoint could be a viable platform. Through this process we also became convinced that no single web design and development firm possessed both the creative and technical skills required. We therefore selected two firms: one to create the website design using their deep experience with law firms, and a second to implement that design in SharePoint.
Lesson 1: Separate website design and technical implementation into two related but distinct projects if you outsource. Doing so will make it easier to find best-in-class providers for both the design and implementation phases of your project.
By decoupling the design and implementation phases we could eliminate the need to compromise on the final result, before we began. This decision did not solve all our problems however, as you’ll soon discover.
YIN AND YANG OF WEBSITE DESIGN
Once the outside design and implementation firms were identified, and SharePoint was selected as the target platform, the design process began in earnest. During this time the role of the technologists, both inside and outside of the firm, was advisory; helping to validate the proposed web design, ensuring that it could be built and would perform well. Engagement by the technologists during this phase proved invaluable, as several inconsistencies were identified and corrected. It’s not surprising that, in their efforts to create an outstanding user experience, the web designers occasionally exceeded the bounds of software reality.
Lesson 2: The technical team should remain engaged throughout the design process, not to limit the creative process, but to help firmly ground it in the real world. This is particularly true if the target platform is SharePoint — a platform with which most web designers still have limited experience.
Lesson 3: Website designers should remain engaged at least through the build-out of wireframes to help interpret the design and answer the innumerable small questions that follow the initial page layout of the website.
This give and take between the design and technical teams, with the marketing department moderating the discussion, is not only necessary, but provides additional opportunities to refine the design. One example of the value of this process involved a search component that was to appear on almost every page. As designed the component was visually striking, but proved difficult to build and cumbersome to use. A few simplifications to the search design resulted in a component that was faster and simpler to operate.
I SAY ‘TOMATO’, YOU SAY ‘POTATO’
Because of resource and time constraints, we chose to partner with an outside SharePoint consulting firm for the implementation phase. The firm selected had outstanding credentials and was an internationally recognized expert in developing public websites using SharePoint. Prior to commencement of programming we spent many hours discussing how our in-house technical team would work with theirs; including our approach to project management (we both used the Agile SCRUM methodology), which stressed a “one-team” approach.
Despite laying this groundwork for collaboration, tensions arose almost immediately over control and scheduling the project. The SharePoint consultancy had a practice of taking full control of their projects, and found it difficult to share that control without “breaking” their development process. As is typical with many “boutique” technical consultancies, they contracted out some of the work assigned to them, which made coordination with some team members especially difficult. Finally, our technology partner was separated from us by a time zone difference that limited communication. The distance in terms of methodology, time, and geography turned out to be too great.
Lesson 4: Distance matters. Time, geographic, or methodology disparities impede the communication that is critical to technical project success.
The degree to which the above applies may be reduced if your firm plans to outsource development entirely. Even in such cases, however, if you plan to host the finished website in-house, don’t underestimate the amount of coordination between your IT department and the outside development firm that will be required.
We were fortunate to have the local development firm that had created and maintained our firm’s legacy ASP pages to fall back on. We had not selected them for the rewrite in the first place because they lacked SharePoint 2010 expertise. But given our long history of working successfully together, their eagerness to invest in building SharePoint skills, and their deep knowledge of legal website information architecture, we decided to take a chance.
While there were some early trials as their developers learned to work with SharePoint, the store of goodwill and past history of working together allowed us to navigate those challenges.
Lesson 5: Relationships and geography matter: While there is no substitute for technical competence, the willingness of an outside partner to work the way you want, when you want, is invaluable.
This local development firm has made significant progress in building their SharePoint expertise, and we now have a technology partner with whom both our marketing and IT departments are comfortable.
Thus far I have focused on the lessons we learned regarding the process aspects of our project. There were also many technical lessons to be learned. SharePoint 2010 is a complex platform, with rich content management capabilities; but there are also many quirks and dark corners that become evident when SharePoint is pushed to its limits that I will take up in part two of this story, next week. Stay tuned.
Mark Gerow is director of applications and business process at Fenwick & West.