COLUMN. User-centred redesign of the FaCS intranet. A user-centred approach throughout the project ensures fewer surprises at the end

Transcription

1 KM COLUMN CASE STUDY (JUNE 2004) User-centred redesign of the FaCS intranet The Department of Family and Community Services (FaCS) engaged Step Two Designs to assist in the redesign of their corporate intranet. This included undertaking research into staff information needs and assisting with the redesign of the site structure and page layouts. Step Two Designs worked with the FaCS intranet team throughout the process and many of the activities were conducted as a team. This approach ensured that the intranet team has ownership of the outcomes and it also utilised the full set of skills held by the combined team: our skills in intranets, information architecture and usability, complemented by the intranet team s knowledge of the department and the current intranet. Although the new intranet has not yet been released (content is currently being rewritten and migrated) the project to date has been very successful. Staff have responded positively to the new intranet, commenting in usability tests that it is much more logical, looks really good, and that new sections such as news will be useful. Following a user-centred design process proved invaluable. Conducting extensive user research at the beginning of the project, and then involving staff in design and testing activities throughout the process ensured that by the final stages there were no major surprises. In many ways, this was a textbook application of user-centred techniques to the redevelopment of a large Government intranet, and it serves as a useful model for other organisations looking to tackle the same issues. Donna Maurer is a senior member of the Step Two Designs consulting team, and a leading specialist in usability and information architecture techniques. Donna has worked extensively in the Australian public sector, with a particular focus on intranet redesigns. A user-centred approach throughout the project ensures fewer surprises at the end This case study focuses on the processes followed for the project, and highlights key issues and insights. Additional work was also conducted by the intranet team (such as obtaining stakeholder support, working with authors and migrating content) which is not covered in this case study. As such, this article documents only the usability and information architecture activities conducted as part of the broader intranet project. Overview of the project The project involved four phases: conducting user research determining intranet scope and goals developing and usability testing the information architecture (site structure) designing and usability testing navigation and page layouts Each of these activities is described in this case study, along with outcomes and key issues and insights. Conducting user research The project started with an extensive round of user research to identify staff information needs. Process The key user research activities were focus groups and individual stakeholder interviews. These were conducted face-to-face in FaCS National Office (in Canberra) and in two State offices, and by telephone for other interstate offices. Stakeholder interviews took up to an hour each, focus groups up to two hours each. knowledge management content management intranets usability information architecture

2 The research involved a total of 77 staff, across a variety of teams in the organisation at all levels, including senior management. Initial planning identified a number of key issues, rather than a set of scripted questions, allowing exploration of issues as they arose. To avoid biasing the discussions towards the role and performance of the existing intranet, the research was focused on the general role of information to support core business activities. Staff using assistive technologies (such as voice recognition software) were also involved in the stakeholder interviews and focus groups. A more detailed understanding of issues facing this user group was explored by asking staff to demonstrate how they currently access the existing intranet and other information systems. Staff relied on a number of sources for news Outcomes By exploring the role of information, rather than just discussing the intranet, we learned a lot about staff experiences. Some of the key findings included: Staff were interested in what happens throughout the department, and relied on a number of sources, including , staff newsletters and face-to-face communications (but not via the intranet). In many cases, staff had a greater need to find a specific person to talk to, rather than a source of online information (personal communications are often more efficient and effective than intranet content). Staff were often confused about which information system would contain the information they needed. Despite confusion over sources of information, staff had consistent ideas about what the intranet should be for. Many described it as the main store of official department information, containing final versions of information. The intranet was also seen as a place to find out who s who in the department. Information was difficult to find, and much of it was out of date, resulting in low usage and a lack of trust in the intranet. The publishing process for other information systems (such as online bulletin boards) was simpler and faster, and staff preferred to publish to these systems rather than the intranet. Issues and insights The twofold approach to interviews (one-onone and focus groups) provided better information than using one technique alone. Individual stakeholder interviews in the workplace were valuable for collecting concrete information about staff roles and how information supports staff to do their core business. Focus groups were valuable for generating ideas about the role an intranet may play in supporting information needs into the future. Focus groups, by their nature, also highlighted cultural issues that didn t arise during individual discussions. Focus groups identified future needs and cultural issues Face-to-face interviews were valuable for exploring issues deeply and seeing in context they way staff work, while telephone interviews allowed remote staff to be included. Within a short time frame, key issues emerged and were consistently repeated. Although the seventy-seven staff involved covered only a small percentage of total staff, issues and experiences were reasonably consistent. By the final interviews, no new issues were surfacing, providing confidence that the key issues had been discovered within a sensible time frame and budget. The intranet team were not surprised by the outcomes of the user research. Instead, the research confirmed many of their assumptions about the current intranet. Undertaking the research, however, gave concrete information on which to base design activities. Determining intranet scope and goals Process Before launching into the design process, the intranet team examined what had been learned from the research and determined User-centred redesign of the FaCS intranet Page 2

