In 2019, Gartner published research emphasizing the end to “a single version of the truth” for data and knowledge management and that by 2026, “active metadata” will power over 50% of BI and analytics tools and solutions to provide a structured and consistent approach to connecting instead of consolidating data.  

By employing semantic components and standards (through metadata, business glossaries, taxonomy/ontology, and graph solutions), a semantic layer arms organizations with a framework to aggregate and connect siloed data/content, explicitly provide business context for data, and serve as the layer for explainable AI. Once connected, independent business units can use the organization’s semantic layers to locate and work with not only enterprise data, but their own, unit-specific data as well. 

Incorporating a semantic layer into enterprise architecture is not just a theoretical concept, it’s a practical enhancement that transforms how organizations harness their data. Over the last ten years, we’ve worked with a diverse set of organizations to design and implement the components of a semantic layer. Many organizations we work with support a data architecture that is based on relational databases, data warehouses, and/or a wide range of content management, cloud, or hybrid cloud applications and systems that drive data analysis and analytics capabilities. These models do not necessarily mean that organizations need to start from scratch or overhaul their working enterprise architecture in order to adopt/implement a semantic layer. To the contrary, it is more effective to shift the focus on metadata and data modeling or designing efforts by adding models and standards that will allow for capturing business meaning and context in a manner that provides the least disruptive starting point. 

Though we’ve been implementing the individual components for over a decade, it has only been the last couple years where we’ve been integrating them all to form a semantic layer. The maturity of approaches, technologies, and awareness have all combined with the growing need of organizations and the AI revolution to create this opportunity now.

In this article, I will explore the top three common approaches we are seeing at play in order to weave this data and knowledge layer into the fabric of enterprise architecture, highlighting the applications and organizational considerations for each.

1. A Metadata-First Logical Architecture: Using Enterprise Semantic Layer Solutions

This is the most common and scalable model we see across various industries and use cases for enterprise-wide applications. 

Architecture 

Implementing a semantic layer through a metadata-first logical architecture involves creating a logical layer that abstracts the underlying data sources by focusing on metadata. This approach establishes an organizational logical layer through standardized definitions and governance at the enterprise level while allowing for additional, decentralized components and solutions to be “pushed,” “published,” or “pulled from” specific business units, use cases, and systems/applications at a set cadence. 

Pros

Using middleware solutions like a data catalog or an ontology/graph storage, organizations are able to create a metadata layer that abstracts the underlying complexities, offering a unified view of data in real time based on metadata only. This allows organizations to abstract access, ditch application-centric approaches, and analyze data without the need for physical consolidation. This model effectively leverages the capabilities of standalone systems or applications to manage semantic layer components (such as metadata, taxonomies, glossaries, etc.) while providing centralized storage for semantic components to create a shared, enterprise semantic layer. This approach ensures consistency in core or shared data definitions to be managed at the enterprise level while providing the flexibility for individual teams to manage their unique secondary and group-level semantic data requirements.

Cons

Implementing a semantic layer as a metadata architecture or logical layer across enterprise systems requires planning in phases and incremental development to maintain cohesion and prevent fragmentation of shared metadata and semantic components across business groups and systems. Additionally, depending on the selected synchronization approach of the layer with downstream/upstream applications (push vs. pull), data orchestration and ETL pipelines will need to plan for a centralized vs. decentralized orchestration that ensures ongoing alignment. 

Best Suited For

This approach is our most deployed and well-suited for organizations that want to balance standardization with the need for business unit or application level agility in data processing and operations in different parts of the business.

2. Built-for-Purpose Architecture: Individual Tools with Semantic Capabilities

This model allows for greater flexibility and autonomy at the business unit or functional level. 

Architecture 

This architecture approach is a distributed model that leverages each standalone system or application capabilities to own semantic layer components – without a connected technical framework or governance structure at the enterprise level for shared semantics. With this approach, organizations typically identify establishing semantic standards as a strategic initiative but each individual team or department (marketing, sales, product, data teams, etc.) is responsible for creating, executing, and managing its semantic components (metadata, taxonomies, glossaries, graph, etc.), tailored to their specific needs and requirements.

Most knowledge and data solutions such as content or document management systems (CMS/DMS), digital asset management (DAMs), customer relationship management (CRM), and data analytics/BI dashboards (such as Tableau and PowerBI) have inherent capabilities to manage simple semantic components (although with varied maturity and feature flexibility levels). This decentralized architecture results in the implementation of multiple system-level semantic layers. Let’s take SharePoint as an example, an enterprise document and content collaboration platform. For organizations that are in the early stages of growing their semantic capabilities, we leverage the Term Store for structuring metadata and taxonomy management within SharePoint, which allows teams to create a unified language, fostering consistency across documents, lists, and libraries. This helps with information retrieval and also enhances collaboration by ensuring a shared understanding of key metrics. On the other hand, Salesforce, a renowned CRM platform, offers semantic capabilities that enable teams across sales, marketing, and customer service to define and interpret customer data consistently across various modules.

Pros

This decentralized model promotes agility and empowers business units to leverage their existing platforms (that are built-for-purpose) as not just data/content repositories but as dynamic sources of context and alignment, driving consistent understanding of shared data and knowledge assets for specific business functions.

Cons

However, this decentralized approach typically leads those users who need cohesive organizational content and data to do so through separate interfaces. Data governance teams or content stewards are also likely to manage each system independently. This leads to data silos, “semantic drifts,” and inconsistency in data definitions and governance (where duplication and data quality issues arise). This ultimately results in misalignment between business units, as they may interpret data elements differently, leading to confusion and potential inaccuracies.

Best Suited For

This approach is particularly advantageous for organizations with diverse business units or teams that operate independently. It empowers business users to have more control over their data definitions and modeling and allows for quicker adaptation to evolving business needs, enabling business units to respond swiftly to changing requirements without relying on a centralized team. 

