The first day was a set schedule of presentations and small panels, the second day was an unconference format, where suggested topics were discussed by self-organizing groups of attendees. The 200+ people that attended represented a wide range of experiences, all trying to build a different kind of democracy through the use of modern network technologies.

Many of the sessions, particularly on the second day of unconference sessions, seemed to surround the question of “how?”

• How do we engage citizens in our governmental/policy processes [using these tools]?
• How do we design for a varied citizenry?
• How do we deal with 10,000 comments on our public policy blog?
• How do we assemble the right tools and technologies to build this new vision of government?
• How do we measure success and report back the outcomes of our work?

It struck me that the motivation was strong to deploy these recent “2.0″ technologies, embodied in the many-to-many communicative / collaborative platforms that afford (or are perceived to afford) a deeper civic engagement than is currently possible using “real-world” traditional methods. Public servants want to use these tools. They want to change how government works. They’re just not sure how to get there.

The expression “citizen-centric” was used more than once in the discussions that I attended. When I called out the the classic design pattern (or rather anti-pattern) of building a civic website’s navigation structure to represent the departments and organizational structure of the civic institution in question, I got a lot of nodding heads. “Here’s our org chart, you figure out how to access services.” Classic. This is the dominant design pattern of the government website genre.

Now there’s nothing terribly 2.0 about any of this. The domain and discipline of user-centred design, task-oriented interaction design, whatever you want to call it; it’s been around for quite some time. And a lot of people have been busy working away on trying to better understand the needs and mental models of “users” (be they citizens, visitors, businesses, or whatever label you prefer to apply) in order to design a better experience.

And in doing so, they’ve developed a lot of tools in the proverbial methodological toolbox. Interaction designers have been pondering these problems, or variations of them, for quite some time.

Now I’m not going to claim that we (user experience professionals, interaction designers, information architects, usability geeks, ethnographers, etc.) have the answers to how to transform government. But I did find myself chiming in to the discussions more than once asking if anyone had heard about “method X” or “method Y” — I sheepishly did so a few times, hoping it wasn’t getting tiresome or simply assuming that most people in the room knew what a persona was or how to design effective KPIs, but when asked to see a show of hands, I only ever got a couple of knowing nods of recognition.

So I figured it might be useful to assemble a few of the many methods and tools that public servants can look into in the service of designing “the next government.” And really, in my mind, transforming government (or any institution) is a design activity.

And just to clear up what we mean when we say Design (because it’s a very, very big word in its usage and meaning), Design is not bound to the domain of solely aesthetics or physical objects. Far from it. Design theorist Richard Buchanan outlines four broad areas of design as a discipline. These are 1) the design of symbolic and visual communications, 2) the design of material objects, 3) the design of activities and organized services, and finally 4) the design of complex systems or environments for living, working, playing, and learning.

Pertinent to government employees are the last two in particular. Examples of the design of activities and organized services include logistics, operations, schedules, bureaucracies, cause and effect systems (domain of management, process engineers, bureaucrats). Sounds like government to me. And of course, examples of the design of complex systems or environments for living, working, playing, and learning include buildings, structures, streets, neighbourhoods, towns, cities (domain of urban planners, architects, systems engineers). This is what government does.

The configuration of government and its outcomes are really just a massive design exercise. At least seen through the eyes of this design professional…

But I digress. Let’s get onto the practical stuff.

How do I better understand the needs of citizens?
This is the domain of user research, ethnography, quantitative and qualitative methods. We try to get a 360 degree view of the user by interviewing them, surveying them, and observing them. Looking for inspiration? Read Grant McCracken’s The Long Interview. Take a Steve Portigal workshop. Read Jan Chipchase’s blog. Read Adaptive Path’s book Subject to Change.

How do I design for varying levels of citizenry?
Personas, while contentious within the field of interaction design and not favoured by some, are still a great tool and exercise in design empathy, putting the user front and centre in the design process. Alan Cooper popularized the methods, you can also derive citizen archetypes using Dave Snowden’s Cognitive Edge methods through the process of group signification. Create Mental Models based on human behaviour. Again, refer to ex-Adaptive Path’er Indi Young’s book on Mental Models. Look at what Webcontent.gov did with their personas. Find out about the City of Seattle’s Race & Social Justice IT Project Management Checklist.

