By Andrea Alliston, Partner, Knowledge Management, and Nicola Shaver, Director of Knowledge Management, Stikeman Elliott LLP
In part 1 of this series, the authors discussed how to decide whether to pursue a major project and convince leadership of its value. Ed.
With decision making and project approval behind you, the next step is to start work on the design and detailed requirements. In our enterprise search project, the research from the decision-making stage made it clear that we had much work to do to improve our user experience. As a result, the theme we wanted to capture in our design and requirements was a relentless commitment to user experience. The underlying theme for your projects may be different. The point is to understand your theme and focus on it throughout the project.
Design for Success
The design phase of a software development project can be defined in many ways. In KM projects, design usually is about matching your users’ needs with the applicable technology’s functionality (and constraints). Our strategy of putting the user experience first required us to engage a UX expert to help us to create user journeys, identify desired outcomes within the limits of our technology platform, and make tough decisions about our KM content and its management. Do not underestimate the value of specialized expertise at this point in a project.
In addition to seeking expert advice, now is the time to engage your users and have them get their hands dirty. We used two techniques with our users.
- We held card sorting workshops for lawyers to determine the system’s structure from a content perspective.
- We convened focus groups to gather feedback on our wireframes and proposed functionality.
A set of design principles that set the tone of the project should come from the design exercise, along with the details needed to prepare the requirements. As one designer notes, “Design principles articulate the fundamental goals that all decisions can be measured against and thereby keep the pieces of a project moving toward an integrated whole.” Your design principles should reflect your particular project; ours were the following.
- Keep the interface simple and intuitive
- Restrict filters to a maximum of 7, plus or minus 2, per page
- Avoid customization where possible
- Allow for flexibility in accessing content
- Provide a bilingual interface
- Include all filters as part of the search snippet
Business and Functional Requirements
Projects are more successful when a clear set of business and functional requirements are documented; they ensure that the business stakeholders, the internal technology team and the vendor are on the same page. Where do you start?
Some of you will be fortunate enough to have a business analyst in your firm. Indeed, engaging business analysts in law firms either on a contract or permanent basis seems to be on the rise. But, what if you are not so lucky? Not having a business analyst role, we used the KM/UX consultant we were working with and our internal KM resources to create the needed documentation.
Our business requirements were comprised of annotated wireframes, descriptive narrative, and spreadsheets (see screen shot from one of the pages). However, depending on your project, you will also need detailed functional technology requirements for the developers. Once a draft is ready, the requirements should be circulated and reviewed in detail with both your technology team and vendor.
Lessons Learned
Stick to the design principles: We needed to simplify various aspects of our search implementation to be responsive to user feedback. Our mantra became “less is more.” While it sounds easy, it was very difficult to give up certain content management practices we had used for years. We constantly second guessed ourselves and worried about making a mistake, getting it wrong, and losing what we once had. We needed to be quite disciplined with this part of the project and, so far so good. No one misses anything we took away and the benefits of sticking with our design principles are paying off.
Discuss with the vendor: Once we had a sense of our desired design, we had early discussions with the vendor to explore options for some key functionality and get the vendor’s input on design elements we were considering. The goal was to tap into the vendor’s expertise and address any potential issues early on in the project.
Get into the details: Our business and functional requirements were developed when we had time to be thoughtful about what we were trying to achieve. Being able to go back to those requirements when we were later under pressure gave us confidence about our decisions and the right path forward.
Coming up in part 3: In our next post, we look at project planning as a critical step in putting your design and requirements into action.
ILTA KM 
One Response to “How to Survive Complex Projects, Part 2: Commitment to the User Experience”