3. A Centralized Architecture: Within an Enterprise Data Warehouse (EDW) or Data Lake (DL)

This structured environment simplifies data engineering and ensures a consistent and centralized semantic layer specifically for analytics and BI use cases.

Architecture

Organizations that are looking to create a single, unified representation of their core organizational domains develop a semantic layer architecture that serves as the authoritative source for shared data definitions and business logic within a centralized architecture – particularly within an Enterprise Data Warehouse or Data Lake. This model makes it easier to build the semantic layer since data is already in one place, and analytics solutions that are using cloud-based data warehousing platforms (e.g., Amazon Redshift, Google BigQuery, Snowflake, Azure Blob Storage, Databricks, etc.) can serve as a “centralized” location for semantic layer components. 

Building a semantic layer within an EDW/DL involves consolidating and ingesting data from various sources into a centralized repository, identifying key data sources to be ingested, defining business terms, establishing relationships between different datasets, and mapping the semantic layer to the underlying data structures to create a unified and standardized interface for data access. 

Pros

This model architecture is a common implementation approach we support specifically within a dedicated team of data management, data analytics, and BI groups that are consistently ingesting data, setting the implementation processes for changes to data structures, and enforcing business rules through dedicated pipelines (ETL/APIs) for governance across enterprise data. 

Cons

The core consideration here (that usually suffers) is collaboration between business and data teams that is pivotal during the implementation process, guides investment in the right tools and solutions that have semantic modeling capabilities, and supports the creation of a semantic layer within this centralized landscape. 

It is important to ensure that the semantic layer reflects the actual needs and perspectives of end users. Regular feedback loops and iterative refinements are essential for creating a model that evolves with the dynamic nature of business requirements. Adopting these solutions within this environment will enable the effective definition of business concepts, hierarchies, and relationships, allowing for translation of technical data into business-friendly terms.

Another important aspect with this type of centralized model is that it is dependent on data that is consolidated or co-located and requires upfront investment in terms of resources and time to design and implement the layer comprehensively. As such, it’s important to start small by focusing on specific business use cases, the relevant scope of knowledge/data sources and foundational models that are highly visible, and focused on business outcomes. This will allow the organization to create a foundational model that will expand across the rest of the organization’s data and knowledge assets, incrementally. 

Best Suited For

We have seen this approach being particularly beneficial for large enterprises with complex but shared data requirements and that have the need for stringent knowledge and data governance and compliance rules – specifically, organizations that produce data products and need to control the data and knowledge assets that are shared internally or externally on a regular basis. This includes, but is not limited to, financial institutions, healthcare organizations, bioengineering firms, and retail companies. 

Closing

A well-implemented semantic layer is not merely a technical necessity but a strategic asset for organizations aiming to harness the full potential of their knowledge and data assets, as well as have the right foundations in place to make AI efforts successful. The choice of how to architect and implement a semantic layer depends on the specific needs, size, and structure of the organization. When considering this solution, the core decision really comes down to striking the right balance between standardization and flexibility, in order to ensure that your semantic layer serves as an effective enabler for knowledge-driven decision making across the organization. 

Organizations that invest in an enterprise architecture through the metadata layer and those that rely on experts with modeling experience that are anchored in semantic web standards find it the most flexible and scalable approach. As such, they are better positioned to abstract their data from vendor lock and ensure interoperability to navigate the complexities of today’s technologies and future evolutions.

When embarking on a semantic layer initiative, not understanding or planning for a solid technical architecture and phased implementation approach leads to unplanned investments or failure for many organizations. If you are looking to get started and learn more about how other organizations are approaching scale, read more from our case studies or contact us if you have specific questions.

The post The Top 3 Ways to Implement a Semantic Layer appeared first on Enterprise Knowledge.

SharePoint is one of the most popular Content Management Systems and one used by over 250,000 companies worldwide (ScienceSoft). While this white paper will focus on Document Management Systems and will include examples that are pertinent to SharePoint and SharePoint Online, the KM best practices in this white paper can be applied to almost any Content Management System.

1. Creating Rules and Governance for Your CMS

One of the most impactful things you can do for your CMS is create clear rules and regulations about what can be stored in your system, how it should be stored, and, critically, who is actually responsible for maintaining your content. The process of developing system governance will be different for every organization and CMS, but there are two approaches that we have seen consistently work for our clients: crafting system charters and designing role-based governance frameworks.

System Charters 

System Charters are the perfect lightweight backbone that can help inform every decision regarding your CMS. Your System Charter should include a one- to two-sentence summary of your system’s purpose, what should be stored in it, and its value to your organization. For example, a strong System Charter statement may look like this: 

“EK’s Knowledge Base was created to house thought leadership about knowledge management. Within the Knowledge Base, you will find blogs, presentations, podcasts, and case studies that teach readers about EK’s services and KM as a whole.”

This System Charter removes ambiguity about what should be stored in the Knowledge Base and introduces users to what to expect. 

System Governance 

With an overall framework in mind, you can begin to create roles and responsibilities for maintaining your system. CMSs can quickly get out of hand if every user has the ability to create folders, add pages, and upload content at will. However, users need some autonomy to manage their work and workspaces. My colleagues have explained content governance at length, but I want to highlight three key pieces of guidance for CMS governance here: 

1. Create a cross-functional team for overall system governance. This should be a team that includes staff representing all departments and teams using your system. This overarching team ensures there is accountability for all governance efforts. 
2. Formulate individual accountabilities for content you own. One of the best ways to avoid content being pumped into a system and never addressed is to create rules about what content owners must do with the content they’ve created. There is a fine line to walk here, as having heavy-handed rules will discourage knowledge sharing, but loose rules will allow a proliferation of bad content. To avoid issues, keep rules light and reward good behavior. 
3. Create role-based permissions wherever possible. If a role within your organization doesn’t need to edit the page’s overall appearance, don’t give them that permission. Providing additional permissions as needed is easier than walking back major changes or mishaps. In SharePoint, this can be done by tying the seven permission levels (View Only, Limited Access, Read, Contribute, Edit, Design, and Full Control) to individual roles through the Admin Center or the Active Directory. 