How do I deal with all of these citizen feedback now that I’ve created a giant forum for discussion?
While the growing field of text analytics and semantic analysis grows more and more popular, I’m personally still reluctant to place my trust in “machine understanding.” Machines can help us sort out the mess of content that results in large scale feedback, but understanding in my mind is still a very human activity. The field of sensemaking and narrative analysis as put forth by the folks at Cognitive Edge and Anecdote appear to me to be some of the best ways of trying to grapple with complexity. Anecdote circles, story telling, mass narrative capture and group signification: there’s some language hurdles here for sure if you’ve never been exposed to this body of knowledge and practices, but it’s worth spending some time reading it or finding a Cognitive Edge practitioner to help you out.

How do I measure the outcomes of all of this?
Measurement is at the heart of performance management tools like the Balanced Scorecard and shouldn’t be a stranger to government employees working in modern numbers-driven environments. But measuring some of the “softer” things can be tricky. What’s my ROI on engagement? How do I measure the blog comments that we’re getting? Drawing cause and effect lines between a website and the changed behaviour of a citizens is the dream of every government worker involved in building a site, but it’s often just not possible. We’re quite fond of Stacey Barr’s PuMP methodology for measuring outcomes. While she’s in Australia, you might be able to catch her in North America a bit more often in the future – we managed to catch her first appearance on this side of the Pacific in 2009 and were really excited about the workshop.

Of course, if you’re looking for general purpose web analytics, look at Avinash Kaushik, Eric T. Peterson, or head down to San Jose for eMetrics and meet them all in person!

This is just really touching the tip of the iceberg. There’s a lot more. But it’s a starting point.

The methods and tools used by interaction designers have a lot to offer government. And let’s not forget that government has a lot to offer interaction designers. Public planning exercises, participatory methods, and the design patterns of Doug Schuler’s Liberating Voices represent a wealth of material on how we, as humans, have assembled ourselves in groups big and small and changed the way we live. I hope to return to this topic in the near future for some more writing.

Here’s to a continued dialogue amongst designers everywhere. Thanks to Sarah for making OpenGovWest happen.

Many thanks to those who came out to share their experiences for the session.

The Architecture of Gov’t 2.0
Subtitled: This open gov’t stuff all sounds great. Now how do we build it?

Gordon Ross
Vice President/Partner
OpenRoad Communications / ThoughtFarmer
Vancouver, BC

http://www.openroad.ca/

http://www.thoughtfarmer.com

http://twitter.com/gordonr

Session Notes

Introduction
- Hi, I’m Gord
- VP and Partner at OpenRoad in Vancouver
- 15 year old web development firm, specializing in public websites, intranets, and custom web applications
- offer strategy, user experience, development, and analytics/measurement services
- clients include BC Hydro, City of Vancouver, Province of BC, Electronic Arts, Mountain Equipment Coop, Pokemon, World Bank and others

Why I’m here
- currently consulting with the City of Vancouver on their web strategy
- first phase of a multi-phase process to redesign their public website
- consists of 60,000 pages, 130 apps, over 5.0M visits annually
- want to have a conversation with local, regional, state/prov, and fed gov’t members on how they’ve architected their web solutions
- open gov’t sounds great, but how do we build it?

Context
- Centre for Collaborative Gov’t in 2002: e-gov’t, the municipal experience
- evolution of e-gov’t through 3 phases: static info, transactional services, online communities
- still holds true: most of conference aimed at the top level of the pyramid
- but can’t ignore the bottom; can’t build the top without a solid foundation

Building it
- so some big issues when it comes to building
- architecture
- content management systems
- build vs. buy, platforms vs. products
- centralized / decentralized / distributed models of tech + governance
- content strategy (content is king!)

The Discussion
- what has worked for people? who has had a pleasant CMS experience?
- how have people arranged these tools/tech/platforms in the past for best use?
- who wants to share a story?

(transcripts from here based on the handwritten notes I was taking while facilitating this discussion. Not perhaps the most coherent)

WordPress
- become a bit of an industry standard, had some great experiences working with it

Skillsets
- can’t underestimate the importance of having people on the team with the right skillsets
- developers, content designers, IA, editors, web dev

