10 things every enterprise should be doing to improve digital customer experience. by Kevin Oleary

I see enterprise digital user experience as the sum of all interactions between any part of your organization and one person. Users will ‘personify’ your company and make emotional judgments based on their experience, and that may include things you consider peripheral. A CEO who had a bad experience using Amazon Prime is not going to set that aside when deciding whether to host with AWS (though she may claim to), it all rolls up into a single relationship with Amazon.

I’m not just talking about tech companies, this applies to any enterprise. Whether your products and services are digital or physical, they should be accessible to the consumer technology users expect. To many of you, this will not be news. If so carry on. If it is news, and you want to get ahead of it, here are some practices you can introduce now to build a user experience based on trust and respect.

1. Single Sign-On

Any internal or external user of a digital service should only have to sign in once to access services they are entitled to. So many enterprises now do this that if you don’t, it just looks sloppy.

2. Self Service Account Management

Every customer, large or small, should be able to manage most aspects of their account in the cloud, including paying bills, managing services, or controlling privacy and access. Sure, some customers prefer talking to a person, but any process that requires them to adds friction and degrades the relationship.

3. Seamless Integration

If a customer uses more than one of your services, every service should be “aware” of the others, and already have relevant data available when the user needs it. If an app asks a user to input data you already have in another app, you are not respecting your users time.

4. Internationalization/Localization

Users, anywhere you do business should automatically see your interfaces, not just in their own language (eg. French), but their own dialect (Canadian French), in a system that is aware of date and time, cultural norms, as well as local legal rights and responsibilities (eg. GDPR). If users get the mistaken impression you might be based in their own country, you’re doing it right.

5. Personal Privacy

If someone’s personal information is on your servers (yes, HIPPA and PCI data, but really just any information about a person), you need to tell them what information you have, and how to remove it, preferably in one click. Post Cambridge Analytica it doesn’t make sense not to do this and if you need to implement GDPR, why take on the burden of maintaining two systems? Just employ GDPR everywhere.

6. User-Centric Security

By design, digital services should maintain the bare minimum of information essential to a task, grant users access to only tasks relevant to their role, and bind changes in user status or role to the permissions. Don’t assume an HR person will go around and remove that former employee’s access to everything. They won’t. Another thing that you might not be considering is the erosion of trust when information is too readily available. Users may be asking themselves “If I can view sensitive information about [insert third party person or company] what information of mine can they view?”.

7. Proactive Communication 

If something bad happens that impacts a customer, shareholder, or any stakeholder, your system should be set up to them right away, via whatever channel is the most immediate. Don’t provide an urgent security update at the bottom of an email newsletter if you can text them. Customers will not be annoyed if it’s truly urgent.

8. Responsive, Accessible Design

Every digital product or service you offer should be accessible via any device that has a browser, with an equivalent experience, including on devices that employ assistive technology even if it’s not mandated by ADA (which for government contractors, it is). The service you design and build first should also be the one that’s indispensable (hint, it’s mobile).

9. Enterprise-wide Design Systems

Part of maintaining a relationship is consistency. Every user should immediately know when they are touching part of your organization. That can’t happen unless you have a consistent brand experience at every touch point. To scale that you need a design system. I’m not talking about a brand standards manual or a style guide website; those impose a burden of effort that kills adoption. What will get adopted is a regularly updated easy-to-install plug in (eg. an NPM module), or even better, a framework-agnostic design API (eg. design tokens). Either way, if you want it to flourish it should be maintained by a dedicated team as a service to the enterprise, not as everyone’s responsibility or one person’s side-project.

10. Continuous User Testing

One kind of data you should be gathering more of (anonymously) is application user metrics. But here, try to only gather data you can immediately use to improve the experience. If you’re aggregating key session data that reveals where users spend most of their time and feeding that directly back into your Jira backlog you’re doing it right. If you are logging umpteen data points from many sources and just sitting on it in thinking someday you might try to use machine learning to extract some insights, it's unlikely you will ever get value from that. 

If there’s anything you think I’ve missed please let me know. But keep in mind I’m not talking about every possible digital innovation, just the ones that directly benefit users. And if there’s a single thought to remember above all: if you focus is on how you can serve users, not what you can get from them, success will follow.

The end of the site as we know it by Kevin Oleary

The corner of the web I work on is Drupal, the open-source CMS that powers 2% of the entire web measured by sites (much much more if you measure by page-views). Recently we launched Drupal 8, a huge milestone for us. It brought fully responsive design, object oriented code, built in REST, configuration management and a host of other improvements. At the same time it opened up so many doors to functionality that had formerly been hard to come by. The explosion of new options is now starting to challenge our fundamental assumptions about how Drupal could or should be used. The time is right to begin to re-think some of these ideas, and as we do I think we might uncover ideas that could be adopted across the web.