Establishing usage guidelines through system charters and governance frameworks enables you to direct the evolution of your CMS and ensure its long-term maintenance, allowing you to focus on improving the actual experience for your users.

2. Design (Or Redesign) with User Experience in Mind

Many organizations see Content Management and Document Management Systems as utilitarian spaces that don’t need to cater to users’ needs and desires. However, developing a well-designed CMS interface and experience can reduce time spent searching for information, garner trust in the system, and encourage staff to give back to the tool. As such, ensuring your tool is easy to navigate and use is key to the success of both it and your staff. You can cater your CMS to your organization by:

1. Retaining interface consistency wherever possible. Your CMS will be one of many interfaces staff use daily; lowering the cognitive load by retaining consistent button placement and page layouts can streamline the user experience and reduce time to find. While no system looks exactly alike, making structural changes can impact overall staff satisfaction. Your cross-functional KM governance team can take responsibility for understanding the user experience across various sites. Creating design consistency means faster usage, more efficient interactions, and fewer errors – all of which can have a measurable, positive impact on your bottom line. One way to start is by creating a cross-site style guide to simplify the design process and prevent users from having to relearn each site they visit. 
2. Organizing your page based on new users’ needs. Set up your site or page to provide clear introductions to every visitor. You might try adding an introductory paragraph (a Site, Page, or System Charter typically fits well), adding quick links to the most critical and popular documents within your space, and adding contact information for any questions near the top of the page. While not all users will need this information, focusing on new users ensures the most visited and easy-to-digest information is close at hand. When using SharePoint, leverage Web Parts to create call-to-action buttons that users can use to navigate and jump around your site quickly. 

Consider creating a consistent navigational taxonomy to streamline your pages and system’s navigation and overall layout. While navigation by department or service area may be the best approach for some organizations, going through the navigational taxonomy design process is an opportunity to learn more about your end users and create a system that suits the needs of the largest user base. We have repeatedly seen the impacts and frustration caused by having radically different experiences from site to site, such as increased time-to-find and a disgruntled feeling that discourages users from complying with governance processes or disinterest in using the system at all. 

3. Organize with a Metadata Strategy

Metadata is descriptive detail used to describe or provide additional information about a piece of content. Most CMSs allow for the capture of metadata along with content. Metadata can improve knowledge management processes within your CMS by creating faceted searches, managing workflows and governance, and support access controls. 

With your cross-functional team, consider how the organization should use metadata within your CMS by prioritizing the KM processes you want to enable. Potential processes include increasing findability through search, managing and governing content via their applied metadata, presenting useful content to the individuals who will use it most, and enforcing nuanced access controls. To some extent, all of these processes can be started by creating content types. 

Content types are a foundational piece of almost any well-operating CMS. A content type is a reusable collection of metadata for a type of content. For example, a blog post is a content type that can have metadata fields such as title, author, topic, and date published. Most CMSs, like SharePoint, allow you to create custom content types. For a blog, for example, a system administrator could develop a defined content type that can be populated with content and metadata whenever a new blog is published. 

When creating content types, operate iteratively and start small by developing one or two at a time. An Agile approach will allow you to devote your efforts to iterative improvements with real user feedback as staff begins to interact with them, promoting effective, efficient, and focused user experiences. Additionally, always start with the content types you see most often. For example, if your organization posts a large number of News items, start by solidifying a News content type that reflects the standard form and information authors normally include. 

This relatively lightweight effort can be repeated over time and expanded as your content and user habits change. This will allow you to create powerful systems and workflows while keeping your content in manageable formats and repeatable frameworks. Keep in mind that content types work best when they work for the largest percentage of users. To achieve buy-in, ensure content types are designed centrally and communicated to the entire user base, emphasizing their power to make positive changes and improve the user experience. 

4. Workflows

Workflows are a key foundational element you can implement within your CMS. Automated workflows are a powerful tool that can boost the value and usefulness of your CMS if done correctly; however, if workflows are too rigid or slow down work, they can severely harm CMS adoption. Some popular workflows to get started with are content publishing, sunsetting content based on content types (now that you have your metadata strategy), and resurfacing content to be updated at predetermined times. Additionally, well-designed workflows will enforce the policies and procedures in your governance plan, ensuring it will be followed while creating greater usability. 

The best way to approach workflows is by focusing on the following: 

1. Keeping it simple. Don’t over-complicate your workflows with too many steps or people that content needs to go through. Complex processes have more parts that can break down or create bottlenecks. Start by testing one small workflow that can be added to and iterated upon as it gets used and reviewed. 
2. Eliminating extra work. As a system owner, workflows can greatly reduce the burden of content management for you and your team; consider identifying the most tedious parts of content management and design workflows to start. For example, if you know News posts are only relevant for 1-2 months and you constantly have to rehouse them, create a workflow that automatically archives those posts. If this feels too permanent, you can set up a workflow that resurfaces the News post to a content or system owner for revision and repurposing rather than archiving. These simple workflows can save you time and energy, ensure stakeholders maintain content responsibly and help declutter your CMS for your users. 
3. Ensuring content is useful. Workflows can also serve as your automatic auditing system. Unfortunately, many content owners see their role as only content authors. With a fairly simple workflow, you can create a system that notices when a content item is 6 months old and automatically triggers an email notification to the content author to check in and revise their item. This normally isn’t enough to ensure it is actually updated, so consider adding a step that also notifies a new hire or volunteer to review and make notes about whether the item makes sense to them; the content owner can then choose to update, archive, or replace the item accordingly. This workflow can enable small efforts that continually improve and maintain your CMS.