BC Gov’t sites
- 400,000 gov’t pages
- 92,000 PDFs
- 300+ custom apps
- how do you manage that?

Bryce
- once built a site for a Canadian city
- met with an internal line of business in the City
- asked “Do you guys build websites?” by line of business
- team’s answer: “yes”
- business response: “Then go build it.”
- moral of the story: no real interest from LoB in terms of building the site or how it works
- low interest

BXMX
- internal social media, Ministry of Attorney General
- getting lawyers to write content, use a CMS
- customized SharePoint site
- usability really mattered in adoption

Legacy cms systems
- they assume the users are stupid
- really try to control the user experience, enforce forms as much as possible
- prescribe content through templates
- instead of relying on the smarts of the user

King County
- did a redesign
- hybrid: standup sites
- initiative of the day, campaign sites
- big website redesign
- 26 sites, trying to get a common look & feel
- positive experience started with good requirements gathering process
- org-focused website to a different model
- used SiteCore CMS (.NET based)
- flexible, able to build a lot on top of it
- able to standardize look and feel of the websites
- easy for people to add content
- moving HTML production to frontline staff seemed risky
- but great UI: one example was teaching visually disabled staff on how to create web pages
- were able to do it
- migration took 2 years to move site over
- simplified things, designers did struggle at times

- what hasn’t worked to well
- did do a lot of custom work, 350K budget
- painful budget process
- PM process was time consuming and challenging
- obvious ROI isn’t there: all this work so we can replicate sort of what we had already
- difficult to communicate the benefit to the accounting staff
- site core is complex, lots to learn

- requirements for extensive workflow?
- 100 to 200 microsites
- probably 4 or 5 that really use a modified workflow, more than just basics

- capital cost was one thing, getting ongoing operating was difficult

- initial requirements for global search & replace weren’t really met
- something you used to be able to do in page-based editing tools

Workflow
- sometimes have a very vertical approval process in gov’t
- citizen engagement: approvals matter
- risk
- not just about look & feel, it’s about content
- how do you deliver a great content product in an environment that has strict rules?

Tension
- default of gov’t 1.0 web model: everything locked down unless otherwise made open / free to publish
- default of gov’t 2.0 web model: everything is open, unless locked down. closed is the exception, not the rule.

Mashable
- description of Mashable website editorial room
- virtual editors, writers, content creators, web developers
- all in one big skype chat room
- content comes in, editors called upon at various times of the day, edit when needed
- developers tasked small jobs, put content up as req’d
- really flexible model, allows for remarkable real-time publishing process
- as news breaks throughout the day
- all done remotely by staff separated by hundreds, thousands of miles (USA, NZ, etc)

Build vs. Buy?
- some have customized
- example of customizing WordPress
- BC Gov’t feedback: WordPress hard to maintain multiple installs at the enterprise level
- sometimes point releases mean customizations break, almost have to re-build the standalone blogs from scratch
- forces IT to tear-down/rebuild on point release, very time consuming, costly

- another comment: my dream situation, build all on open source
- don’t have to pay license, but pay big costs in customization
- how to pay for it is tricky
- another comment: I found hard to get capital, but easier to divert operating funds
- in that way, open source made sense (more people than budget?)

- Leif
- dream architecture: Zanby
- communities of collaborative groups
- groups of groups, they aggregate content
- enables cross-silo / cross departmental collaboration

- New York State Senate
- yeah, what they did!
- Andrew’s presentation of the previous day, large open source stack, lots of point solutions, custom built, quite a bit of Drupal work

What’s your ideal system? Pretend it was magic!
- ideal system, not sure
- but resource allocation! possible to engage citizens without right amount of resources

- Drupal as the platform
- feeling that it’s really modular
- build it, customize it, do your own thing from the ground up

King County
- Andrew’s NY State Senate team is sharing some of their tools
- sharing code & resources

User standards point of view
- look at your community
- How the City sees the City is not how the city sees the City
- geo-located
- how it effects you, intensely local

Joomla, WordPress
- “I had positive experiences with both”
- we had to use Interwoven Teamsite: it was brutal
- hard to put content in
- so yeah, the ease of use should be really high

Question: who is the ease of use of a CMS for?
- user? citizen?
- content creator, editor?
- web developer? IT manager? system admin maintainer?
- can it be all things to all people?

