Portal Creation - The Torah on One Foot
- Dr. Moria Levy
- Sep 1, 2004
- 12 min read
For many of us, a portal already exists in our organization. In the past, we may have called it an "intranet," but now, with the acquisition of technology, we're upgrading its name to "portal," but we're not starting with a blank page. Some organizations didn't have a portal or intranet before, but the Public Folders in Outlook served as the shared work environment, a portal substitute. In other organizations, it was a network library or another dedicated environment. In a few places, they start completely from scratch.
Nevertheless, when we come to build the future portal, we are full of intentions, desire, and much hope. We hope to show that there is something new here, with capabilities but also with use and benefit. It is new but based on the foundation of the past. It is advanced but gradual. This article provides practical tools for portal managers to design the new one in the most effective process, with feet firmly planted on the ground but certainly without being fixated on the past.
By the way, the following rules are no less relevant for a group or organizational site.
So, step by step, here are the steps for establishing a portal:
Stage A - Defining the Target Audience
A good portal does not always serve all people in the organization simultaneously. When setting up a portal, you should first define the target audience that the portal will serve. Often, it's preferable to have a portal that addresses a defined need for fewer people, but for whom it provides a significant solution. This can be likened to a surfer's enjoyment from one big wave versus several small waves. The same total energy in both cases, but what a difference in feeling!
Even when we know how to define a bounded group related to the portal, this doesn't mean they are the target audience. Usually, that group can establish a portal that helps it manage its activities more effectively, or a portal that serves the organization (all or part of it) and the people who receive service. For example, let's look at a training school. We can see a portal serving the training staff with a lot of professional content on how to develop training and how to deal with attention problems in classrooms; a completely different portal serving the school visitors with information about restaurants, course assignments to classrooms, and other administrative and instructional information of materials for specific courses; and a portal intended for organizational staff with eligibility information and how to register for courses. The same group sets up portals, but with different target audiences.
As stated, the first step in establishing a portal is defining the consumers, the focused target audience.
Stage B - Defining the Content
First Part of the Content: Defining Business Objectives for the Portal
After defining a target audience, we need to define a business objective that the portal will serve. We need to ask ourselves what we, as an organization, expect to happen better (at the business level) thanks to the portal's existence. How will that target group function better, and why? Defining a goal in terms of knowledge sharing is not enough. We don't set up a portal just for knowledge sharing. We must always remember that most organizations were not established to enable knowledge sharing among their employees. Organizations seek to heal, seek to profit, seek to teach. A goal defined only in knowledge sharing is not sharp enough and can lead to a portal that is not sharp enough and justified. Even if it's true that through the portal we share knowledge, we must go one step further and define the profit that will grow for the organization from this sharing. Examples of profits could be:
Increasing employees' sense of loyalty to the company (a very valid example in high-tech organizations during good times, when the fear of hopping between companies is real and tangible, and the company invests heavily in employee retention);
Increasing the number of Leads turning into sales;
Reducing the time required for management by branch and store managers in small networks, and more.
To ensure that our goals are more than just nice phrasing, we'll ask ourselves three questions about each goal:
We'll try to give examples of content items whose existence and sharing in the portal serve our defined goal. If we don't have such items, perhaps the goal is nice, but not achievable through a portal.
We'll ask how and in what work processes the employee will use the knowledge described. If the employee doesn't use the knowledge, it's a waste to manage the knowledge in the first place.
We'll ask if there are other alternatives to the portal for the employee to obtain the knowledge, and for the organization to manage it. These alternatives may be significantly more convenient and/or cheaper than a portal.
Suppose we've satisfactorily answered the three questions. In that case, we should start the actual work: Roll up our sleeves and prepare a list of additional items (data, information, and knowledge) that belong in the portal and serve the defined goals. Emphasis—when we say data, we don't mean the names of information systems, but specific screens within them that help perform the work and achieve the goal in practice.
How do we define these contents? Classically, it is through interviews, workshops, and listening to the knowledge consumers themselves.
Second Part of the Content: Identifying Killer Applications
Unfortunately, life is not ideal. It's not enough for a portal to contain only content that serves the purpose for which it was established. And why is that? People stand on the other side of the portal. People with independent will, who don't start using a portal just because they were ordered to do so; people who have become accustomed to working in alternative methods, and even if we convince them that the portal is a good thing, it's not easy for them to change their habits.
To make people enter the portal and make it part of their work, we need to integrate Killer Applications into the portal: "loved," "liked," "intriguing," or just useful content that will make users want to enter the portal. Usually, Killer Applications are organizational-general, and not necessarily professional-specific. If you have professional Killer Applications, they are desirable and preferable, but don't shy away from using the standard-organizational ones as well, if they "do the job" and cause people to enter.
Examples of Killer Applications:
Phone directory: This application is very useful. Employees frequently use it, and its convenient location in the portal can make it a real Killer Application.
Information about internal organizational tenders and their results: Employees are very interested in the possibility of their promotion, and managing information about tenders in the portal can be a new step of organizational transparency, or in other places, a step of operational convenience. People are no less interested in the results of the tenders: to know who won what as early as possible. If the information is extensive and updated frequently, a portal that includes this information becomes a not insignificant attraction center.
Dining room: Information about the dining room is a magnet in certain organizations. Some organizations' menus create interest, while others do not, and what interests the employees is the level of queues at any given moment. In organizations with a camera at the entrance to the dining room, capturing shots every minute is not a complicated matter, and an attractive one.
Caution! Adapt the Killer Application to your organization. What succeeds in one organization is not guaranteed to succeed in another. Each target audience has what appeals to them.
Third Part of the Content: Preparing an Inventory List of Existing Items
Another important part of upgrading an existing site is to prepare an inventory list of items on the existing portal site. Some items help achieve the goal (first part above); some constitute Killer Applications (second part above); and an additional part represents items that, although not counted among the previous types, are nevertheless... what to do... in use. These items cannot be ignored. It's not right to ignore them on the pretext that they don't fit with the new portal. A solution must be found for them, either within the framework of their presentation in the new portal or by other (more correct) alternative solutions. Experience usually teaches that these items will be located in the new portal. Usually, they were put on the previous site in the first place for the same reason - there simply wasn't a better place for them.
These three types together constitute the content of the new portal: The first part is the Top-down (against management goals), while its additional parts are the Bottom-up (from the employee’s side):
Stage C - Planning the Organization
After defining the contents, their optimal organization must be planned carefully.
Note! In a portal/site whose contents are not numerous, the issue of planning is not so important, since the scarcity of content makes orientation easier. However, in a content-rich site, the issue of planning is critical. Many portals and sites are not used properly and sufficiently (if at all), not because of a lack of content, but because of the inability to find that content. The key sentence in planning a portal/site is that the difference between three and five Clicks is Use/No Use for the portal.
The portal planning also includes three parts: planning the framework, navigation menus, and homepage.
First Part in Planning: The Framework
The portal framework is more than an external framework; it constitutes the delimiting framework, the fixed anchor of the portal, an anchor that allows quick orientation at any time during our stay in the portal.
The portal framework can be an upper strip, a right strip, or a combination of both (the combination is called an "r" framework). It all depends on the technological tool, its capabilities and constraints, the number of different topics (requiring independent sub-menus), and the independence of the sub-portals/sites (requiring their own fixed menu areas).
It is recommended that the framework include:
Logo + return to homepage (as customary, combined into one).
Quick search (not a substitute for a navigation menu, but complementary to it).
Feedback (very important to receive feedback from users, and the availability of this item is important).
Navigation menu areas.
Hot buttons area (allows quick access to common applications).
Plan the framework's form and main contents. Don't get confused; it's not about graphic design. These guidelines will determine the graphic design's implementation.
A small tip regarding the placement of items in the framework is the middle-of-the-night test: Make sure that search and feedback can be reached even without looking. Place them in the framework's upper right or left corners (the bottom corner is always a flexible definition).
Second Part in Planning: Navigation Menus
The failure of many portals due to a planning problem is mainly related to planning navigation menus. There are many rules for proper planning of a navigation menu, but the main ones include:
Defining menus from the user's point of view. Verifying that a representative user navigates the contents easily (Usability tests). Two good types of division, for example, are:
Division according to the user's work processes (e.g., opening a new customer, supporting an existing one).
Division according to content topics (fire extinguishing, process safety, electricity, etc.).
A less good division is according to the format representing the knowledge (documents, applications, links).
The items in each sub-menu are consistent. The human mind identifies the definition pattern of the items, and inconsistency makes it difficult to scan and locate the appropriate item.
The depth and width of the tree should be balanced. This is easy to say, but not always easy to implement. In any case, opening menus shouldn’t require scrolling (they should fit on one page; the quantity depends on the font and design).
And remember - it's not recommended to give up on navigation menus, saying you can reach information through search. Research proves that the human mind finds it easier to think in a hierarchical navigational way, and 80% of people navigate better with navigation than with search.
Third Part in Planning: The Homepage
The homepage is of crucial importance for attracting the user to the portal.
Unlike regular applications, where the active implementation process constitutes the main basis for creating the change in the employee's work habits and system use, this is not the case with an organizational portal. On one hand, we assume that employees (almost) don't need training. After all, many also access the internet at home without training and manage well. On the other hand, we cannot rely on the occasional entry or the goodwill of employees. Meanwhile, we remember that the portal includes Killer Applications, a means of attraction, but not the main thing. After all, the portal is supposed to serve a certain purpose. A purpose that justifies its development (people entering the portal is not a sufficiently justified reason). The role of the homepage is a combination of functionality and marketing:
Functionality: The portal should contain the most important information for the employee to see in every entry.
Marketing: The portal should include information that will make the user want to explore and return.
And within all these... the homepage should serve the purpose for which it was established, both at the level of functionality and marketing.
How do we do this? The most important information is simply prioritizing needs while adapting to space constraints (as a window integrated into the page, not a full screen). Information that will make people dive in - exposure to the homepage of knowledge, representing links and/or beginnings of new items (somewhere on the site), and/or interesting items/items in focus that are also on the site. Information that will make people want to return - a homepage with changing and updating content.
Note—information about new items is an example of information that serves both goals: It also encourages diving. Since the information is updated frequently, it makes people want to return.
Stage D - Role Holders
Many portals are content-rich (not just application-rich). Sites, all the more so. Unlike applications, where in most cases there is an orderly process for updating information, in sites, one of the stumbling blocks that caused many sites in the past not to survive is related to the currency of the information. To ensure quality, accurate, and up-to-date information, a content manager should be defined for each window and each item in the menu representing content that does not update automatically. Suppose it's a window of a questions/answers forum. In that case, the content manager will be responsible for answering questions that haven't been answered, verifying the quality of answers given, and so on. If it's a window representing static information, the currency of this information should be ensured periodically. If the window includes documents related to a certain topic, the content manager will ensure the initial and ongoing uploading of documents on the topic. And so on.
The content managers’ population is very important in the site/portal. It should be gradually structured and nurtured since the success of the site/portal depends first and foremost on this population.
In addition to content managers, an overall manager should be defined for the site/portal. This manager will ensure content managers’ quality and continuous activity, for menus and shared work areas, and manage the homepage, a page on which everyone will want to be partners if the portal succeeds. The overall manager is also responsible for the user aspect: to examine usage and understand where there are problematic "pockets" in areas where access is less frequent. He is responsible for analyzing the problem, whether it stems from content that is not required, outdated content, or a marketing/implementation problem, and of course, ensuring its solution.
Stage E - The Establishment
The establishment stage is, of course, without which there will not be a "bad" or "weak" portal, but there will not be one.
Some emphases for establishment:
Development: Standards and methodologies. All applications will be linked at one level or another to the portal; some of them will be developed in the technological tool environment on which the portal is based; for some, a presentation layer will be developed in the portal; others will operate as windows under the portal; and there will be developments that will only be linked to the portal. Either way, it's about a new technological environment, large development scopes, and varied development levels. Each organization should adopt binding standards and accompanying methodologies according to which development will be carried out.
Governance (permissions policy): In the absence of an orderly and developed permissions policy, whether centralized or decentralized, the existence of an advanced portal requires such a policy. The levels of decentralization are extensive (see content managers for example); the nature of the contents requires permissions that are not at all hierarchical but networked (people are members of diverse communities, not necessarily according to their organizational affiliation); the scope of developments in the portal requires a non-trivial permissions policy; and last but not least, the very existence of permissions in systems to which there is access through the portal requires dealing with permissions issues that we have not yet dealt with in most organizations. The bottom line is that structural preparation on this subject is required. No lesser solution will bear the burden over time.
Initial content core: A portal consists of a combination of components of different types: in operational applications, the data is already built in; content pages need to be prepared; documents need to be collected, some improved, some structured (in orderly templates). Insights, forums, and various tip corners need to be established. Don't ignore this section; remember, there's only one chance in life to create a good first impression, and a content core, to a not insignificant extent, strongly impacts this impression.
Stage F - Marketing, Training, and Implementation
As detailed extensively in stage C, we don't always have an opportunity for implementation. Portals confined to a focused, homogeneous population can be implemented as part of their role (for example, as a work desk). Performing training and implementation processes for an organization-wide portal/site is impractical.
The alternative is marketing. Marketing is done on three levels:
Initial marketing with the launch of the portal. Creating "noise and bells" to intrigue people and to instill in them the impression that it's worthwhile for them to enter the portal.
Ensuring freshness and updating content on an ongoing basis will create the desire in the user to enter the portal frequently and regularly, not just on a one-time initial basis, with the launch.
Drawing users inside: Creating Teasers, Subscriptions, and other means to make the existing user dive into the portal. The user will be drawn from the portal (such as emails) and inside the portal from the homepage (see content organization stage).
Stage G - Measurement, Lessons Learned, and... Expansion
And after all the effort, we return to classic methods:
The level of use should be measured, but more so, the level of response to the defined goals. Lessons should be drawn regarding methodologies, work standards, and how the project is conducted. And we should run and plan the continuation. We'll often find that we're already at the expansion stage, even before we've launched the initial portal. So be careful. Expand, but work in an orderly manner.
Good luck!
コメント