Combine workflows with analytics to ensure that under-used, duplicated, or frequently edited content is addressed by content and system owners often. Think of analytics as another trigger for workflows that automatically point out difficult-to-notice trends or content issues and begin the remediation process for you.

Conclusion

CMSs are powerful tools that require a touch of Knowledge and Information Management best practices to reach their full potential. SharePoint is one of the many Content Management Systems that can be cumbersome, unwieldy, and a financial drain for your organization, but effective KM best practice implementation can transfer your Content Management System into a powerful and business-effective solution for your organization. You can start incorporating these best practices and processes today by starting bite-sized, iterative, and impactful engagements to help you and your users. This white paper is meant to inspire you to start your own CMS improvement processes tailored to your organization. Do you need help improving your CMS and the processes around it? Contact Enterprise Knowledge! 

The post Make Content Management Systems Work for You: Designing Your CMS to Deliver KM Solutions appeared first on Enterprise Knowledge.

Motivation

Motivation is a complex factor to understand, but psychologists, neuroscientists, and learning theorists have amassed quite a body of research. We know that motivation can be positively influenced by intrinsic motivation, experiences of success, and overall positive system user experience.

Learning ecosystems that leverage curiosity and interest to drive intrinsic motivation create much better learning outcomes than learning ecosystems which depend upon compulsory training or fear. There are obviously a lot of process and cultural elements that influence curiosity and interest-driven learning, but knowledge management technology has a role to play as well. In knowledge management, we talk a lot about the findability and discoverability of information:

• Findability describes the ability of a system user (in this case a learner) to find the information for which they came to the system. If I want to learn the basics of graphic design, I might execute a search for “graphic design basics.” Findability refers to my ability to find a beginner eLearning course so I can get started.
• Discoverability describes the ability of the learner to discover new information in the system which is useful – but for which they weren’t even searching. In the example above, I search for “graphic design basics” and find an eLearning course, but I also find an entire training plan with multiple levels of graphic design proficiency and supporting learning assets for each. I didn’t know those additional resources were there, but I’m thankful to discover them as they provide me not only with the course, but with a roadmap to continue advancing my skills.

A well-designed knowledge management portal supports both findability and discoverability of learning assets. Enabling the discoverability of additional learning assets and learning paths inspires curiosity and helps create an intrinsic motivation to learn.

Research shows that learners who experience success are also motivated to keep learning. Knowledge management technology can build success experiences into your organization’s learning ecosystem by automatically conferring certificates when learners complete metadata-enabled learning paths. Knowledge management technology can also create personalization of feedback by leveraging some of the same tools we use to deliver a multitude of content personalization experiences – componentized content and a robust metadata strategy.

Motivation is also strongly linked to the overall user experience a learner has with the learning technology. Learning is a process which requires sustained attention and effort, and if a learner is frustrated with outdated information, a lack of cues to guide attention, or visual clutter which creates cognitive overload, motivation is greatly reduced.

Attention

It is difficult for learners to sustain attention, and many learning activities take place in an online environment where there is fierce competition for that attention. Many traditional training approaches rely on unrealistic expectations of our ability to pay attention. Full-day, instructor-led workshops or even hour-long webinars are examples where learner attention can drop off drastically.

Knowledge management technology can provide solutions to this problem. Componentized content can enable the chunking of educational content in such a way that the same core components of content are reusable across multiple learning contexts. SCORM packages promised this benefit, but SCORM was only designed for reuse within eLearning courses. With ever-increasing demands on learner attention, we know that diverse learning opportunities – including informal learning and social learning – are absolutely critical. Componentized content in a CCMS can actually enable the reuse of content in any context – not just in courses.

A Headless CMS delivery architecture can provide further benefits and allow for the personalized delivery of these reusable learning asset components across multiple learner experiences. If you’ve created a reusable learning asset that explains how to create a budget report, a Headless CMS would enable you to publish that information to:

• A checklist that provides context for a project manager to create and update the report; and
• An explanatory reference sheet for a department director that explains how to apply the information in the report for department-level strategic planning.

When we leverage the latest knowledge management technology to create reusable, componentized learning assets, which can be reused across multiple learning experiences, we allow ourselves to create shorter, varied, and personalized learning experiences, which will help our learners sustain their attention and improve learning outcomes.

Summary

A modern workforce faces many demands for their time and attention and it’s easy for learning to get put on the back burner – even for those of us who love learning. When designing a learning ecosystem, it’s important to remember the learning theory that helps us best support learners and set them up for successful learning outcomes. Supporting learner motivation and attention are key. Knowledge management technology has the potential to improve the motivation and attention of learners – and thereby increase learning outcomes. If you’d like to apply knowledge management best practices to the design and development of your learning ecosystem, EK can help.

The post Knowledge Management Technology to Improve Learning Outcomes appeared first on Enterprise Knowledge.

Join the webinar “From Docs to Components” on January 27 from 3:00 PM – 4:00 PM EST to learn more about how to enable full flexibility for a tailored user experience.

Register for the event here: Online event registration | Drupal4Gov 

The post EK’s Ivanov and Taylor to Speak At Upcoming Webinar On Content Management: “From Docs to Components” appeared first on Enterprise Knowledge.

Between the newness of this powerful technology and the limitlessness of how it can be applied, I’ve seen many organizations struggle to define exactly what they want a knowledge graph to do for them. To better communicate all that a knowledge graph can do, I’ve found wireframing/interface design and user experience flow definition activities to be powerful tools in helping our clients define what exactly they hope to get out of leveraging a knowledge graph. These interface designs are all the more helpful when they’re a result of collaborative design sessions with project stakeholders and subject matter experts (SMEs). 