Wrap up, thanks to everyone. If you see issues with the notes, feel free to edit. It’s a wiki after all!!!

Cheers,

Gord Ross / March 29, 2010

How much content should we have on a page? What is an average page length in words?

And somewhat predictably, I answered, “It depends.” But I went one step further. I let them know why and how it depends.

While I’m not a content strategist in the sense that my fellow Seaquam high school alumni Jeffrey MacIntyre is or the same way that local Vancouver CMS-meets-UX-meets-content strategy guru Rahel Anne Bailie is, I do provide our clients with a lot of web strategy and that does involve a lot of content. And I’ve been thinking about this a fair bit recently, working on a lot of large public website and intranet projects for the past 15 years.

Here’s my proposed content strategy in a nutshell. It stems from two simple ideas:

Understand the context of use of your content and then be channel appropriate.

Context of use? Channel appropriate? What does that mean?

First off, the concept of bounded applicability is in full force when it comes to the type of large bureaucratic corporate website content that we frequently face.

“Bounded applicability simply states that any method or tool has limits. You know you are reaching those limits as the cost/benefit ratio of handling new issues becomes adverse. At this point you should not carry on doing the established approach more furiously, but instead realise that you are approaching a boundary and gain perspective so you can look on the other side.” – Source: Dave Snowden.

The way you design your content and what a page of content is good for, has its limits. If you feel like you’re questioning the usefulness of that page, its content, and the overall design, if you’re getting feedback from users that they still can’t find what they’re looking for, you’re probably reaching the limits of your content.

Remember that, we’ll get back to Dave in a moment.

Secondly, users are engaged in productive inquiry when they visit a corporate website. Productive inquiry is an activity where they are deliberately seeking what they need in order to do what they want to do. Said another way, it’s not inquiry in the form of general curiosity, but inquiry in the service of wanting to get things done.

What types of things are users trying to get done when they visit a corporate website? For our client, we did user research (interviews, observations, surveys, search term analytics) to find out the answer to that question. We identified over 2000 primary tasks that users described in their own terms.

These included very real world tasks like buying things, researching things, learning things, obtaining things. Some of which were directly satisfied by the organization and its services, some of which were not. It painted a brilliant picture of the mental model of the user, their motivations and needs.

In the midst of their information foraging behaviour, where users come to the website to get one of these tasks done and try to make sense of the 1300+ pages our client has on the subject, we hit the limits of cognitive science.

Simply put, users don’t read, they scan.

Enter Mr. Jakob Nielsen and the usability studies of how much or rather how little users actually read on any given web page.

How little do users read?

Answer: On the average Web page, users have time to read at most 28% of the words during an average visit; 20% is more likely.

So what about long articles vs short articles?

Answer: Information foraging shows how to calculate your content strategy’s costs and benefits. A mixed diet that combines brief overviews and comprehensive coverage is often best.

So, as a result of the big 3 concepts of 1) bounded applicability, 2) productive inquiry, and 3) scanning behaviours, our client’s content approach / strategy should be thus:

• Determine which problem domain their target content resides (simple, complicated, or complex?)
• If simple: create a web page, no more than 300 words – example: find corporate contact information
• If complicated: create a web page, no more than 900 words – example: find where and how to access a service
• If complex: delegate to the call centre – example: what happens to me and my super specific scenario

The three domains are from the Cynefin Framework, a knowledge management / sensemaking framework that describes the types of problem domains in which humans interact. It’s more of Dave Snowden’s work.

Read the Wikipedia article on Cynefin for a primer and watch Shawn Callahan’s video on an introduction to the framework.

Okay? All briefed on Cynefin. Good. There’s lots of brilliant stuff in there. I encourage you to explore further or better yet, become Cognitive Edge certified like me and lots of other really interesting people around the world.

Simple is something where there’s a best practice. Where there’s a right answer, quite possibly only one answer. Where the user is engaged in sensing, categorizing, and responding. Where cause and effect is obvious. Deductive logic works here: theory, hypothesis, observation, confirmation. Short content is recommended and appropriate.

Complicated is something that may require more analysis, where there are a few right answers. It’s the domain of good practice. The user is involved in sensing, analyzing, and responding. Inductive logic works here: observe, pattern, tentative hypothesis, theory. Medium-length content is recommended and appropriate.