3 how the intranet should support business and staff information needs. This resulted in a defined intranet scope, high-level goals and metrics, which were discussed with key stakeholders before progressing. Outcomes The main goal for the intranet was to be the core repository for corporate information of interest to a wide group of staff, and the single trusted source of that information. Other goals included: information is accessible for staff using assistive technologies information is easy to find information is accurate and current to be a communication tool used by all staff on a daily basis to be a tool for all staff across the department and reduce the Canberracentric perception of the intranet Intranet goals are essential during the design process Issues and insights Setting goals and scope is a very important step in any design process. Doing so ensures that the strategy and high level directions have been considered, and that the place of the intranet is defined in relation to other systems. Goals are particularly essential when discussing features or content, where only those aspects that contribute to the goals should be included. It is also important to revisit goals regularly, particularly when other organisational changes offer opportunities for improvements to the overall staff experience. Developing the information architecture The information architecture (site structure) is a key aspect to any intranet project and should be completed well before page layouts or visual designs are started. Process The design process for the information architecture continued the user-centred approach, involving staff throughout each activity. The key elements included: content inventory card sorting designing a draft information architecture usability testing a paper prototype Each of these is described in the following sections: The content inventory provides additional clues about needs Content inventory A content inventory is a detailed listing of all pages on the intranet. This was used to: gain a comprehensive understanding of what was included on the existing intranet identify content owners identify content that is outdated or no longer needed It was also used to place content in the information architecture, and will be invaluable when migrating and rewriting content. With the new intranet being created from scratch, it may seem unnecessary to undertake an inventory of existing content. This content, however, can supply additional clues about information needs, supporting or adding to user research. For example, content that doesn t appear to meet information needs may indicate a gap in the user research, while content duplicated throughout the site may indicate highly useful information that is difficult to find. The intranet team completed the majority of the content inventory by generating a list of pages from the content management system. The remainder was generated manually using the approach outlined in the article Doing a Content Inventory which can be obtained from: archives/ php. Card sorting Card sorting is used to gain insight into the way that staff think about groups of information and how they describe them. User-centred redesign of the FaCS intranet Page 3