In this blog, I’ll be focusing specifically on how wireframing can help define knowledge graph-specific use cases from a search perspective, but know that knowledge graphs enhance a wide variety of KM-adjacent efforts at your organization and aren’t solely relegated to the realm of enterprise, asset-based search.

Defining Knowledge Graph Use Cases

As previously mentioned, an organization may be ready for knowledge graph implementation, but may not yet know why they need one or how they may benefit. Most simply, a knowledge graph imparts meaning to data and information, and from that point of view, the possible use cases can seem limitless. Consider the following use cases from a variety of our past clients spanning various industries:

1. As a researcher, I need to identify experts in a particular field by browsing related webinars, publications, conferences, committees, HR data, and other such entities, and be able to determine if I should invite that individual to join a committee. 

2. As a lab equipment purchaser, I need to access all available content about a specific product category so that I can make the most informed buying decision possible.

3. As a data scientist, I need to see how various financial institutions replied to a specific question on the same regulatory form and be able to easily traverse the relationships that exist between the data, institutions, and other such forms.

From the search perspective, facilitated collaborative design sessions can not only define the appearance and interaction points of various knowledge graph-supported functionalities, but can also facilitate the discovery of the types of questions and answers users are expecting to address and access via these functionalities. Understanding the users’ goals allows us to structure, model, and build the data in a way that is best able to answer those questions. Search enhancements like action-oriented results and knowledge panels can serve as a great stepping stone to defining use cases that are increasingly specific to your organization and the particular needs of your users.

Additionally, some of these initial design sessions can clarify what the knowledge graph shouldn’t do. For example, in recently collaborating with a provisioner of scientific instrumentation, software, and services, a design session started with the intention of defining the information assets and data entities to be represented in knowledge panels (meant to appear alongside search results). As part of that same session, search aggregator pages were also drafted and designed to feature any and all information, both knowledge- and product-specific, pertaining to a particular scientific technique. As the session continued, use cases better suited to the client’s goals materialized, and another series of wireframes, this time featuring a variety of page recommenders and topic classifiers, were devised to address those needs.

Identify Knowledge Graph-Supported Functionalities

Similar to use case identification, design sessions can also play a significant role in feature or functionality identification. There are not only many forms via which a knowledge graph’s data can be presented, but a limitless variety of ways of which that data can be collated, organized, and ultimately presented. Oftentimes, feature and functionality definition happens alongside use case definition and interface design, as use cases define the user’s action and its associated goal, and the interface’s built-in functionality maps how that goal will be achieved.

At this step in the process of knowledge graph-focused use case definition, there’s often some necessary data assessment work that needs to happen. Now that knowledge graph-specific use cases have been identified, the quality and availability of the data to be accessed by the graph and presented in the interface must be assessed so that the feasibility of implementation can be measured and it can be ascertained whether or not a data clean-up process is required.

Examples of Knowledge Graph Design in Practice

Below are two abbreviated examples of how EK used design sessions to define and meet user needs as they related to knowledge graph-supported functionalities and features.

Example 1

For a nonprofit and nongovernmental research organization, designs and use cases were iterated upon in parallel. While the project continued, both the designs and use cases shifted as a result of both an iterative approach, which allowed us to surface additional stakeholder thoughts and concerns, and upon discovering that the quality of the featured data was found to be in need of some necessary clean-up or was otherwise missing. Both to ensure that the project was delivered on time and that the expectations of the knowledge graph were defined and met, design-to-use-case mapping became a regular part of the working project cadence. For example, after each design walkthrough where additional requirements were identified or a use case was refined, those changes to the use case in question were mapped to the wireframe, allowing all project members to visually track how the proposed interface supported a use case, regardless of how much that use case may have changed. Mapping the goals of the use cases to specific actions and processes supported by the interface ensured that the project team’s forward momentum remained user focused and feasible. These design validation sessions also allowed for EK to simultaneously train and educate project stakeholders as to how they could use wireframes to demonstrate the values of a knowledge graph throughout their organization.

Use Case to Interface Mapping

Example 2

At an accounting and tax services firm, staff were unable to see any and all content related to a specific client, and this was exacerbated by that content taking many forms, such as survey results and individual documents. To address this need, EK led a series of iterative design sessions to identify the types of data to be featured in both action-oriented results and search aggregator pages. Conducting these sessions in an iterative manner means that each consecutive group of participants provides feedback, and builds, on the inputs supplied by the previous session. At the end of a series of these sessions, the resulting designs have been both refined and validated multiple times by participants’ peers. For example, we worked with stakeholders across the organization to design the client page (featured here) which aggregates information from the organization’s content, HR, and CRM systems to ensure that employees could easily access information like engagement letters, active jobs, survey results, industry intelligence, and more, all as they related to that specific client. Iterative design via collaborating with individuals across the organization allowed us to identify all of these different types and sources of data and information.This repeatable process of refining and validating allows EK to confidently understand how a knowledge graph should be constructed, while also providing a sense of security to project stakeholders in the fact that the recommendations are exactly what the users are expecting and from which they’ll find guaranteed value.

Example of a search aggregator page iteratively designed by workshop participants.

Conclusion

As you can see, there are a variety of decisions to make prior to implementing a knowledge graph, and design sessions with a focus on wireframing can help define the use cases, interface, and necessary features and functionalities to be supported by that interface. Design workstreams running parallel or prior to development/integration efforts ensure that those efforts are directed towards a high-value goal and ultimate increased return on investment. If your organization is ready to explore the benefits of knowledge graph implementation but isn’t sure where to start, reach out to us. 

The post Using Wireframes to Define and Visualize Enterprise Knowledge Graphs appeared first on Enterprise Knowledge.