Complex is where cause and effect are unknown, it all “depends” – the domain of highly specific and personal, multiple variables. The user is having to probe, sense, and respond to figure out what’s going on. They’re heavily into “sensemaking” and doing their best to “figure things out.” This is the domain of emergent practice. They’re in the realm of abductive logic: half theory, half observation, mostly “hunch” or “heuristic” – again, this domain is not appropriate for your typical top-down, expert written content. You can’t cover all of the scenarios that come up. You can’t deal with all of the variables. You can’t author content that predicts all of the unknowns in this domain.

No web content other than “CALL US” should be on this page. Talk or interact directly with a human being or many human beings. We are sensemaking machines. Static web pages are not.

Having said that, there is one argument for web content to manage the Complex domain.

If our client company had a social forum area where people could discuss their problems, tell stories, read each other’s anecdotes, then you’d have a proper group of content for the complex domain. But in our client’s case, they don’t. They have their official materials and official policy. So any social interactions need to happen between the customer and a corporate employee on the phone or in person. Answers in complex situations are highly contextual. A context strategy (not a content strategy) should be social: i.e. talk to someone. Or some people.

The endless hype around user generated content and social media seems to miss the fact that it’s sometimes totally inappropriate and that lots of problems can be answered by corporate, few-to-many, expert-written content. For our client, a large public sector bureaucracy, it was inappropriate to suggest a social strategy for their complex content simply due to the nature of their business. Privacy and legal issues were too great to allow for customers to share their experiences and benefit from a social experience. But if privacy and legal issues had not been present, this would be a big win for our client. Social forums and human dialogue (one-to-one or many-to-many) are where people make sense of complex subjects.

So, in summary, here’s my take on an integrated approach to content strategy.

• Step 1: Understand what task the user is trying to accomplish. What is the user trying to do when they come to the website
• Step 2: Understand if the answer to that task is simple, complicated, or complex
• Step 3: Write and design content appropriate for that level [remember: users scan, they don’t read] (simple = less, complicated = a bit more, complex = call someone)
• Step 4: Publish content, measure the results using Google Analytics and the inquiries to your call centres, determine if it’s working through customer satisfaction surveys
• Step 5: Iterate and revise content, tuning where required

Given the word count of this page, perhaps next time I should take some of my own advice…

Wish 1: Consider context of use with mobile design

Mobile is hotter than ever.  In North America, the mobile carriers have been making the access to the web on mobile devices easier for the

Mobile Context Model (Source: Giant Ant)

customers to swallow with more reasonable plans. With this growing customer segment, companies are starting to understand the value of a mobile presence.  What they often forget is one of the most important rules of mobile design – Context of Use.

My wish for 2010 is that mobile designers think about how and when users are going to be accessing these sites.  They should be asking themselves: ‘What information is important to them?’,  ‘What do users want to do with your site on their mobile?’, ‘Where will they be accessing your site – on the bus, at home, in a restaurant?’  By starting to think about these key questions, the usability of mobile sites will start to improve.

Wish 2: Design for the End to End Experience. Think about the whole experience.

At the end of the day, we are designing experiences.  A website, a mobile device, a print piece is all part of a complete experience for the customer.  Customers don’t think of all of these pieces in isolation, they see it as all the same experience with one brand.  When one piece of the experience doesn’t exactly flow with the other pieces, customers are often left to their own to work their way through it and figure things out.  Often this translates into both usability issues as well as a decrease in brand perception.  Apple is an example of a great end to end experience.  Their in-store experience, their online experience, their device experience down to their out-of-box experience, there is a universal thread that guides their customers.  This leaves their customers with an experience that is satisfying, and easy to understand.

My wish for 2010 is that designers and clients care more about the whole end to end experience.  Even if we are just tasked to look at one slice of the end to end experience, an understanding needs to be gained of what the whole experience is. This way we can ensure that we are creating compelling experiences which allow customers to flow seamlessly through.

Two simple wishes for the year 2010.  Both wishes keep the user at the heart of the design process by thinking about when and how they will interact the design.  If these come true for 2010, we will begin to see more innovative experiences emerge.

