I worked as content architecture lead on a process change team of 17 building out an internal video content production studio for Pfizer. We reduced production costs of dynamic content assets by more than 50% and accelerated project delivery times by 600%, while delivering higher-quality content.

Situation

Pfizer, one of the world's premier pharmaceutical companies, had fifty-five global brands in 2021. Most of them were operating autonomously in terms of content marketing–outsourcing production to dozens (and dozens) of vendors, there were issues with inconsistent branding, unnecessarily long production timelines, and redundancies. 

Task

Establish an internal production studio focused on creating audio and video assets. Offer a baseline menu and content strategy of “80% solutions” effectively addressing shared challenges between Pfizer brands. Provide a customizable and extensible foundation of high quality and consistent assets and strategies to build on, meeting each brand's individual needs on a project-by-project basis.

Goals

• Handle all aspects of content creation: ideation, production, and distribution.
• Ensure a unified brand voice.
• Reduce costs by eliminating duplicate work and overlapping efforts.
• Improve time to market.

Action

Assessment & Planning

1. Conduct a analysis of current content production processes, identifying strengths, weaknesses, and opportunities.
2. Benchmark against current market research and industry best practices to inform the studio's design and operation.
3. Make a business case highlighting an internal studio's potential cost savings, efficiency gains, and strategic benefits.

Studio Design & Setup

1. Secure buy-in from critical stakeholders and allocate budget for the project.
2. Utilize don't repeat yourself (DRY) and keep it simple, silly (KISS) principles in developing automated workflows.
3. Create a content calendar to plan and prioritize projects, aligning with product launches, campaigns, and other key marketing activities.

Process Implementation

• Establish a branded shared asset library to eliminate cost overlap while maintaining support for high-quality content production.
• Establish clear documentation of workflows and guidelines for content creation.
• Implement a project triage and management system to streamline content production, track progress, and supervise deadlines effectively.

Training & Development

1. Provide training documentation and instruction for the new studio team on Pfizer's style guide, values, product portfolio, and compliance requirements.
2. Foster a culture of continuous improvement through recurring feedback sessions, professional development opportunities, and industry trend analysis.

Launch & Evaluation

1. Launch the studio with a phased approach, starting with pilot projects to refine processes and address any initial challenges.
2. Establish key performance indicators (KPIs) to measure the studio's cost, efficiency, and quality impact.
3. Conduct regular performance reviews and adjust strategies based on data-driven insights.

Results

• Reduced production costs by more than 50% through decreased reliance on external agencies, streamlined workflows, and effort redundancy elimination.
• Accelerated content turnaround times by 600%, enabling faster response to market opportunities.
• Achieved a consistent brand voice and higher-quality content, leading to increased engagement and positive feedback from both internal stakeholders and external audiences.

My Role

Content Architecture Lead on a team of 17

Timeline

Six Months

Skills

• Marketing Strategy
• Content Marketing
• Automated Workflow Development
• Process Change Management
• User Experience Design (Internal Tooling)
• Market Research
• Systems Design
• Branding

Tooling

• Adobe Experience Manager (AEM)
• Adobe Digital Asset Manager (ADAM)
• Adobe Indesign
• Atlassian Confluence Platform
• Microsoft O365
  • Excel
  • Powerpoint
• Figma

After having worked in design, engineering, and marketing roles at an integrated marketing agency for six years, I was looking to specialize. In 2013, I moved into an Interaction Designer role at Fire Engine RED–a higher education marketing services company. They were taking an "internal startup" approach to building a new software product–a contact relationship management (CRM) system for the higher education market with a business to business (B2B) software as a service (SaaS) business model. This product was Fireworks CRM (or just "Fireworks".)

I worked there for six years, moving my way up to User Experience Lead and eventually Director of User Experience. The product launched shortly after my third year at the company. While we gathered customer feedback and continued building features and support, year-over-year user growth was over 300% for three years in a row. I left the company in 2019. On December 14th, 2023, Fire Engine RED was acquired by Carnegie.

Situation

A marketing services company serving the higher education sector—Fire Engine RED—was experiencing growth in demand for more personalized, data-driven solutions for colleges and universities managing student recruitment, communication, and engagement. Fire Engine RED offered consultancy and other outsourced recruiting and marketing services to higher education institutions. As the landscape shifted toward more personalized marketing solutions, Fire Engine RED saw an opportunity for a CRM tool tailored specifically for this audience.

Fire Engine RED decided to create an internal startup team and build its software product: Fireworks CRM, or "Fireworks" for short. The Fireworks vision was a SaaS-based CRM platform that helps higher education marketing teams offer a user-friendly, consumer-product-like experience. Salesforce was already in the market but was an expensive, complex solution with no specific tailoring to the needs of higher education clients. Fireworks CRM's goal was to manage leads better, automate communication, track student journeys, and analyze engagement metrics. The product would need to be intuitive, accessible, and aligned to both the sector's specific needs and the company's existing service offerings.