In my last blog, I introduced the how of chatbots: how they work, how they’re implemented, and how they can help your organization, whether that’s through supporting your customer experience team, connecting users to information and research at the point of need, or request mapping. I also closed the blog with a line about the user experience that’s integral to successful chatbot implementation: “chatbots allow for a customized user experience, and not only allow users to get the information they need more quickly, but can be designed and oriented toward each user’s unique intent and interest.” This blog considers four key elements integral to creating a user-oriented chatbot experience. I’ve also included a selection of questions and considerations to ask yourself and your team before beginning the process of designing and developing the user experience of your chatbot. 

Define Your Purpose

At the outset of your chatbot design and development process, you’ll want to define the chatbot’s purpose. Is it going to be oriented towards supporting your CX team or to connecting users to relevant research and publications? Part of your purpose will be pre-defined by the type of organization you are and the services you provide. When deciding what the purpose of your chatbot will be, consider areas of weakness in your organization and if those areas could benefit from chatbot-oriented services. A strong purpose statement can serve as your ‘north star’ throughout the development process and guide decision-making so that the end product aligns with your initial goal. Having a clear ‘north star’ purpose will also be invaluable throughout the necessary content clean-up and tagging process that happens prior to chatbot development. Additionally, the iterations and use case validations that occur during development should consistently be matched against, and support, your purpose. 

Questions to consider:

• If you’re considering a phased approach to chatbot implementation, what do those phases look like? Does your purpose statement hold true during each of those phases of development?
• Some purpose statements include elements of both the emotional and the rational. Decide how you want your chatbot to make your users feel and consider not only what that looks like from a visual perspective, but the steps necessary to make that happen. What processes must your chatbot be able to carry out flawlessly? What is its main job? What is the use case for your chatbot?

AI & Chatbots

Artificial Intelligence (AI) chatbots have the ability to ‘learn’ in the sense that they’re designed to spot and track trends and patterns in data, like repeat user questions. The programming behind these chatbots is written in a way that not only tracks these patterns, but also applies those patterns where applicable, allowing the chatbot to most aptly service users’ needs without consistent human intervention. For example, consider a company that sells cell phones: user questions about a nonfunctioning power button or a cracked screen would both be routed to a physical repairs webpage.

Questions to consider:

• How ‘smart’ do you want your chatbot to be? Should it be able to notice and document patterns in user queries and adjust its responses in return or should it be designed to answer a set of  targeted, but common, questions?
• What are the more advanced features you envision your chatbot offering? If its main purpose is to connect users to customer service representatives through a series of Boolean questions, you can go light on AI and machine learning capabilities.
• How often and with what resources are you willing or able to dedicate to your chatbot? A chatbot oriented around Boolean questions requires considerably less investment than a chatbot designed to ‘learn.’

Natural Language Interface/Conversational User Interface (CUI)

Chatbots allow users to interact with a computer interface on their own terms and in their own language, regardless of whether the chatbot’s communication process is triggered through Boolean operators (‘Did you want to cancel your internet services?’) or actual queries (‘What publications do we have about bridge development in Paraguay?’). And while Boolean operators limit the questions a user can ask of the chatbot and, in turn, what the chatbot understands, implementing a Boolean-oriented chatbot is an excellent option for a Proof of Concept to prove out a larger, more complex chatbot project.

Questions to consider:

• Related to both the AI section above and the Purpose section below, consider how conversational you need your chatbot to be. Spend some time brainstorming the types of questions you expect your users to ask, and then consider what questions would ‘break’ your bot. Be prepared to spend some time reworking your bot’s logic to address these breaking points. For instance, should your users be able to escape a bot-guided and intent-specific process? In one of our projects, users were finding that they couldn’t request help while looking at publications (i.e. the intent here is ‘view publications’). The bot’s conversational structure had to be reformatted to guide the user through the required steps to complete an intent before returning them to a point where they can choose a new intent.
• When your bot breaks (and it will), how should it respond and prompt the user to try another query? Does it recommend alternative or popular queries submitted by other users?

Personalized Brand Experience

The visual interface of the chatbot should be aligned with your organization’s branding guidelines so that it doesn’t appear to be adversely operating as a separate function of your organization’s user experience strategy. And because chatbots leverage a natural language interface, you’ll want to spend some time crafting the tone and formality of your chatbot’s responses so it interacts with your users in a language akin to your company’s brand and ethos. Your decisions here dictate how your chatbot will look, ‘speak,’ and behave.

Questions to consider:

• Is your organization’s branding up-to-date? Do your design and development teams have access to this branding? While this may seem like an obvious place to start any design process, it’s always a good idea to ascertain that everyone has access to the same, and correct, materials.
• Have you defined the ‘voice’ of your brand? If your brand were a person, how would they talk? Consider the vibe and tone you want conveyed through your chatbot’s ‘speech.’

Conclusion

With some dedicated thought and draftwork, the prompts featured above should help kickstart your organization’s chatbot design process. And while the above points are integral to the chatbot implementation process and can inform your organization’s initial design and development decisions, there’s some necessary data mapping and ontology design work that needs to happen behind the scenes so that your chatbot is both relevant and helpful. Use the prompts above to get a head-start on your chatbot’s design, and contact us if you’re interested in better understanding the chatbot implementation process from an end-to-end perspective.

The post The UX Guide to Chatbots appeared first on Enterprise Knowledge.

This is all well and good, but what happens when you’re the one behind the curtain and it’s your job to create that seamless experience for your organization’s internal systems? Do you know how to operate the mechanisms of enterprise search? In this blog, let’s go behind the wizard’s curtain and discover how search analytics, content reports, and user feedback can help you measure and improve the quality of the enterprise search experience for your users.

Search Analytics

You can collect several different helpful categories of information about your users’ search experiences with web analytics. The metrics listed below can help you pinpoint potential pain points, needs, or frustrations of your end users. 