In 2006, OpenRoad was awarded a contract by the BC Ministry of Transportation to build a web-based system to help commercial vehicle carriers (ie: truckers) around the province of BC apply for their National Safety Code Certificate.

Keeping BC’s roads safe

The certification process is about keeping BC’s roads safe, ensuring that commercial truckers abide by a nationally agreed upon set of rules for their vehicles and drivers. In BC, there are over 26,000 commercial vehicle companies operating over 76,000 vehicles.

Obtaining an NSC certificate is mandatory for the truckers of BC. You have to have one. In years gone by, this process involved filling in a lot of forms, sending them via mail or fax to the BC government, then waiting to hear back on your status. Roughly 80 to 90% of the time, the submitted information was incomplete or incorrect and there would be extensive back and forth between the trucker and the government. Time would pass (typically just over a week) and eventually the certificate would be issued. Close to 3000 applications were received annually with that number growing each year.

Chronically incomplete information, ill-prepared commercial vehicle carriers, overloaded clerical staff chasing down faxed-in paper forms: the process was in need of improvement.

And so the CVSE tendered the work to build a web-based system to automate the application and approval of NSC certificates and OpenRoad was the successful proponent.

The application is simple. Truckers go through a multi-part online form that mimics the information collected previously via paper-based forms. They submit information about their company, their vehicles, their drivers, and their safety record. They attach supporting documents, if necessary, then they make their payment and exit the e-service.

Government staff receives the application, review the information to ensure it is correct, and process the application, resulting in a confirmation email and issuance of a PDF certificate to the commercial vehicle carrier.

Validation rules within the web application ensure that information is complete and correct. When commercial vehicle carriers submit their information, the web applications uses web services to query the government mainframe to verify the information. The legacy systems at the core of the government’s operations are crucial to the overall application proceeding smoothly.

Ambitious goals

The business objectives of the team were aggressive: reach a 50% adoption of the online application form within one year of implementation. That’s right, move half of the applications from a paper-based system to an online system within in the first year. If you’re a business owner of a manual-paper based process and you’re contemplating moving it online, how comfortable would you be in targeting 50% adoption? Year two (2009) the team hoped for 70% adoption, year three (2010) 80%, and year four (2011) 90%.

The team was optimistic and dedicated to the success of the program. And they were right in reading the demand of their target customer, the commercial vehicle carriers.

But the results were well beyond anyone’s expectations.

The Safety Certificate Application Online (SCAO) launched in 2008 and within the first year of usage achieved an 80% adoption rate and it continues today to increase towards the 90% year four target. The average time to process an application dropped from 8 days to 1 day with the increased accuracy of information submitted. Overloaded clerical staff were re-assigned to other more pressing tasks within the Ministry and the cost savings have been significant.

Lessons learned

Automating paper-based processes using web based applications may seem like old news to many, but the point we believe SCAO has made is important: there’s still lots of value in Web 1.0, servicing the needs of inefficient business processes that consume far too much time and effort than is required.

And don’t underestimate the appetite for your customers to utilize the tools and technologies you create. Who knew commercial truckers would be so willing to adopt an online tool? Ease of use was an important factor in the application’s success, but the real driving force wasn’t usability but utility. It was clear that the process could be made better and SCAO provided that. The usefulness of the application was so compelling that everyone started using it immediately.

So while you’re looking at your web strategy, don’t get too distracted with social media and microblogging and all that wonderful 2.0 stuff – there’s still plenty of room left for innovation using 1.0 approaches, ones that drive real value, demonstrate real ROI, and improve customer and employee satisfaction.

Mega Drop-Down

The concept of the mega drop-downs started to become more popular after a post by Jakob Nielsen in March. After this post, sites started adopting the mega drop-downs – some successfully and others not so successfully. The mega drop-down does help users find the information they are looking for quickly and easily by showing categories of information upfront. The mega drop-down isn’t for every site. Sites need to have adequate hierarchy and depth to them to warrant introducing this. If a site only has two levels of navigation, I wouldn’t recommend introducing it won’t necessarily improve the efficiency of finding information; it may actually hide information from the user.

The keys to success of the mega drop-down are:

• Proper categorization and appropriate level of granularity
  
• Timing and behaviour of menus should follow outlined standards

Columbia Sports designed an easy to use mega dropdown

Faceted Browse