Fire Engine RED had already developed quite a bit of internal tooling and used some of that knowledge to set up an 'internal startup' team. This team was tasked with the design and launch of an MVP (Minimum Viable Product) for the CRM platform.

Task

The core objectives for the Fireworks launch project were:

1. Develop a simple-to-use yet robust SaaS CRM platform to manage leads, execute communications (text and email), and track engagement for higher education institutions.
2. Design the user experience (UX) to be intuitive and easy to navigate for non-technical marketing professionals at universities.
3. Ensure WCAG accessibility standards compliance to guarantee inclusivity for users of all abilities.
4. Release a functional MVP within twelve months to validate the product concept, acquire early users, and refine the platform based on feedback.

Action

When Fire Engine RED's leadership recruited me, they were more than nine months into a waterfall development process with little to show. After working under these conditions for six months, I met with the Principal Software Architect, Product Manager, and Project Manager and built a coalition advocating for change. We developed a process change proposal for moving the team to Agile development and got approval from the VP of Product, VP of Sales, and CEO.

We applied our process change plan over the course of a couple months. See this article I wrote about UX Design teams working in agile frameworks. Fire Engine RED's development team demonstrated remarkable adaptability in embracing Agile development principles following a two-week sprint cycle.  

Planning & Backlog Creation

The team identified critical features for the MVP, which included robust authentication and permissions management, demographic segmentation, automated email campaigns, and basic reporting functionality. I worked with the product owner, engineering manager, and project manager to prioritize these based on customer needs, market demand, and team bandwidth.

User Stories & Feedback

As part of the product backlog, user stories ensured the platform met specific pain points of marketing teams in higher education institutions. User research, including surveys and interviews with seasoned university marketing professionals formed a solid foundation for design and functionality.

My UX team followed a user-centered design process that emphasized usability and accessibility. Throughout the development cycle, we focused heavily on feedback from potential end users.

User Research and Persona Development

• Interview university marketing teams, including admissions officers and digital campaign managers, to understand their challenges with existing CRM solutions. With Fire Engine RED's existing client base, accessing these user groups was easy.
• Develop user personas using our research.
• Key pain points included managing complex data imports and exports, lack of data insights on student engagement, and convoluted user interfaces that impeded productivity.

Wireframing

• Based on user feedback, the design team created low-fidelity wireframes and early-stage prototypes. They focused on making key actions and interfaces simple and streamlined, ensuring users could navigate the system with minimal clicks.
• Usability testing was conducted on prototypes, gathering feedback on user flows, interface elements, and system design metaphors allowing users to move between Fireworks modules with ease.

WCAG Accessibility Standards

The team adhered to WCAG 2.1 AA guidelines throughout the design and development process. Key featured included:

• High contrast visual elements.
• Keyboard navigability.
• Descriptive alt text images, icons, charts, and graphs.
• Screen reader compatibility to ensure users with visual impairments can navigate and interact with the platform.
• Usability testing sessions allowed the team to identify usability issues early on and make adjustments, ensuring the MVP would meet the expectations of real users.

Development and Testing

The software development team, following Agile practices, worked closely with my UX team to implement the user interface and core features. The MVP's backend was built using the Laravel PHP web application framework, while the frontend was HTML, SCSS, and Handlebars.JS, designed to be lightweight and responsive for desktop and mobile use. Our UX team ran regular accessibility audits to verify compliance levels with WCAG guidelines.

Launch

After ten months of focused development, Fire Engine RED launched the MVP of its higher education CRM platform to a select group of early adopters for beta testing. The initial response was mostly positive, with users highlighting benefits and giving us valuable feedback about areas for improvement.

Results

The MVP launch validated Fire Engine RED's product concept and allowed the company to invest confidently in further expanding development. The team used the data gathered from early adopters to improve the product roadmap and refine user experiences.

Early Customer Reactions

"Fireworks was not retrofitted from another tech arena... this meant it spoke our language. It was and is a tremendous value."
–Chris Beiswanger, Director of Admissions, University of Colorado Colorado Springs

"Fireworks has saved us hours of time by automating our communication flow... We are now able to devote more time to students and getting results. Our applications were up by 6.6% and our admits were up by 14.6%"
–Mark Meydam, Director, Enrollment Operations and Technology, University of Wisconsin-River Falls

"We chose Fireworks for its intuitive design, easy functionality, and affordable cost."
–Marc Skjervem, Director of Student and Career Advancement Services, University of Wisconsin-River Falls

Conclusion

