Embedded Knowledge—A Nürnberg Funnel
First published in Best Practices in Volume 7, Issue 3 by the Center for Information-Development Management
I continue to be intrigued by the story of the Nürnberg funnel—a magical way of transferring knowledge from teacher to learner.
The image reproduced in John Carroll’s book of that name shows a drawing of two teachers pouring knowledge into a pupil’s head. The drawing expresses the teachers’ agendas—a desire to get as much ‘in,’ in as short a time possible, or as the caption states, “The Nürnberg funnel, surely and rapidly, makes heads bright.”1
What intrigues me about the Nürnberg funnel is not the teachers’ agenda but rather the learner’s. Learning demands effort from the learner and the funnel removes the effort required to process information and absorb it into knowledge structures.
Alas, for our readers and product users, there is no Nürnberg funnel; yet, responsibility for knowing and doing is continually pushed back onto them through the now entrenched service paradigm—self-service.
The self-service paradigm is moving to dominate the relationships that organisations have with their customers. Through intranets, the paradigm already pervades the relationships that most organisations have with their employees.
The knowledge that was once provided by the user support person must now be developed by the user who has been handed full responsibility for performance.
There are very successful examples of self-service solutions:
- Self-service works well when the user has knowledge that enables effective use of the online service. For example, product and troubleshooting knowledge bases work extremely well and are the preferred option for technology professionals.
- Self-service works well when the task is simple and ‘trial and error’ is an appropriate performance strategy. For example, online banking and phone and web-based payments have clearly passed their ‘tipping points.’
However, self-service does not work well when complex tasks are performed by inexperienced users.
Once customers or employees are confronted with tasks that require experience and knowledge, information becomes the key to enabling performance.
The self-serving customer or employee is expected to read to
- decide what to select to read
- know how to manipulate the online environment
- process pages of words and graphics
- progress through online transactions
And reading doesn’t mean words passing before the eye. Reading is about effort, about processing text to discover information, and then about fitting information into existing knowledge structures to support decisions and actions.
Information developers are confronted by a conundrum.
1. Customers and employees push back on information because reading and learning stand between them and their task.
2. The writer knows that the performer will fail or will perform badly without knowledge.
The world of information design is constantly exploring ways of resolving this paradox. There are many solutions because solutions depend on the nature of the performance space and the group of performers.
In fact, the following three case studies hark back to objectives of the electronic performance support systems (EPSS) that were promoted heavily in the early 1990s.
The case studies show how the performance space itself can become the learning space despite the complexity of the task and the inexperience of the performer.
Each study takes a performance support tool, embeds organisational knowledge, and empowers the user without requiring pre-task learning.
Each study represents a solution to a particular organisation problem.
- The technical specification template is commonly used by software engineering units but provided the perfect strategy for building standard team skills across specification writing, review, and application.
- The marketing brief templates lifted ad hoc and partial processes from constant re-work and iteration into professional execution.
- The discussion form was invented purely to ensure that managers who had no time to read guidelines would interview staff with sensitivity and without exacerbating workplace problems.
In 2000, a new software engineering company began the design and development of a complex infrastructure for smart cards (chip cards).
In their first phase, they ramped up from the seed design team of 2 architects to more than 20 architects and developers. The focus of the first phase was product design—everyone, from architect to new engineer, was involved in designing components of the product.
Management was faced with an interesting challenge.
- The business knowledge of the staff was limited—smart cards were an emerging technology and engineers with specialist technology and business knowledge were rare.
- They did not have the budget to hire a full team of experienced engineers. They had to, and wanted to, take on a mix of experience and skills.
- The majority of first phase activity was centred on solution design, which meant that everyone, irrespective of their experience, had to write technical specifications.
- With design came review and feedback cycles that had to be managed efficiently and could not be allowed to consume inordinate time.
- Quality assurance compliance was essential for generating industry buy-in to the new product.
All these issues were addressed by a technical specification template that the lead engineer developed for the team.
The lead engineer had worked with smart card technologies and had a broad understanding of the business problems that the product hoped to address.
He also had 10 years experience in software development, saw the benefit of clearly defined development standards, AND he was a ‘wiz’ with Word.
His technical specification defined the design activity,
- prompting engineers to consider every required element of a smart-card infrastructure design
- stepping engineers through design thinking
- helping engineers write content using the ‘worked’ examples that were included as hidden text
When colleagues read and reviewed a specification, the document layout was familiar and the content was expected. Familiarity and structure streamlined the review and feedback cycle and underpinned the ego-less team culture that they had hoped to achieve. An engineer-designer could see the context of every comment and suggestion.
Other engineers noticed feedback that was provided to one colleague and applied that feedback to their own work-in-progress before the issue was raised in a review.
When a specification was passed to an engineer for implementation, the content was familiar but more importantly, the technology and business knowledge around product development was there, expressed in the components and information relationships of the specification.
I was recently discussing the opportunity to embed knowledge in tools with a colleague and friend, Renée Todres. Renée owns and heads Tipping Point, an Australian e-marketing services company. She was consulting to the Marketing group of a large financial services organisation.
All members of the Marketing group were experienced professionals. They also worked closely with highly experienced product professionals.
Despite the experience in the group, the process of moving product campaigns through from decision to implementation was at best ad hoc and at worst non-existent. Every campaign involved rework, and decision and design iteration.
The disjointed campaign process flow had other negative outcomes. One product campaign was even mailed to the wrong customer base.
The marketing team did not have time to stop and learn. Besides, they had most of the skills and knowledge that they needed. There was simply no efficient flow from product management to marketing channel to implementation channel.
Renée and the Marketing group collaborated to produce three templates that integrated the specialist knowledge of her company with that of the team, and that implicitly defined a process through the creation of process deliverables.
- A product manager requested Marketing group services through a marketing request.
- The marketing channel handling the request worked with the product manager to clarify campaign requirements and produced a creative brief for campaign design and an implementation brief for campaign execution.
The templates presented document headings as questions and each heading included short documentation examples to guide the thinking and the writing of the author.
For example, product managers frequently pointed to something a competitor was currently doing in their campaign request but rarely looked back through their own product and marketing experience to find campaigns that could provide some insights into how to market effectively with the planned campaign.
As in the smart card project specification, examples were used to facilitate ‘doing.’ Writers use examples in two ways: to elucidate an idea using ‘such as..’ or ‘for example…’ or to indicate a sample outcome or output of doing.
Examples are frequently used in forms instead of instructions. For example, the sample dates that sit beside a free-form date field are used to indicate what the output should look like.
The marketing template users were producing specifications for campaign operations. Successful implementation depended on the documentation of each section of the specifications.
Examples reduced the effort required to create useful information. They were concrete and practical. No one had to stop and think “what am I meant to write here?” They looked at the example and translated it into their current campaign context.
The marketing request template prompted managers to identify what had worked or not worked in the past, as well as competitive campaigns that they believed ‘had an edge.’
Prior to the introduction of templates, the product team had focused on what they saw others were doing rather than on reviewing and assessing what had been done before and how successful past communications had been.
It is interesting to note that this organisation went on to develop ‘Guideline checklists’ for each of the templates.
At the same time, it is gratifying to know that the templates stand by themselves as task enablers—just in case there are those who aren’t prepared to stop and learn before starting their task!
Information distributed over the organisation’s intranet is increasingly becoming the organisation’s nominated ‘virtual support person.’ This was certainly the strategy of a large organisation that I worked with in 2003.
The number of Human Resource professionals in the organisation was shrinking at a time when restructuring, retrenchments, performance review changes, falling union membership, and employee rights issues were challenging Australian organisations.
The organisation had a very generous unscheduled leave policy—employees who were unwell could ring up and request leave on full pay. If they were away more than one day, they were required to bring in a doctor’s certificate.
There was no limit to the number of unscheduled leave days that an employee could request.
The organisation accepted that a small number of employees might have been exploiting the generosity of the system but there was also concern that employees might have other problems that were being overlooked, for example, a problem with their team.
A Human Resources and business team redesigned the unscheduled leave policy and system. A new and sensitive addition to the system was the requirement that line managers conduct a formal discussion with a staff member who had taken three or more days of unscheduled leave within a certain period.
Managers were required to conduct the formal discussion on the day that the team member returned to work.
The discussion was formal in the sense that a record of the discussion had to be made and signed by both the manager and the staff member. The record would be filed in the member’s personnel file.
The discussion was sensitive in that, if not handled well, it could incite a claim of unfair treatment or trigger union involvement. The organisation’s agenda as well as the staff member’s agenda would be at play in the discussion.
The Human Resource specialist who was documenting the new policy and system had written a manager’s checklist for the formal discussion. The checklist was extremely helpful but long.
We discussed the likely context for the discussion—staff member returns the next day; everyone is busy, including the manager; and the manager grabs time between tasks and when the staff member is also free to conduct the discussion.
- Was the manager likely to rush to the intranet to read the checklist to prepare for the discussion? Hardly!
- Was the manager likely to use the two-page checklist during the discussion, which though formal, aimed not to be intimidating? Hardly!
We both agreed that the checklist was a helpful umbrella for those who might consult it but that something more practical was required.
We worked back from the personnel file. A document had to be written, dated, signed, and filed. The document had to be a record of the discussion. Normally, a manager might make ad hoc notes. Why not create a form that organised the note taking?
And that’s what we did.
The document had no ‘branding.’ It was listed in the tools section of the policy and system and could be downloaded from the intranet and printed.
The document contained
- a simple, one-page table that had a column for discussion elements or steps such as “Date & time,” “Why this discussion is being held,” and “Follow up actions”
- an identical table that contained short reminders about each step
The table ‘organised’ the flow of the discussion. Of course, we hoped that managers would find the second page of the document useful but we knew many would not take time to read the reminders.
We DID expect managers to use the form. We were sure they would recognise that the form protected them from forgetting to cover aspects of the leave context that could have implications for them and the organisation later.
We were also sure that they would be glad to have “something they could print to use,” and we anticipated their keeping “a couple of spares” in their desk drawer.
My project work with the client finished before their policy and system was implemented so I am unable to say whether our ‘form’ is proving of value to managers.
What I do know is that we thought practically about the information user’s context and we provided ‘layers’ of support.
- A primary layer, the form, that organised the performance space
- A secondary layer, the form reminders, that would clarify requirements if needed
- A tertiary layer, the comprehensive guidelines for conducting the formal discussion, that were available for those who needed richer performance support, AND who had time and were prepared to make the effort to read and process the information
Since the web has spread into every corner of the world and, through intranets, into every corner of our organisations, self-service has become ubiquitous
Self-service saves businesses money but raises issues of skill and knowledge. However, no cost savings are made if self-service results in service failure and loss of custom, or in inadequate performance and organisational disruption.
When a self-service task is complex or requires insights, something else is needed to empower the performer. Information is the obvious solution but information engages the performer’s reluctance to switch focus from doing to learning.
As information designers, we have no option but to accept the self-service challenge and explore information models that will “surely and rapidly” educate our users. We need to start creating 21st century mini-Nürnberg funnels.
1. “Der Nürnberger Trichter, sicher und schnell, macht er die Köpfe hell!”-caption on the image shown in John Carroll’s book. The image may be a reproduction of a copper etching that is held in the Nürnberg Municipal Library. The first recorded reference to the funnel in German literature is probably in “Deutsche Arithmetika”, Michael Stifels, 1545.