Finding ways to help users to find information on a site more efficiently has been a growing interaction design challenge especially on e-commerce sites.

Office Depot has a good example of faceted browse.

Companies want to increase the conversion of the browser to a purchaser. The adoption of faceted browse is being seen as the solution. This allows users to narrow down the information on a site based different content/product characteristics.

As with any new interaction model, there are good and bad ways that people have implemented them. In September, UX matters published a good article “Best Practices for Designing Faceted Search Filters”. This article breaks down the faceted design into 5 things you need to consider:

1. Decide on your filter value-selection paradigm.
2. Provide an obvious and consistent way to undo filter selection.
3. Always make all filters easily available.
4. At every step in the search workflow, display only filter values that correspond to the available items, or inventory.
5. Provide filter values that encompass all items, or the complete inventory.

Multi-tasking behaviours

The past year has seen a dramatic demand on the demands of application and website design assuming that we are adaptable task switchers. Interactive experiences are providing us with a continuous stream of information with which we are meant to process and respond to. Task switching is not to be confused with multi-tasking, the art of being able to do multiple things at once. Task switching is a behaviour in which when you stop attending to one task and start another task. This allows more attention to be placed on one task rather than dividing attention between two or more potentially important tasks. Throughout your day this occurs hundreds of times, and now more frequently with little widgets that serve as a cue that more information is available.

Twitter and Facebook both do this well by indicating to the user that there is new information available since the user started their experience with the application. Rather than just dynamically update the application with the new information, a visual cue in the user interface is displayed. This allows the user to stay in control of their experience and their place within the application – key usability principles that are often forgotten.

Twitter supporting task switching behaviour

Game design principles

Principles of game design and play are starting to creep into the design of everything interactive. Companies are starting to understand that injecting some elements of game design into their design does not mean that users are going to be less efficient or view their brand differently. Some companies, like Twitter, have used the game model of collecting to help enhance and entice user interaction. In these places, collecting is being used as gathering ‘followers’ as some people use this is an indicator as their power of influence.

Ways to introduce gaming principles seamlessly into your next design project:

• Saving progress: More applicable to application design and exploratory web experiences, allowing users to save ‘work’ and come back to continue later.
• ‘Tutorial’ style introductions: A lot of games provide users walk users through the ‘how to’. This is always accessible to the players at any time during their game play. Think about your own ‘help’ design and how it can be made more engaging and easy to use.
• Progressively add complexity to the experience: As your users become more proficient with your design, start to introduce levels of complexity to keep them challenged and motivated. This works very well in cases when the user has to learn a basic set of skills before they move on to different parts of the application or experience you are creating for them.

Touch Interfaces and ‘the Swipe’

With the new iPhone being released in the summer, the further exploration, adoption and use of the touch interface continues. This has positive and negative impact to the resulting user experience. Because there is one less barrier (or piece of hardware) between the user and the screen, they have high expectations with the resulting performance and responsiveness of the interface. Users expect the immediate action; and are less tolerable of targeting problems.

More and more mobile devices are starting to adopt the touch interface mode of interaction. At the end of the day, does the touch interface help make users interactions with their mobile more or less efficient? It does make it more compelling, but the overall satisfaction of users still hinge on how simple and responsive the UI is. The number one rule of designing for any touch interface, whether it be on a mobile device, kiosk or computer screen is to ensure that there is enough space between buttons and actionable areas so that a user can select what they want to successfully.

The other night I saw an ad for the new HP Photosmart Premium TouchSmart Web All-in-One Printer. This is a printer that has a touch interface in which the ‘user’ was using the ‘swipe’ gesture to navigate to different screens. Will this introduction of the touch interface take off on a peripheral that we all have had a love/hate relationship with? Time will tell – maybe touch is the answer!

Walter has been instantly productive at ORC, jumping into a major project set to launch next year, and well as testing several Electronic Arts game title sites.

Carolien Dekeersmaeker joins the ThoughtFarmer team as Sales Coordinator.
Carolien has a Masters degree in French Literature and completed a post-graduate Communications program at the University of Antwerp (Belgium). She brings over 6 years of experience in customer service and account management. Carolien joins us after various roles at Uniserve Communications which included time in account management, presales, and wholesale coordination. Prior to Uniserve, Carolien was at British Telecom as an Order Manager for their Global Services department. She’s known for her exceptional follow-through, a strong customer focus and methodical work ethic.

