Before customers can begin using the Inkling platform effectively they must go through the implementation process. Customer content might arrive to Inkling in multiple formats with outdated design standards. Part of my role is to standardize the visual design and build custom content authoring tools in the customer’s template.
Every implementation presented unique challenges that were solved for through the design process. Here’s an overview of the platform and the process that allowed myself and my team to create solutions for our customers.
Multiple projects are featured here during my time at Inkling for customers such as Hilton, CVS Health, Tumi and others. Case studies below elaborate on design challenges and the final design.
Inkling is a SAAS B2B company in the e-learning market space. The Inkling product is a content distribution tool that allows corporate entities to easily publish, revoke, and iterate content to large and segmented groups of users. These users might be behind a desk or out in the field to perform their job but every type of user can access the content because it’s designed for all devices—regardless of internet connection.
The Library is where users can freely access, search for, and open content. The Reader allows users to easily navigate between pages to read, watch, or interact with published content. Habitat is Inkling’s content authoring tool. Habitat allows the user to drag and drop Patterns, or blocks of ready-made HTML and CSS, onto the page. Users can insert their own text, images, videos, and interactive Patterns called widgets. Once the project is published it becomes an Inkdoc which I would describe as something in between an ebook and interactive website.
Customers I’ve implemented range in industry, scale, and types of users. Users that are creating content (known as authors) might be in an office setting at corporate HQ. Users that are on the front-line (known as end-users) might be in a range of environments: the sales floor, kitchen, industrial zones, or behind the desk at a call center. Custom templates are built for both the authors’ content creation experience, plus the end-users’ reading experience—simultaneously. This means not only do I dig into how content should look in general, but also:
Customers I’ve implemented into Inkling includes:
The implementation process ranges from a couple weeks to months depending on the volume of content we would bring into Inkling, budget restraints, and other factors the customers might introduce.
The primary role of the Front End Designer (that’s me!) is to:
Discovery: The design process starts with discovery. The customer’s branding guidelines and content is analyzed for key components that will impact template development and content conversion specs.
Mockups: Mockups are created to explore ideas and narrow possible design directions. Often, customers provide content that is inconsistent, outdated, and misaligned with their own corporate brand identity. Mockups allow for alignment in design vision for how content will be transformed in Inkling before we go through the work of building it to completion.
Development: Once a design direction takes root the template is developed with HTML, SASS (CSS), JSON, and other proprietary software. We take our master boilerplate code base and “reskin” it with the customer’s design elements, and add on some of the custom layouts we planned in the mockups.
Steps to Launch: Once these steps are completed I collaborate with the content strategist and we build out some sample Inkdocs that represent how the content will look in its completed form when it goes through mass-production. There’s a lot of back and forth in this phase between myself, the content strategist, and the customer as we narrow down on a final look, authoring tools, and set of rule-based styles.
Code for Template Development: An Inkdoc template is essentially all of the branded elements—logos, colors, typography, etc—that come together to create Habitat patterns. Patterns are then dragged and dropped onto the page to create easy starting points for both basic layouts and highly complex arrangements. The user can then manipulate these patterns until they’ve created a page that houses their unique content under one unified design system.
Style Guide for Design Specifications: A style guide is created to document how every design element and Habitat pattern is used across the body of content we bring into Inking. This ranges from arbitrary choices like how to use a generic header or table element—to very prescriptive ones such as overviewing details of an industrial-sized cooking recipe.
Designing for content at scale can be a shot in the dark. We don’t have the time to go through page by page and plan a solution for every piece of content when there’s thousands of pages. Instead, content is divided up by type—much like a persona—which represents larger portions of content. Once we solve for 90% of the content the remaining edge cases are solved for case by case in a post-implementation clean up.
Customers might be using a multitude of formats (PDFs, Word, PowerPoint, etc.) and this must be consolidated into a singular Inkling-friendly format. This is explored in the discovery phase where we asses all the types of content we’re bringing in. When an ambiguous content source is discovered we suss out possible solutions through discussion, mockups, and prototypes—and confirm with our customer what the best path forward is for their users and workflow.
A WYSIWYG platform means authors can design whatever they want—this means templates have to accommodate every possible outcome. Templating starts with a strong base of design elements including typography, color, space, etc. Then, all HTML elements are accounted for including headers, footers, sections, asides, headings, lists, etc. Also, our code-base is the result of years of template building. We rework the code-base and return bug fixes and improvements to the code-base a little bit at a time. This ensures future customers always get the best authoring experience.