The internal startup team at Fire Engine RED successfully used an Agile and user-centered design approach to launch an MVP SaaS CRM product that addressed a gap in the higher education marketing services market. Focusing on UX design, user research, and applying WCAG accessibility standards, Fire Engine RED created a highly usable, inclusive product. The MVP's success demonstrated market demand and set the stage for future iterations to refine the product and expand features to serve higher education institutions better.

My Role

2019 - Director of User Experience
2018 - Director of User Experience
2017 - User Experience Lead
2016 - Sr. Interaction Designer
2015 - Interaction Designer
2014 - Interaction Designer
2013 - Interaction Designer

Timeline

Six Years

Skills

• Interaction Design
• User Experience Design
• Design Systems
• Full Stack Development
• Product Design
• Product/User Research
• Process Change Management
• Agile/Lean Project Management
• Technical/Creative Team Leadership
• Recruiting and Onboarding
• WCAG Accessibility
• Branding

Tooling

• LAMP - Linux, Apache, MySQL, PHP (Laravel)
• HTML, CSS (SCSS), Javascript (Handlebars)
• Adobe Creative Suite (XD, Photoshop, Illustrator, InDesign)
• Atlassian Suite (JIRA, Confluence)
• Microsoft O365
  • Excel
  • Powerpoint
• Google Sheets
• Google Slides

I was the content architecture lead on a process change team of five. We were tasked with streamlining content management for Ford.com and Shop.Ford.com. With sophisticated data modeling, schema.org API utilization, and workflow optimization, we realized a seven-figure annual savings on operating costs and an improvement in both content quality and consistency.

Situation

Challenge #1

Ford Motors offers a tremendous variety of products at different price points and configurations, across many markets.

Challenge #2

Supporting content operations at Ford.com and Shop.Ford.com requires handling a variety of data sources and formats which are ingested, sanitized, normalized, and then made retrievable. 

Risks & Opportunities

• Disjointed and inconsistent content delivery systems reduce positive business outcomes.
• Supporting numerous data sources can lead to redundancies and data entry/translation errors. 
• Ford Motors is legally mandated to present individualized claims and disclosures on a per-product and per-market basis for the wide variety of geographic locations in which it operates.

Tasks & Goals

Primary Task

Develop a new content model that could support current operations on Ford.com and Shop.Ford.com in a scalable and extensible way for future products and initiatives. 

Secondary Tasks

• Revamp existing internal tooling
• Define new workflows
• Create documentation to support the process changes

Goals

An e-commerce platform that could efficiently ingest content data in the various formats needed and make it easily retrievable.

• Enhance the customer experience on the e-commerce platform
• Improve messaging consistency where needed while supporting granular marketing strategies
• Improve efficiencies in content operations

Action

Assessment & Planning

1. Audit existing marketing content and data structures.
2. Identify key stakeholders, including marketing, production engineering, IT, and data analytics teams, to gather requirements and insights.
3. Define the objectives and scope of the new content model project.

Data Model Design & Development

Collaborate with the IT and data analytics teams to design a new marketing content data model. The model incorporated metadata, taxonomies, and content hierarchies to facilitate easy content management and retrieval.

Implementation

1. Migrate existing marketing content into the new data model, ensuring minimal disruption to ongoing campaigns.
2. Develop and deploy automated tools for content tagging and metadata management.
3. Train marketing and content teams on the new data model, processes, and tools to ensure smooth adoption.

Testing & Iteration

1. Test to identify and resolve any issues with the new data model and associated process change.
2. Gather feedback from users and stakeholders and iterate.
3. Implement analytics tools to monitor content performance and user engagement.

Results

Efficiency Gains: Streamlined processes for creating, organizing, and retrieving marketing content reduced production spending by $500,000.

“Wow! This is going to save us five-hundred thousand dollars THIS QUARTER.”

-Project Director, Content Systems

Better Personalization: Enabled personalized marketing campaigns to increase user engagement and conversion rates.

Improved Consistency Across Touch Points: Ensured consistent messaging and branding across multiple e-commerce touchpoints, boosting business outcomes.

Scalability: Established a scalable data model and associated workflows and documentation to support future growth and integration with emerging technologies.

My Role

Content Architecture Lead

Timeline

Nine Months

Skills

• Data Modeling
• Automated Workflow Development
• Process Change Management
• User Experience Design
• Market Research
• Systems Design
• Multichannel Marketing
• Content Marketing

Tooling

• Adobe Experience Manager (AEM)
• Atlassian Confluence Platform
• Microsoft O365
  • Powerpoint
  • Excel
• Schema.org API
• JSON
• JAVA
• XML
• Adobe Digital Asset Manager (ADAM)

There are many fine articles floating around about fitting traditional UX design into an Agile mold. They tend to cover the principles well, but what I’ve found lacking is content that shows in a practical manner how to create the assets and artifacts often expected of a User Experience designer on an Agile development team. So let’s do that…

