HSRG 1.pngHSRG 2.pngThe Human Security Report Project (HSRP) is an independent research centre affiliated with Simon Fraser University’s School for International Studies in Vancouver, Canada. The HSRP’s mission is to provide the research, data, and analysis that are necessary for evidence-based policy-making in the areas of conflict prevention, peacemaking, and peacebuilding.
The Afghanistan Conflict Monitor and Pakistan Conflict Monitor websites were designed to provide concise and current information on peace and security issues on countries in crisis. The Monitors connect Government/International Organizations, Researchers, Media and Humanitarian Organizations with high quality research and analysis. Pairing the latest news with related research, the Monitors provide daily briefings on emerging issues and immediate access to the best available data and analysis on conflict-related issues in Afghanistan and Pakistan.
Originally these sites were created using the TypePad blogging service. TypePad is a fine service and functions quite well as a blog. Trying to create a fully functioning website using TypePad, however, can be problematic. The HSRP asked iomer to improve the site on several key points:
- Enhancing the navigability of the site,
- Allowing for more extensive data to be presented
- Including interactive statistics, maps and charts
- Simplifying integration with the Conflict Monitor parent site
To create a relevant information architecture for the Conflict Monitors sites we required user input. Unfortunately (for us), the target audience was spread across the globe. User interviews were conducted with government policy analysts, journalists and non-governmental organization (NGO) representatives. These conversations (in addition to being absolutely fascinating) provided invaluable insight into how users consumed the information provided by the sites.
To overcome the problems that a geographically diverse user group provides we also employed the WebSort (http://websort.net/) online card sorting tool. Both HSRG and iomer created a set of “cards”, common terms, topics or ideas that are relevant to the conflict monitors and input them into our online card sort. Our study was then published by WebSort as a publically accessible web site that could be accessed anytime and anywhere and capture how our user base perceived how information should be organized.
One of the challenges we faced with the card sort was not being able to moderate it in person. Participants were offered the opportunity to leave feedback, but few took the opportunity. This put us at a disadvantage for gathering why users categorized the cards as they did. This drawback aside we were able to gather statistically relevant data on how the information in our site should be organized.
Using the results from our card sort and interviews, we were confident in what needed to be incorporated as we moved into the wireframe phase of the design. In most cases, we use Microsoft Visio for developing wireframes, but for the Conflict Monitors sites we decided to try something different and use Microsoft’s Sketchflow
software. Sketchflow provided us with several advantages over traditional paper-and-pencil wireframing:
- It can be used for quickly developing wireframes with common controls like buttons and grids.
- Sketchflow can be very easily published as a website for remote viewers to access in their internet browser.
- Users can “draw” on an online Sketchflow wireframe in order to submit accurate feedback.
- A user can “click through” Sketchflow wireframes that mimics the navigation of the new site.
The wireframes that we developed went through much iteration before a satisfactory result was reached. As much as I would like to admit otherwise, Sketchflow did not play an important role in that process. In hindsight, the problem was in the presentation of the wireframes as a “deliverable”, a design artifact that is completed then formally submitted to the client for review. Had the wireframes been moved up in the project timeline to straddle the definition and design phase I think we would have been better able to make the design of the site more of a collaborative effort between the HSRP and iomer. My mistaken assumption was that the sense of flow that an “interactive” wireframe would put our layout in context, thus reducing any necessary clarifications in the design.
That being said, we may have taken the long way through the woods, but we still arrived at grandma’s house. The wireframes that were ultimately accepted after a few rounds of feedback were an excellent representation of how the site would ultimately be designed.
Once our mock-ups were completed we wanted to test their efficacy through usability testing. Once again, we looked to an online tool to help us overcome the difficulty of remote users. Usabilla
) provided us with the opportunity to test the usability of our proposed design. Users were presented with a mock-up of our proposed design and asked for:
- General feedback – Users were prompted to point out aspects of the design that they felt positively or negatively towards.
- To perform a specific, time-based task – Users were prompted to complete a task such as “Click where you would expect to find related articles on this post”. The goal of this activity was to collect time-on-task metrics that we would use to determine how quickly and easily a user could find information on a page.
As in the card sorting activity, we were unable to collect feedback from users without being able to ask follow up questions about decisions they were making.
The site that we provided to HSRP was fantastic and is one of the strongest public website designs that iomer has produced. Both the clients and we were pleased with the end result. The development of this site also proved some excellent learning opportunities for our User Experience (UX) practice:
- Moderated usability tests/definition activities are VASTLY better than unmoderated – This is both obvious and painful to experience first-hand .This was the first time I had used both Websort and Usabilla for UX activities. Both of these products are excellent when you don’t have the means or opportunity to individually assess groups of users. The one obvious caveat is the inability to collect users’ thoughts, expressions or asides when they are participating in an activity. Knowing what a user will do is good, knowing why is great.
- Wireframes are a collaborative activity, not a deliverable – If I could change one thing about the design process for this activity I would have not have presented the interactive wireframes as a “deliverable”. Wireframe development should be presented to users as soon as reasonably possible for feedback and testing. The earlier problems are detected, the earlier they can be solved.