4 We followed the process outlined in Card sorting: a definitive guide available from: card_sorting_a_definitive_guide.php This involves labelling index cards with content that will be published to the intranet, and asking participants to group the information in ways that make sense to them. The card sorting exercise used two methods: individual and group sorts. Bundles of cards (plus instructions) were sent to interstate participants and facilitated group sessions were held in Canberra. By using these two methods, staff throughout the Department could be involved, with rich data obtained from group sessions and a large volume of data gathered from individual card sorting. The most challenging part of a card sort for a large intranet is determining what content to include. The cards need to represent the final content, include enough overlap to allow groups to be created while not providing too many cards for the participants to sort. The content included in the card sort focused on areas where staff input would be most useful, and excluded content with obvious or inherent structures (such as the who s who information that would be best structured according to the organisation chart). Although the outcomes from the card sorts were entered into a spreadsheet, the primary analysis involved examining how staff had grouped content at the broadest level, as well as the labels they used to describe their groupings. The outcomes from individual and group sorts were similar. The IA was not the result of one activity, but from insights from many activities Draft information architecture Ideas and insights from a range of sources (including user research, intranet goals, organisational strategies, existing content and the card sort) combined to create the first draft of the information architecture (IA) for the intranet. The initial IA was drafted after a team discussion about the outcomes from the various activities. This was then refined by ensuring that all major information needs were covered, and that content had a logical place in the structure. The resulting draft information architecture consisted of a hierarchy containing three to four levels of navigation. It was an exploratory draft only, with some uncertainty around some of the groups and labels, to be clarified by the usability tests. The information architecture was usability tested Usability test of the draft IA To determine whether the information architecture allowed staff to find information easily a usability test of the draft IA was done. This also helped to further explore the groupings and labels. We used the Card-based classification evaluation method as described in the article: cardbased_classification_evaluation.php This involves writing the information architecture onto a set of index cards and preparing a group of scenarios on another set of cards. Staff were then asked to identify where they would first look for information described in each scenario. The usability test involved 24 staff who each spent minutes with the scenarios. Two teams ran the test at the same time. Each team tested a different version of the information architecture. For example, one team had top level headings like administration and what s new, while the other team had the headings business administration, personal administration and news & events. This allowed teams to explore the difference between the groupings and labels to see which allowed staff to find information more easily. Being a paper-based technique, it is easy to change, and we used this to our advantage during the test. For example, after testing with eight participants it was clear that there was a section of the IA that staff did not understand. We re-wrote the relevant cards and continued testing with a modified version that proved to be more intuitive. The results from the first test showed that many of the groupings were generally intui- User-centred redesign of the FaCS intranet Page 4

5 FaCS Intranet - Information Architecture About FaCS FaCS programs What s on Administration Research Technology Emergency Our people Programs, strategies & services Business administration Staff administration Organisation chart Our values & ethics Stronger families A-Z of programs News Business planning Certified agreement Library services Passwords Bomb threat Executive Our relationships Stronger communities A-Z of payments Calendar of events Communicati ng Learning & development Statistics System access Fire Branches & STOs Communities & networks How we work Our locations Economic & social participation Program administration Job vacancies Getting to the FaCS Legal Finance OHS Orientation Research papers Internet links System manuals Help for... Bulding evacuation First aid Committees & meetings Corporate documents Newsletters Project management Pay & conditions Legislation Telephones Emergency contacts Minister Corporate policies Projects Property Performance management Teleconferenc ing Our social activities Purchasing Personal safety IT security Risk management Recruitment Helpdesks Security Workplace diversity IT assets Travel Workplace harrasment Final information architecture presented as a site map tive, but there were labels that were misleading and confusing. For some scenarios, participants were unsure which groups would contain their information. The IA was again revised and the test was repeated a week later. In the second round of testing, participants were more confident in their selection of groups and the results were much more consistent. Outcomes The key outcome from these activities was an information architecture for the intranet that was intuitive for staff. The information architecture described the top 3 4 levels of the intranet. It did not include the location of all content, but sections : Small, natural groupings of information, often created by one team. Examples include travel, OH&S, committees & meetings, and system access. Each of these sections will then have its own small IA to allow staff easy access to the content within that section. While the process was aimed at designing the core information architecture (the hierarchy through which staff would navigate to content), the process provided information about areas where cross linking would be needed, or where staff would approach a task from a number of starting points. For example, it was clear that each team in the who s who section would need a link to the intranet content owned by that team. The resulting information architecture was documented in two ways. A site map visually showed the relationship between sections and groups, while the detailed information architecture document provided details, including: intent of each section type of information that should be included most relevant related links metadata required for some sections A list of alternative entry points (such as how do I? pages, A-Z indexes, quick links, top 10 lists) was also included. Issues and insights The key point arising from these activities was that the design of the information architecture is not a direct outcome from any one activity, but rather a merging of the insights gained from many parts of the project. For example: User research indicated a staff need to find out about the functions of the various teams, so one section of the site was devoted to providing this information. User-centred redesign of the FaCS intranet Page 5