There are many assets and artifacts that can meet our definition, but I’m going to pick something very specific to keep the scope of this article manageable: a user flow for a software login feature. This entire user flow is what we want to build, eventually. But how do we get there?

Scrum software development works by building in a series of productivity sprints (usually 1–3 weeks). In any single sprint you set a small reasonable expectation for a feature that you can release to users at the end of a sprint and then execute. This is often referred to as a minimum viable product (MVP).

This means that for each sprint the UX Designer needs to define small, releasable, end-to-end user experience. This can be built upon in turn as the team continually releases the software and receives feedback.

So let’s actually define the MVP of our login system.

It has to keep some people out and let some people in. The minimum UX we could ship would be a form on a login page that validates user credentialsand redirects them somewhere OR reloads the page and shows them an error message.

There are features missing. We haven’t addressed creating a user or resetting a password, for instance. Early on in a product/feature life cycle we’re doing a lot of critical stuff manually, or not at all, but that’s expected. This is small; we can build it fast and show it to the stakeholders in our project. This will get us our first critical feedback.

Feedback on a login form!?

Absolutely.

This is where you’ll start getting feedback on your UI, the copywriting style, the responsiveness in terms of both speed and platform, the way the team works together, etc... It’s all going to be small potatoes, but that’s the point. What sort of team couldn’t handle potatoes this size?

When my dad taught me to shoot an arrow, he had me take my first shot standing THREE FEET from the target. Once I had drawn my bow, the only way to miss would be if it had spontaneously caught fire or I was hit by lightning (and even then I still might have hit the target just by releasing in preparation to run away screaming).

So I hit the target. And then I backed up a little, and I hit it again. And again. And again…

Small stuff is easy to define, easy to design, easy to build, easy to manage, and easy to ship. And the big stuff is made up entirely of small stuff. Once you get your team in this mindset, you can build almost anything.Prioritization becomes the hard part, not implementation.

So, what’s next? Manually resetting (and setting) passwords for our users isn’t going to scale very well. It will become a huge problem as soon as we achieve any sort of success with our product. What does the end-to-end version of that workflow look like to our users?

Now we’re talking. We’ve added several things here that make up a complete end-to-end password reset experience.

1. We create a link from the login page to the password reset page.
2. The reset page has a web form to submit an email.
3. An email validator runs in the background. As a security measure, we’re not going to show any kind of error if they enter an email not associated with an account. We don’t want them fishing for live account emails.
4. On submit they’re sent to a confirmation page saying to check their email for the reset link.
5. If the email submitted validates, a system email module will send the “Reset your password” email.
6. Clicking a link in the email leads to the landing page. It contains a password set form with a validator looking for the security token associated with the email address.
7. We also start handling errors gracefully with a 403 error page.

Now, that is a lot more than our feature MVP. Depending on your team and your tech stack, more may still be small potatoes. If it isn’t, you can always break it down further. For instance you could build steps 1–4 above and have the email module send something to a developer telling them to manually reset it.

Most importantly we have v2 of our feature which gets us more feedback, so we’ll be better at building our thing during the next sprint. Don’t try to be perfect; it won’t happen. Try to be better. Better is small potatoes compared to perfect.

So now what? We’re handling accounts pretty decently once they’re created. Let’s automate creating the user accounts so we can quickly add new ones to our system without bothering the developers that are currently entering them in the database by hand.

So what’s the end-to-end experience for the user?

1. Creating a user.
2. Viewing a new user profile.
3. In the background, our email module built last sprint sends a welcome email to our new user with a “Set password” link. (Love using stuff we already built!)
4. That link works with our existing (yay) “Set password” page.
5. Once they set a password, use the existing (yay) redirect logic to take them to the login page.

Now we’re talking! This is great. Our software developers can stop hand-entering credentials into the database and focus more on features. Features that are nice to have. Such as what if someone has been in the system before and tries to go back to that page, but they’re logged out? Let’s redirect them to where they wanted to go after login.

Release notes, “Users logging in will be redirected to their desired page.” Isn’t that nice? Now we’ve moved beyond needs and we’re knocking out wants. Fantastic. Go get your feedback and decide what to do next.

Now that we have some basic security in place…

1. Maybe we want to add two-factor authentication to boost our security.
2. Or social media login to increase sign up conversions.
3. Or captcha to prevent spam, and so on…

Or maybe this is good enough for now and we start looking at other features. That’s the whole beauty of the Agile thing. You get to incorporate feedback and reassess your priorities often, so you never get trapped.

That’s a practical look at creating an application user flow on an Agile development team. A final note…

Just because you’re working in distinct end-to-end user experience chunks, you must not confine yourself to only thinking that way. For instance, I had planned the entire user flow at the top of this document before breaking it up into small digestible chunks. The danger is that the further out you plan, the more risk you’re taking that feedback will change your direction and you’ll have to rework your plans.