Carolien also brings some great multilingual support as ThoughtFarmer continues to explode internationally. Her French, English, Dutch and Spanish language skills are sure to come in handy as ThoughFarmer 4.0 launches in 2010. Carolien will be helping improve our ThoughtFarmer sales process and manage the furious pace of our demo schedule.

Walter and Carolien were able to join us in time for our Christmas party and our Christmas gift exchange and have not been scared off, so we look forward to continuing to enjoy their support into the new year and beyond.

Welcome Walter and Carolien!

image: The Consumer Decision Making Process (Kotler) as found in Peter Morville’s book, Ambient Findability.

Buying software is not an easy job. There’s a ton of software options out there. We’ve been on the other side of the table for many years, having done countless CMS evaluations for our professional services clients in building large public websites and intranets. We’ve relied on vendor evaluation lists and requirements checklists like those published by Tony Byrne at CMS Watch and James Robertson at StepTwo. You may have viewed the Gartner Magic Quadrant report, which we also appear in. You may have enlisted a professional services firm to help with the evaluation.

These tactics are all useful and help you march through the myriad of choices from Total Set to Awareness Set and onwards towards your final destination of Consideration and Choice. Of course, if only we could be quite as rational in our decision making as Kotler’s lovely flow chart diagram. Most often, the decision process is still a bit of a black box.

One helpful tip that came across my inbox the other day was from a potential client who’s in the process of evaluating ThoughtFarmer. They sent me a detailed spreadsheet with their requirements. Now this is not unusual and often forms the basis of the evaluation process. But what was unusual was the way they documented their requirements.

They took the typical software requirement of “the system shall do X” and wrapped it with some more context. It’s a user-centred requirement, without needing to write some massively detailed use case.

Here’s an example of a single requirement.

What’s so special about this way of documenting requirements?

They identified who this requirement was for. The User. They also included requirements from many other users, including the Intranet Manager, the IT Manager, and the Intranet Editor. I quickly got a sense of the different roles they had involved in their intranet.

They stated what they wanted. They wanted to be able to blog. Or more to the point, they wanted users to be able to publish their own information on what they were doing (which may be satisfied by the feature of a blog, but may also be satisfied in some other way). I understood their goals.

They told us why. Again, they gave us a bit more context around the request. We want a blog and here’s why. The advantage for us as a vendor is that if we have a feature which may meet the need, but better than that, we now understand a bit more as to why it’s being requested. If they think they want a blog, but explain why and we discern that perhaps they want a more wiki-like feature, we can now begin to engage in that dialogue with them about their needs and how we can meet it.

So for you intranet managers out there, evaluating software packages, this is a great place to start.

Ask yourself the following:

• Who’s the user?
• What do they want?
• Why?

You’ll save yourself and the vendors you’re talking to quite a bit of time and effort in clearly communicating your requirements. Remember, it’s really about the needs and wants of your end users, not some shopping list of features.

* This blog post is re-posted from the ThoughtFarmer blog. Read more about our social intranet software.

Cat, Ben & Barb from Habanero, Chris from Optimal Interfaces, Gagan from DesignStamp, Theresa from Key Pointe, freelancer Katja, and myself (Gord from OpenRoad) met up with Eric from the Pine St Community Garden and started our 12 hour user experience “design slam” with in-person interviews and observational research. We then moved onto the Network Hub for the afternoon, who graciously provided the space for free, where we marched through the ideation process.

Stickies were heavily used. Coffee was consumed. At at the end of the day we came up with a few design interventions that we thought might be able to help the garden.

Our presentation back to the Vancouver User Experience community happened on November 17 where we talked about the process, our findings, and encouraged other community members to participate in future design slams.

Vancouver User Experience Group: World Usability Day 2009 from Gordon Ross on Vimeo.

Thanks again to all participants, the Network Hub, and the Pine St Community Garden for working with us.

In her presentation, Selma covered the basics of user centred design, interaction design principles, and usability testing as they pertain to mobile devices.

If your mobile project or team could use Selma’s expertise, please contact OpenRoad for more information.

You can also follow Selma Zafar on Twitter: @selmaz