Metric	Description	How to Use This Metric to Improve Search
Most Frequent Search Terms	Lists the most common search terms during the previous quarter.	Search terms provide insight into the information people are looking for. By focusing your energy on the most frequent terms, you can enhance findability for the content that is most important to users. For example, if users are frequently searching for “annual goals,” you can configure the current year’s annual goals to show up as the top search result.
Average Search Depth	The average location of the selected search result based on the order in which it appears on the search result page.	Searches that provide more relevant results will have a lower average search depth, with users finding what they’re looking for at the top of the page. Understanding your average search depth is a good starting point for your work to continuously improve the relevancy of search results.
Most Frequent Facet Group	The facet group that is most often selected in order to narrow search results.	An important reason for the use of taxonomies is to fuel greater findability. It is important to get regular feedback on which facet groups people use to filter their search results to understand whether that specific taxonomy is needed or whether it can be removed to streamline the search interface.
Most Frequent Facets	A count of the frequency in which individual facet values are selected for search.	This report also informs the taxonomy design, shedding light on which specific terms users are relying on the most to filter results down to relevant content.
Previous URL	The page your user was viewing before they came to the search page.	Understanding where the user came from can provide you insight on the ebb and flow of traffic to the search portal. Did they search for an unfamiliar term from the previous page? Were there gaps in the content of the previous page that caused them to conduct a search?
Number of Search Refinements	The number of times the user performed a new search immediately after a previous search.	If the first search doesn’t produce the desired results, many users will try again using different keywords. The higher the average number of search refinements, the harder your users are working to find relevant results. The keywords users are trying out in the search box can also give you ideas for tweaking your taxonomy and possibly adding in some new synonyms.
Queries with 0 results	The number of times the user received 0 results for their search terms.	It’s useful to know what terms result in a fruitless search so that you can determine whether the search engine needs special tuning and/or whether the content team can add relevant content to meet popular demand.

Content Reports

Since a search experience can ultimately only be as good as its results, the quality of the content surfaced through searches is key. Run reports or build dashboards on the following queries in your content management system. When you share them with content creators and maintainers across the enterprise, they can identify content clean-up needs and take action on opportunities to make the most popular content even more accessible.

User Feedback

Even with copious amounts of data on how your end users are interacting with the search portal, direct feedback from users can offer new insights on the search experience. Options for collecting user feedback include an immediate pop-up survey after each search, and semi-annual polls. 

Simple yes or no questions, such as “Did you find what you were looking for?” will draw out the largest number of responses, and open-text questions, such as “What would have made these results more helpful to you?” will give you a deeper understanding of the experiences of those who take the time to respond thoughtfully.

Do you know how well your enterprise search engine is performing? Do you need someone to help you peek behind the curtains and reveal the secrets of enterprise search magic? Don’t hesitate to make your way over the rainbow. We are just a tap of your red shoes away!

The post If I Only Had an (Enterprise Search) Brain: Behind the Wizardry of a Seamless Search Experience appeared first on Enterprise Knowledge.

This infographic is a visual introduction to how facets can improve item, document, and content findability, regardless of the form and structure of that content. Other factors, like customized action-oriented results and an enterprise-wide taxonomy, allow for an even more advanced search experience. EK has experience in designing and implementing solutions that optimize the way you use your knowledge, data, and information, and can produce actionable and personalized recommendations for you. If this is something you’d like to speak with the experts at EK about, reach out to info@enterprise-knowledge.com.

The post Using Facets to Find Unstructured Content appeared first on Enterprise Knowledge.

Moreville’s User Experience Honeycomb advanced the conversation from just discussing usability and gave designers of web products a more complete tool for strategically analyzing and improving the overall experiencing of interacting with web products. With this increase in completeness came an increase in the complexity of the analysis and discussion. As we decide which facets of the UX honeycomb to prioritize in our product development, accessibility often gets a lower priority than the others (unless we’re developing products for the Federal government). Accessibility is ranked towards the bottom of the UX honeycomb at our peril, however. As discussed below, designing an accessible web product cannot be separated from the other aspects of user experience.

Accessible

IT Accessibility simply means that our web products and content must be accessible to anyone – regardless of disability. In an analysis of the intersection between accessibility and user experience it is important to acknowledge the obvious fact that accessibility is one Moreville’s facets of user experience. If someone is blind and requires the use of screen readers to access the content on our websites, their user experience is going to be poor if we haven’t built an accessible product. But the strategies we employ to ensure our web products and web content are accessible ultimately impact other aspects of user experience beyond the “accessible” facet of the honeycomb.

Findable

One of the core services of Enterprise Knowledge is knowledge management strategy and design, so creating findable content is near and dear to our hearts. One of the key ways we ensure content is findable (sometimes via keyword search, and sometimes via faceted navigation) is through metadata. 508 compliance requires key metadata be associated with any web content. At minimum, this should include:

• Title
• Author
• Subject
• Keyword(s)

If you’re creating content directly in a CMS, this will often be accomplished by “tagging” content (i.e. this blog post is tagged to topic/subject = “Content and Brand Strategy” on the EK website). If you’re creating a document like a PowerPoint presentation or a PDF that will be uploaded to a document management system, you can add the metadata under File > Info > Properties. Adding this information to your web content will simultaneously improve the findability and the accessibility.

Valuable

Take a moment and think about the product value statement for any product you’re developing. Is it:

• To improve employee performance through improved access to learning resources?
• To provide an enticing view of goods and services for sale and encourage consumers to purchase them?
• To raise awareness about the mission of a philanthropic organization?

I challenge you to think of any product value statement where accessible features and content would not enhance your ability to realize that value. According to the U.S. Census Bureau, nearly 1 in 5 people in the United States have a disability. This is not a small market segment – you can’t afford to leave them out.

Useful