The amount of planning ahead you can get away with before the risk builds up too much and renders your planning inefficient depends entirely on context. It could be a single sprint, or it could be months. The more comfortable you are with your team and the more knowledgeable you are about your product and market, the further out you’ll be able to plan your user experiences effectively before breaking them down.

Lastly: the tools don’t matter much to the process. But I used the Mac OS Sketch App to build this particular wireframe. And I started with this free user flow template for Sketch that I found on Dribbble.

This piece was last updated October, 2024. It was originally published by Wade Meredith on Medium in October, 2017.

I worked as the product and account manager on a team of five, creating a bespoke crowdfunding platform for The Global Orphan Project. We developed a tightly integrated custom theme and custom plugin running on WordPress for maximum cost efficiency and security. The platform generated a 1121% ROI over five years.

Situation

The Global Orphan Project (GOProject) needed a bespoke crowdfunding platform to support its international service initiatives of building self-sustaining communities to feed, house, and educate orphans. As a not-for-profit organization, GOProject faced budget constraints and limited technological expertise. They approached Voltage Creative, a digital agency with a long-standing relationship, to help bring their vision to life.

Tasks & Goals

The primary task was to develop a crowdfunding platform that met the specific needs of GOProject, balancing functionality with budgetary limitations.

1. Define Requirements: Work with stakeholders to discover and outline requirements for essential features versus optional ones to establish a minimum viable product (MVP).
2. Define Sub-Brand Integration: Create a cohesive design language and style guide that aligns with GOProject's existing branding while developing a sub-brand called "MyGO."
3. Development: Build, deploy, and support a platform using modified off-the-shelf CMS software and custom WordPress plugins to ensure necessary functionalities, including user account creation, event management, and secure payment processing.
4. Meet the timeline: 12 months.
5. Meet the budget budget: Under $75,000

Action

Collaborative Requirement Gathering

Leveraging the trust and rapport between GOProject and Voltage Creative, we conducted workshops to identify and prioritize features. We created a clear roadmap for the project's progress.

Proof of Concept Development

The team quickly developed proofs of concept using customized WordPress plugins in PHP. This approach minimized risks associated with third-party software and provided the necessary security for sensitive financial transactions.

Design and Branding

Working closely with GOProject, we modified their established brand guidelines, creating the MyGO sub-brand. The design process was iterative, allowing for real-time feedback and adjustments, which resulted in a user-friendly interface seamlessly integrated into the existing GOProject web presence.

Development

We created the custom MyGO WordPress theme and plugin for the WordPress platform with a team of three developers. The plugin utilized the Authorize.net API for payment processing.

Deployment and Training

We did a soft launch internally alongside site administration training for GOProject staff. Once satisfied with the results, we launched it alongside an integrated marketing campaign.

Continuous Communication

Regular check-ins and updates ensured alignment with GOProject's vision, allowing for agile responses to any emerging challenges or changes in direction.

Results

The MyGO crowdfunding platform launched on-time and on-budget in 2013. A twelve-month post-launch audit indicated a 299% return on investment (ROI.) A five-year audit indicated a 1121% ROI. The platform expanded the GOProject's fundraising capabilities, increased donor engagement, and expanded global outreach efforts. The successful collaboration strengthened the long-term relationship between The Global Orphan Project and Voltage Creative, paving the way for future successes.

My Role

Product Management, Account Management

Timeline

Nine Months

Skills

• User Experience Design
• Product Design
• User Research
• Requirements Gathering
• Proposal Development
• Technical Documentation
• Systems Design
• Wireframing
• Web Design
• Web Development
• Technical Training
• Branding

Tooling

• Adobe Creative Suite
• WordPress
• Authorize.net API
• LAMP stack (Linux, Apache, MySQL, PHP)
• HTML, CSS, Javascript

This was purportedly said by Bruce Ediger or Steve Jobs or perhaps someone else… It doesn’t really matter, because it’s nonsense.

Breastfeeding is an (often painfully) taught and learned skill. I strongly suspect that the originator of this design trope had little experience with angry infants or exhausted mothers. If humans need help surviving literally the simplest of tasks… what are the chances they can intuit how to manage their photo sharing preferences in the cloud?

Zero. The chances are zero.

As designers and engineers seeking to empower people through technology, We must build robust systems that enable them to understand and utilize that technology. Otherwise what is the point?

Expanding circles of support — The level of support as well as the cost and complexity increases as we approach the edge of a proposed software support ecosystem.

A System of Support

Users experience many stages of considering, acquiring, questioning and understanding a product. These range from newbies onboarding to seasoned power users digging through complex API documentation. A robust support system should be able to speak to both of these user types and everything in between in a helpful manner.