6 The analysis of content had revealed a gap in core business information, and one section of the site was devoted to this. User research indicated that staff were interested in knowing what was happening in the department, suggesting the inclusion of a better news section on the intranet. The card sorting activity provided insights into grouping and labelling of much of the remaining information. Existing content provided a check that the information architecture covered content well. During the card sorting and usability testing we discovered that staff were still searching along organisational lines (despite reporting previously that they found it difficult to find information in this way, primarily because they didn t know who was responsible for a given piece of information). This highlighted the importance of providing alternative access methods to information. Homepages from other intranets were examined weaknesses. A list of features to include on the home page was then brainstormed, referring back to our intranet goals. We discussed each idea & grouped similar ideas into zones that could be included on the home page, prioritising the zones to balance the limited space available on the home page. It can be difficult to create the first design from a list of features. A strawman home page, main navigation and content page was sketched on a whiteboard the intent being to pull it apart and progress our ideas. The strawman home page looked like: Provide alternative methods to access information Designing navigation and page layouts With a solid, usability tested information architecture, the next step was to design the navigation (the way staff would move around the intranet) and page layouts (the location of elements on pages). Process We used a team, workshop-based approach to design the navigation and page layouts. This included not only the intranet team but the chosen visual designer as well. This approach avoided handing wireframes to the visual designer to paint by numbers and had the added benefit of gaining additional professional expertise in the design process. Page layouts Starting with the design of the home page, we examined printouts of home pages from other intranets, discussing strengths and The strawman served its purpose, providing a framework in which to discuss what worked and didn t work. Many aspects were quickly agreed upon, including a large zone for news, and search in the top right corner. Smaller zones were included for recent updates and job vacancies, as well as quick links to popular content or systems. It was clear from the strawman that the navigation would be challenging, as the usability test of the information architecture had shown that although staff would usually understand which group the desired information would be included in, this would not always be the case. We sketched a number of alternatives for navigation on the home page and discussed how they would relate to overall intranet navigation. This was complex but by the end of the day, we had a home page that the team all liked, that included priority content, User-centred redesign of the FaCS intranet Page 6

7 would meet the intranet goals and would suit the information architecture: Quick links Vacancies Last updated News The intranet navigation was refined further over the next few days, creating alternate versions of the home page, navigation and content pages. This provided the intranet team with a number of options to choose from. After the final set of wireframes was selected and documented, the visual designer worked on the graphic design while the intranet team created a prototype of the intranet for usability testing. The prototype created was both broad and deep Prototype A prototype was developed to ensure that the intranet page layouts would work with the content management system and to provide the basis for the usability tests. The prototype was both broad and deep: every page for the top few levels was created, along with selected sections of the intranet. Usability and accessibility test The main goals of the usability test were to check that staff could easily navigate around the site and recognise key elements of the pages. It was less important to explore whether staff could find information within the IA, as this had been covered during the earlier activities. As the intranet will be used regularly by staff, they will eventually become familiar with the intranet structure. For this reason, we wanted to avoid testing only initial learnability of the site. To simulate modest familiarity with the intranet, some participants Search Personalised content for the usability test attended a demonstration of the new intranet. Five participants worked through seven scenarios involving looking for information on the intranet. Participants were informed that the prototype wasn t complete and that there were links that wouldn t work. Staff using assistive technologies also explored the intranet, checking that they could select links and move between pages. The usability test showed few issues, as can be expected from a user centred design process The outcomes from the first test were very positive. Participants were able to easily navigate between the homepage and content pages and to use the navigation within the sections. They located the search box (although it wasn t implemented in the prototype), as well as related links and other major screen elements. At the end of this test, there were only a few changes to make to the layout of some pages, and information architecture of specific sections (these had not been tested in the information architecture test). This is the expected outcome of a user centred design process there shouldn t be major surprises at this stage. In the second round of testing (with five new participants and the same scenarios), participants breezed through the test. In some cases participants thought that they had to do something else: they couldn t believe that it was so easy. In both tests, and in the demonstrations done by the team, staff commented (without prompting) about how much they liked the new look of the intranet, how it was much more logical and more professional. Outcomes The main outcome from this part of the process were usable page layouts and navigation, proven through the creation of a prototype and usability testing with staff. The delivered page layouts were in the form of wireframes (layouts showing key page elements, but without the graphical elements), accompanied by annotations and descriptions to ensure the reasons for placement on User-centred redesign of the FaCS intranet Page 7