It’s not about the language

The world has changed since the beginning of Drupal when PHP was the upstart. Javascript is the new king of the hill, REST APIs are now the primary protocol of data exchange, developers are moving from monoliths to microservices, and everyone is focussing more on the end-user experience.

Businesses don’t adopt new technologies because they are “cool”, they adopt them because they address immediate, painful problems. Yes, we need to take a hard look at the limitations of PHP and the benefits of client-side frameworks as Dries (founder and project lead of Drupal) has suggested. But we also need to take a deeper look at what these technologies are for and perhaps challenge some of our fundamental assumptions.Identifying the problems

Over the years we’ve dealt with many big customer issues at Acquia. I've taken a swag at boiling these down to the biggest problems customers deal with most often.

  1. Retooling cost:
    I can’t change the design of a site for > six figures.

  2. High skill bar:
    My designers can’t make updates without a developer

  3. Poor usability:
    My authors refuse to write in the CMS so I have to copy paste then fix or rewrite the markup

  4. Single points of failure:
    If my 400 page site goes down I’m #&%$ed

  5. Deep tech debt / shallow talent pool:
    I have 200 Drupal codebases and 20 Drupal developers

Most of the pain points above can be laid at the feet of overloaded monolithic sites. Retooling, eg, updating the CMS or the site design, for example, often involves mostly theming work because themes in Drupal are global and, through the evolution of Drupal 7, became increasingly complex and bloated. Staying with themes for a second, there's no easy way for designers to create Drupal themes without a developer, and again this is related to their size and complexity. If themes were more granular and tied to, say, components, it would be far easier to make individual presentation elements configurable. Looking at usability, again we run up against the sheer scope of UX issues open across a large and complex CMS, many of which involve site management and not the content authoring issues that impact a far larger number of users. 

As far as a single point of failure is concerned, we already see many Enterprises using multi-sites like Acquia's Site Factory and other federated solutions to mitigate risk and speed up development, but nobody has yet developed a good solution for sharing configuration or brand styles. The last point, technical debt and shallow talent pool, can't be entirely laid at the feet of monolithic sites, but it would certainly be mitigated systems that more broadly share content, configuration and presentation. 

I'm not the first to point the problems of monolithic sites but the bulk of the solutions I hear today—like stripped down, lightweight content APIs or flat-file CMSs—focus on the "monolithic" part not the "site" part. Systems like Drupal have grown more complex to handle more complex needs and stripping away that complexity is not the answer. In my view the problem is the site. If you think for a second it’s hard to even remember the original business case around having “sites” in the first place, apart from their origin in structuring sites as files in a single document root directory. It's time we consider abandoning them.

Keep it lean

If I were to re-invent the CMS today this would be my lean hypothesis:

The biggest obstacle to delivering maintainable content rapidly, with low overhead, and creative freedom, is the outmoded concept of the “site”. By moving content management out of individual sites and up to the level of the entire organization, we liberate content creators and enable them to meet those goals while at the same time introducing massive economies of scale.

The age of the page

So if it’s not sites then what? The next step down from the site is the page. Mobile-first, responsive design has already made pages more lean and focussed and we are unlikely to see a return to complicated layouts with many panes and facets. We are already seeing the rise of “Landing Page Builder” apps and services. This focus on the page makes sense. It’s the standard serving size of content on the web, and it can live at a single URL. Of course there are already single page apps, but my focus, and Drupal’s sweet spot is delivering content, not tools.

If we do re-focus on the "content" part of content management, perhaps the next generation is content modeling tool and API plus a render pipeline that can serve atomic “chunks” of content to any number of different sites. Front-end developers might question the need for any render at all, but remember “Having the freedom to code my front-end in my framework of choice” is not one of our top five problems. If marketers can simply feed rendered HTML including their global brand classes to any site in their organization without having to involve a developer, that’s a huge win.

Once we abandon the site and all the baggage that goes with it and let each page be it's own independent "node" managing content and presentation becomes much simpler and a lot of the duplication that currently exists falls away. But of course this raises many questions about how you would manage things like a global information architecture or content model, or how you would handle global authentication or error codes or any number of other site-specific functions that would need to become organization-wide services, but the point of this post is to open up that discussion, not to answer all the questions. Will CMSs be the systems that tie all the micro-services together? Maybe, maybe not. I'm inclined to think that another system, more closely tied to platform architecture would do the job better, and that over time all that organizing and routing of pages becomes "plumbing" enabling content creators to simply create and publish pages to wherever they want.