The above graphic is a conceptual support ecosystem. Let’s break down its parts and see how they might work together. (Our example system is for discussion’s sake. Support systems are as varied in size and complexity as software. The only sure thing is the circle in the center–and even that is assuming we’re not just building a CLI.)

Each level has a corresponding expense and complexity. Generally speaking, the further we move away from the center the more expensive and complex the systems are.

Consideration should be paid to how each type of help relates to the other in the critical task of supporting users as they accomplish their goals. The design of the system in a holistic manner, consistency of language and interaction design, and ease of movement between, layers are what will make it a valuable part of our product, rather than a confusing mish-mash of project artifacts.

Graphic User Interface

Moving beyond the command line, graphic user interfaces (GUI’s) are the first level of help offered the user in understanding how to access and utilize the functionality our software provides. (In the case of dashboards and business intellegence tools much of the interface may be the functionality the software provides.)

A GUI is itself a collection of affordances or helpful envrionmental cues that reveal to the user how their surroundings may be manipulated. Space and contrast should be effectively utilized to communicate hierarchy and order of function. Color and motion can be used to enhance this hierarchy (but require a disciplined hand to keep from simply distracting). Layouts should guide the eye. Interactive elements like links and buttons should be inviting and responsive.

Perhaps most importantly, direct communication is accomplished in the GUI using signifiers such as written copy and iconography. Elements should be labeled appropriately for our target market. Language and tone should be consistent throughout. Copy should strike a balance between verbosity and terseness. And it goes without saying that copy editing for typos and grammatical errors should be made a priority.

The GUI is ground zero for helping users understand what our software can do for them. Getting that right is job one. It should be inviting and meet expectations set by the branding, marketing, acquisition, training, and onboarding processes.

It’s worth addressing here the persistent myth I’ve encountered in my career that if we do this GUI part well enough, we can forget all the other stuff. I think this is nonsense when it comes to software of any sort of power and complexity. And I think it has persisted because it would be so nice if it were true…

The kernel of truth is that the GUI is just part of the bigger help system. More heavy lifting by the GUI means other areas can probably do less, but balance is important. An interface that explains everything all the time will be cluttered and annoying. It will not be appealing during sales and marketing and power users will hate it. Conversely, an interface that is too sparse may demo well and appeal to power users, but have a learning curve that makes getting new users up to speed an impossibility. This is why it’s important to look at the user experience of our software help system holistically.

Embedded Help

Here we have the first humbling admonition that we may not actually be able to design software that anyone can pick up and use–embedded help. The most popular form of this at the moment seems to be the onboarding dialogue or splash screen. As shown in the graphic above, this is usually a short introductory set of images, GIFs, or videos may walk a first time user through the basics of the application.

Embedded help also often takes the form of GUI augmentation such as an overlay with helpful notes or tooltips. These are often hidden but can be triggered automatically when a user first encounters an interface or perhaps on demand if they turn on a “help mode”. Or perhaps help mode is enabled by default and a user can turn it off.

Building and maintaining something like this needn’t require going too far above and beyond the level of effort needed to create our GUI in the first place. There is the design and copy to consider, but embedded help is likely contained in the same technology stack as our GUI and can be built and released using the same processes and resources since it is an extension of existing elements.

Documentation

People who make software love documentation! Just kidding; no one likes documentation. Except users. They really really like it, if it’s done right.

The problem with documentation is now we’re definitely moving to the outside of our circle of support graphic. Things are getting harder and more expensive.

Challenges to helpful documentation are rife and well known.

• It needs to be written by someone who understands the software.
• It needs to be written by someone who understands the market.
• But perhaps most confounding: Documentation needs to be written in a manner that is engaging, but technically accurate and helpful and not patronizing.

Bless the software companies with well written documentation. They are few.

Let’s say we do make the investment in time, money, and resources and get our docs in a good spot. The good news is great documentation can be beneficial in different ways, so we reap our investment over and over.

Firstly, we should link to our help docs from within the application itself. The best way to do this would be contextually appropriate deep links directly to the helpful topics. This could come in the form of “Would you like to know more?” links at the end of our embedded tooltips. Or perhaps a suggested reading link on error pages that is specific to the error type or a documentation search box embedded on more general errors.

Documentation can also be written with an eye toward training and on-boarding. Pieces of documentation could be reused to create our splash screens or in hands-on training sessions with little modification.

Good software documentation can also be the star of content marketing campaigns and sales pitches. Leveraging a robust documentation site for SEO purposes is a slam dunk from a topical content standpoint. Good docs should be speaking directly to how to solve the market’s problems on every page.

Help Desk

This is a big topic that I am only going to touch on tangentially. And by that I mean I’ll only speak about help desk support in the ways that it touches and influences our bigger software support system. The nuance and logistics of the support itself is far beyond the scope of this article.