As designers of web products we must always be confident and creative enough to challenge assumptions and ask whether the products we’re creating are actually of some use. Web products that are not accessible are inherently less useful. As professionals, we shouldn’t let managers or clients push us to design and build less useful products – it’s not in anyone’s best business interests.

Usable

Often when we talk about user experience, the conversation focuses on ease-of-use (usableness). While making our products more accessible can make human-computer interactions more complicated, a well-designed, accessible system can understand enough about the user to personalize the experience and offer the least-restrictive option to meet that user’s accessibility needs. Barring the level of complexity (or budget) for an automatically personalized user experience, we can allow users to self-select the level of accessibility and assistance that is required. For example, not everyone needs an audio-described version of a video or a companion video transcript, but offering an option to our users can only improve the usability of our products

Desirable

The principles of emotional design (focusing on how a user feels when interacting with a product) can help us use improved accessibility to design desirable web products. Research tells us that we can affect the desirableness of a product through three key strategies:

• Visceral emotional design – Here we design for aesthetic pleasure. When we factor in aspects of accessible product design like adequate contrast ratio, we are improving the visceral emotional design of the product.
• Behavioral emotional design – Here we focus on how well the product performs the desired functions. There’s a lot of overlap between behavioral emotional design and designing a usable product (discussed above).
• Reflective emotional design – In reflective emotional design, we help our product’s users understand the product’s impact on their lives – even when they’re not actively using it. To design for this we really have to understand our users and think about how we want them to feel when they use the product. It’s the most complex of the three tiers of emotional design, but again – improving accessibility, while not compromising style and simplicity, can only improve the emotions users associated with our products.

Credible

Stanford’s Web Credibility Research has resulted in this top 10 list to boost your website’s credibility. It seems pretty credible – supporting research and all. While accessibility is not directly mentioned, a site that is easy to use – and useful (number 7 on the list) repeats two elements of the user experience honeycomb discussed above. In short, good design is good design and a well-designed product improves accessibility, credibility, and overall user experience.

Summary

When designing web products – and creating the content which fills those products – it’s easy to think that the technical experts and leadership within an organization know what’s best. It’s important, however, to prioritize the needs of the system’s users, even if those needs contradict what we think we know. The tension between leadership’s desires and users’ needs already lends a layer of complexity to product design and content creation, and it’s easy for accessibility concerns to get squeezed out by that tension. EK’s consultants can help you balance the tension of these conflicting needs when designing your product and crafting content. Contact us to learn more.

The post The Intersection of User Experience and Accessibility appeared first on Enterprise Knowledge.

As product creators, we should make decisions based on feedback from people who consistently interact with the product, rather than our own priorities and preferences. You may have spent time painstakingly developing multiple end-user personas for both inside or outside your organization. Now that the personas have been developed, it is important to make sure that you consistently weave them throughout your development process to create a great solution for your end user.

Deriving Epics from Personas

Once you have created your product-specific personas, it is now time to take their goals and drill them down into epics. At EK we define an epic as:

Example Epic

Let’s use the following example to demonstrate how a user persona can guide the story writing process:

University-Wide Initiative: Improve the findability of information and experts that students need in order to enhance their learning experience at EK University

User Persona:

Jane’s persona represents one of many students on EK University’s campus that have the same or similar problem. Based on Jane’s goals and frustrations, a digital tool that increases her social engagement and peer collaboration may be created in order to ensure her success because it connects her to other students on the same learning path.

A sample epic may be:

As an active student, I would like a responsive and robust mobile app, so I can engage and collaborate with the other students learning about KM in my class, in real time.

In her persona, Jane is clearly motivated by technology. Her motivation is incorporated into the epic as an app that can be viewed and easily used on her phone. Notice that the epic is high-level yet captures Jane’s goal of being successful in engaging and collaborating with her fellow peers around increasing shared knowledge, quickly and efficiently. Creating a persona-driven epic allows us to center ourselves around the user experience, one where the overarching focus is framed around the user and their needs.

Writing User Stories with Personas

Having developed an epic based on Jane’s persona, you can now break the epic into smaller user stories. Remember that the user stories should be written as problem statements in the perspective of the person who has an issue or challenge; in this case, Jane. So, if you don’t know who the users are and what problem you want to solve then it’s impossible to write the right stories and you end up with a wish list rather than a description of the relevant product functionality. At EK, we describe user stories as:

Example User Stories

Going back to our epic of “develop a mobile app for active students,” we can now break it down to include the following hypothetical user stories:

Sample user stories may be:

As a student…

• I would like to have a tool where I can chat with the peers in my class, in real time, so that I can collaborate on projects and share knowledge
• I would like a space where all relevant course materials are stored for easy access, so that I can quickly get all my documents
• I would like to see my course grades, so that I can quickly check my progress.
• I would like to quickly send and receive emails to and from my peers and from the app, so that I can quickly engage with them about a class.

In her persona, Jane is frustrated by not being able to access class documents easily  and is driven by her goals and motivations surrounding creating positive peer relationships and having goals to maintain at least a 3.5 GPA. Here, using a persona to derive user stories was effective because the user stories were written in a way that identifies the direct user (Jane) and explains what she needs and why she will need it. Using a defined persona allowed us to create a holistic user story centered around Jane and her peers, rather than just a product.

In Conclusion

In order to design an exceptional product, one that is directly related to your end users, you have to understand and utilize your user personas throughout the sprint process. While completing these may seem a bit time-consuming, completing both will serve as the basis for product success and can potentially save you from any major re-designs in the future. One way to keep your epics and user stories centered around your personas, is by keeping hard copies posted on the wall. This way, you will always have a visual reminder of who you are building your product for. If you’re interested in developing personas or successfully applying personas to your product, contact Enterprise Knowledge at info@enterprise-knowledge.com.

The post Personas to Products: Writing Persona-Driven Epics and User Stories appeared first on Enterprise Knowledge.