8 pages were captured. The wireframes were followed up with completed graphic design by the visual designer. Issues and insights One of the key challenges in this part of the process was to design the navigation for the intranet. On an intranet, staff spend much of their time within individual sections of the site, finding information to complete specific tasks (e.g. booking travel). As each section could include a significant amount of information, there needed to be a strong navigation model that would be suitable across the intranet. It was also important that the home page, global navigation and section navigation worked well together. Creating navigation that allows all of this is not an easy task. Creating the page layouts as a team in a workshop situation proved to be very effective. Although it was challenging work, the ability to spend a concentrated day working on the page layouts allowed us to reach a good design in a short time frame. It was certainly much more effective than one person creating a design and everyone commenting via (or other form of collaboration). The use of a strawman design in the process also worked well, providing something concrete as a starting point for further discussion. The prototyping step was very valuable. During this process the team further explored how to set the site up using the content management system and how it could help them to maintain the site efficiently. Before the usability test, the intranet team demonstrated the prototype to some participants to simulate a situation where staff have some familiarity with the intranet. Although this worked to some extent, it may have been more effective to give participants access to the prototype or time to explore more freely. Next steps The redesigned intranet has not yet been launched, as the authors are currently rewriting much of their content in preparation for go live. The intranet team is also planning prelaunch demonstrations and preparing additional help materials for the launch. This recognises that it will take some time before staff become familiar with the redesigned intranet and can find information quickly. Conclusion Following a solid user-centred design process which involved substantial user research and staff involvement has resulted in an intranet that is both intuitive for staff and provides benefits to the organisation. User research provided a concrete list of staff information needs and a good understanding of the context in which staff work. An information architecture that allows staff to find information more easily was designed with the input of user research, card sorting and usability testing. Navigation and page layouts were designed, prototyped and again tested with staff to ensure they were intuitive and usable. By following this user-centred methodology, FaCS has been able to deliver a greatly improved intranet, with the confidence that it can be used by staff throughout the organisation. More articles! Find out when new papers are published: Did you like this article? Send your thoughts and feedback to: contact@steptwo.com.au Step Two DESIGNS contact@steptwo.com.au knowledge management content management intranets User-centred redesign of the FaCS intranet Page 8

9 TM The Intranet Roadmap provides the first truly comphrehensive methodology that describes all the activities required to develop (or redevelop) an intranet. Beyond just implementing software or redesigning the site, the Intranet Roadmap covers activities in five key streams: strategy design content change & communications technology The Intranet Roadmap does more than just indicate what activities need to be conducted, it clearly shows the sequence of activities required, and the techniques that will help at every stage of the project. The Intranet Roadmap is delivered in two forms: full colour A1 wallchart supporting 54 page booklet The wallchart lists the key activities required in each of the project streams. It also highlights which activities (such as usability testing, affinity diagramming, personas and collaborative design) can be used to support individual activities. Usability testing Training needs analysis Train small groups Task analysis Develop authoring guide Train authors Focus groups Staff interviews Design patterns The supporting booklet then provides an overview of every activity and technique listed on the Intranet Roadmap, as well as linking to further resources and information. The combination of the wallchart and booklet will be invaluable for any team looking to develop or redevelop an intranet, and it will assist in both planning and reviewing the approach taken. Personas Accessibility testing Write and acquire content us$120 + $15p& p Secure online ordering: Step Two DESIGNS