So the final tier of our circle is without a doubt the most complex and most expensive as it involves real people talking to each other. This requires hiring, training, staff, facilities, communication logistics, and more. (Or at the very least outsourcing all of the above–its own subtle art to get right.) But how do we incorporate it into our existing structure so that users can move between the tiers?

In our exemplary support structure users are to submit help desk tickets into a queue via a form and have client support representatives respond to them in turn. Where are the entry points into this tier of support?

One entry point could be on any error pages within our software. This could be as simple as a link or as robust as an embedded form within the page itself. This should have no problem living alongside helpful error messaging copy, any links to relevant documentation, or a documentation search form.

Another help desk promotion point could be on the home page of our marketing website. If my company sells a piece of software, there is likely a marketing site for that software. That site’s support and contact pages are also appropriate places to have links for contacting the help desk.

Lastly, let’s say we’re really proud of our support and have invested significant resources there. Perhaps it’s a competitive advantage and we want users to be able to jump straight to it whenever possible. We could add a subtle corner stripe to our software during business hours that says “Support is in!” with a link to a dedicated help desk page. (Note: this could be annoying for power users. Make sure to offer a way to dismiss it.)

Things Left Unsaid (Quite a Bit)

There are all kinds of support options that I didn’t even mention like chat bots, chat humans, webinars, service status pages, social media channels, and more. The service support industry is huge and each software product in each market will be deserving of some mix of support systems that work together in harmony to help the user empower themselves with software.

Final Word

We as designers and engineers must be wary of the ego trap that we can build or design software that is so grand, so useful, so good that humans will be able to use it without help. Dropping something on the user without introduction or explanation for a variety of understandings is a recipe for disaster or worse: a recipe for nothing at all.

Most users that cannot figure out our software will not tell us; they just won’t use it. They will think it is broken. They will think it is bad. They will not empower themselves with the technology we’ve worked so hard to provide. Not without help.

This piece was last updated October, 2024. It was originally published by Wade Meredith on Medium in March, 2018.

Darena Solutions, a software company offering health IT solutions, had a successful product in the market and wanted to leverage existing brand equity to help new products about to launch. The existing brand standards were not established well, making extensibility difficult. Further, the successful existing product brand did not match their corporate brand, creating friction around any association of trust and quality with their existing happy customers.

The executive team recognized the need for cohesive branding between their corporate identity and all product lines. I advised them to create a comprehensive style guide to ensure consistency and an extensible branding system that gave them flexibility and guidance when adding product lines.

Research

I researched competing brands and reviewed notes from internal stakeholder interviews, identifying the key attributes and values that should define the Darena Solutions brand family.

Define Brand Elements

• Mission and Values: Clearly articulating the company's mission and core values.
• Visual Identity: Standards for logos, color palettes, typography, imagery, and iconography.
• Extensibility: Templates and a framework for efficiently creating new cohesive sub-brands in the future.

Create an Extensible Branding System

I created detailed instructions on applying brand elements consistently across multiple touch points and product offerings.

Bringing It Together

The key deliverable was a corporate style guide that worked in digital and print formats. Delivered alongside the style guide was an asset library with brand assets in various sizes, file formats, colors, and layouts. Also included were a PowerPoint template, letterhead, and a corporate email signature template.

Results

• Improved efficiencies in all future marketing investment
• Transferable brand equity and trust between the primary corporate identity and all product lines
• Better consistency, quality, and cohesion of all brands
• Faster product enablement times for emerging products going to market

My Role

Branding Strategy Consultant

Timeline

Three Months

Skills

• Branding
• Logo Design
• Copywriting
• Graphic Design
• Digital Design
• Design Systems
• Market Research
• Multichannel Marketing
• Digital Marketing
• Marketing Strategy

Tooling

• Adobe Creative Cloud
  • Illustrator
  • InDesign
  • Photoshop
  • Acrobat
• Figma
• Google Workspace
• Microsoft O365
• HTML

Bankle is a faux-branded mobile banking concept created for an undisclosed client on contract in 2019. This is a simple project. I was provided with a minimal list of requirements and asked to create a one page brand sheet, a number of user flows, and interface mockups. See the results in the (obnoxiously large) image below.

Mercury CSS is a tiny classless stylesheet built for speed. It hooks directly into HTML elements adding minimal modern styling focused on good typography, fast load times, accessibility, and responsive design. The stylesheet is 4kb unminifed.

Mercury CSS is a good place to start and build upon for most modern web development. And it's a pretty good place to stop if you literally only care about legibility and speed.

Great Typography

As a classless CSS stylesheet, Mercury CSS is primarily concerned with great typography. Great in the sense that it is easy to read and you probably won't notice much else about it, not great in the sense that it will win an AWWWARD.

Sacred geometry ascribes symbolic and sacred meanings to specific geometric shapes and proportions. This has ancient roots and takes many compelling forms in Buddhism, Chinese spiritual traditions, Islam, Hinduism, and Christianity. Plutarch attributed the belief to Plato, writing, "Plato said God geometrizes continually." The science doesn't work, of course, but it is beautiful.

“This is prophesy, not prediction. This is the I Ching; it's beautiful, but it's not scientific.” –Jin Cheng, The Three Body Problem

Platonic Solids

One of my favorite forms of Sacred Geometry involves the platonic solids-tetrahedron, cube, octahedron, dodecahedron, and icosahedron. Their namesake, Plato, associated the first four geometric shapes with one of the four classic elements: fire, earth, air, and water. From wikipedia:

Earth was associated with the cube, air with the octahedron, water with the icosahedron, and fire with the tetrahedron. Of the fifth Platonic solid, the dodecahedron, Plato obscurely remarked, "...the god used [it] for arranging the constellations on the whole heaven". Aristotle added a fifth element, aither (aether in Latin, "ether" in English) and postulated that the heavens were made of this element, but he had no interest in matching it with Plato's fifth solid.

Reading about these ancient great thinkers and how their reach exceeded their grasp was inspiring. I embarked on creating a series of limited-run screen prints and complementary digital art.

Full-color digital art representations were made using vector graphics of the platonic solids and stock images sourced from Unsplash. Each of these must be converted to single-color images for screen printing.

Screen Printing

For the uninitiated, in the traditional screen printing process, each individual color requires the creation of a new physical screen through which the ink is pressed onto a medium, creating the "print." Using even a few colors becomes prohibitively expensive in small-scale production.

This constraint forced me to expand my creative skills, which was a big part of the appeal of this project. I still often use halftone bitmaps in my design projects. See Seek HiFi. The vibe is appealing to me. Halftone screen effects are a novel way to reduce file sizes while preserving enough detail for viewers to fill in the blanks as their minds apply gestalt principles automatically.

To preserve the depth and texture of my elemental prism digital art, I used the original concept art and generated halftone screen images as black-and-white bitmap files. Applying a single color to each, I was able to generate these mock-ups.

Once I had satisfactory mock-ups, I worked with Dan Padavic, the owner of Vahalla Studios in Kansas City. Vahalla is an expert in flat stock screen printing and letterpress. Dan has probably forgotten more about traditional printing methods than I will ever know. He was an amazing partner in this project and worked hard to get everything exactly how I wanted it.

Dan helped me with file formats, and we went through dozens of test prints and colors. As a creative professional, I know how taxing it can be to work with a client on your shoulder, and they had me in the shop pulling stock and mixing colors. I could not have asked for more.

I ended up with 100 numbered 18x24 inch prints of each element. These were sold online in a SquareSpace store under a "Platonic Press" brand I created. I just about broke even. I sold other prints under this label, but that's a different story. I held back a few sets for myself. One is hanging in my dining room.

Digital Art

During this time, I also made digital art to accompany the screen prints. Bits are cheaper than ink, paper, machine time, and labor. Why not?

The images in these galleries are full-size and free to download for personal use.

This project had me exploring new mediums and stretching my creative legs. I also made a tremendous local connection with a true expert craftsman. Finally, in my research, I learned something new about human history and our amazing drive to assign meaning to the universe and explain the unexplainable. Whether it's a story, principle, or set of laws that describe our world, no matter how flawed, we all just gotta make stuff.

"Up Into BIG Air" is an information design love letter to two fascinating worlds of which I have little mastery but plenty of interest: mountaineering and cartography. Skip to the downloads at the bottom.

I was born in the heart of (probably) the world's flattest place: the American Midwest. In my teens and twenties, I traveled to Colorado dozens of times. Most of my Colorado road trips were summer trips focused on hiking and stargazing.

After climbing my first fourteener, a mountain with a summit of 14,000 feet elevation or higher, I was hooked on the mountains. I spent the first summer after that reading and watching everything I could about mountaineering, from nonfiction novels and TV documentaries to action movies. Mountaineering is amazing! So, of course, I had to make something. I always have to make something!

"Up Into BIG Air" is a collection of stylized topographical maps of 12 of the world's most famous–or infamous, in the case of the Ana Purna Massif or K2–mountains. These maps are available as 4K digital desktops, mobile wallpapers, and high-quality PDF or PNG files suitable for printing at sizes up to 18 x 24 inches.

This project was created using OpenTopoMaps and a combination of graphic design tools, such as Sketch, Adobe Photoshop, and Adobe InDesign.

The Poster

Digital Wallpapers

Downloads

"Up Into BIG Air" was a very personal and fun project for me. I hope you enjoy it!