Will AI eat your UX design job? by Kevin Oleary


I was recently asked on Quora whether UX design jobs would be replaced by AI. the following is an extended version of my answer.

There’s no question that in the coming years software and automation, aided by in many cases by artificial intelligence, will render many jobs obsolete (though many argue that as many new kinds of work will arise). Out of all the possible jobs under threat, however, UX design is one of the least likely to be easily replaced.

Let’s look at an analogous change I lived through; the ‘desktop publishing’ revolution. When I was just out of high school my dad worked in advertising. At that time, to produce an ad in a magazine for, say, pancake mix, it took an account executive, an art director, a copywriter, a photographer and assistant, a food stylist, a graphic designer, an illustrator, a typesetter, a copy editor, a mechanical artist, a stat camera operator, a color separator, two film processors (one for the photo shoot and one for the photostats), a photo retoucher, and a courier to shuttle all this stuff back and forth across town between their various offices (that was my job).

That’s 18 people. Barely a decade later it took four; the account exec, art director (now on a Mac), copywriter, and photographer. Today they’re more likely to use a stock photo and less likely to use a writer, so it’s down to two. But notice who’s left, the essential business contact and the art director, now doing most of the 18 jobs with the help of a collection of software and services. In the midst of all this change I can vividly recall people in the design industry wringing their hands over the ‘death of design’ and predicting that we would soon all be replaced. That didn’t happen. There are more designers today than ever, and a greater variety of roles as well.

Print magazine cover ca. 1991. (Translation: "This is not a designer")

Print magazine cover ca. 1991. (Translation: "This is not a designer")

But stepping back, why did the art-director survive but not the mechanical artist? The answer is that their task was—as the name suggests—‘mechanical’, If we define mechanical as ‘a linear process governed by a fixed set of rules that can be repeated automatically without thought’, you can see that the other extinct roles also fit the bill. The mechanical artists job was to take a rough comp produced by an art director, collect all of the assets; type, photos, illustrations etc. and assemble them exactly as dictated by the comp. Linear, governed by rules, automatic. In essence the more ‘mechanical’ a task is the easier it is to mechanize, and the more quickly it will be turned into a digital product or service.

Now take product development today. You have product managers who define the business need, a UX designer who observes and interprets user behavior and translates it into usable interfaces, and a wide variety of developers and operations people, many of whom perform tasks that are, you guessed it, mechanical, and thus targets for automation. Where there’s a performance engineer, there will soon be a performance algorithm; where there’s a digital asset manager, there will soon be a digital asset management service, where there’s a front-end dev creating CSS animation in code, there will soon be software to create production quality animations *without* code. These things are happening. New software and services that replace mechanical operations are created every day.

Now when we look at the job that UX designers do (notice we already merged the UX and design roles), there’s something different, and not just by degree. The task of the UX designer, observing user behavior and creating interfaces crafted to respond to, and influence that behavior, is not mechanical.

Design is:

  1. Cyclical not linear. Insights from testing lead to iteration
  2. Governed by discovery, not rules. We have a lot to learn about human behavior
  3. Intentional not automatic. Designers constantly make judgments in uncertainty

Design is an intellectual, even emotional task that requires intimate knowledge of it’s subject; human beings. To understand human behavior, it seems, takes a human. There may be a point somewhere in the distant future where an algorithm can accomplish some of this, but if we are setting up the dominoes in the order they are likely to fall this one belongs close to the end.

This is not to say that software, automation, and AI will not affect the way design is done. They will, but likely in ways that strengthen, rather than weaken our hand. Here are a few things that are happening already and will continue to happen.

  1. Design systems will lead to Design at Scale. Large organizations will be able to deploy design more efficiently and ‘reinvent fewer wheels’ meaning they may not need to increase the size of their design teams that much.
  2. There will always be more to design. The totality of digital communication continues to increase exponentially.
  3. The UX designer role will absorb other roles just as in the desktop publishing revolution (remember the animator?). This becomes more likely as design software aligns itself to an increasingly standardized web production pipeline.
  4. AI will provide powerful tools to ‘design algorithmically’. For example imagine an adaptive design system to personalize not just content but style, or stock photo search that automatically presents a range of appropriate images based on the text content already in the design.

So, UX Designers will not be replaced by AI, developers on the other hand might not be so lucky, unless they are the ones developing the AI.

10 simple tricks to improve your design by Kevin Oleary

Group 3.png

If you are just getting started in design, or if you’re looking for ways to improve, there are great resources available to dig deep into the fundamental principles of design. If you have the time I recommend you use them. Unfortunately, most of us don’t have a lot of time, so here’s a list of design heuristics (rules of thumb) that you can use to quickly up your game.

  1. Steal things
    Take a design you think is great, a homepage for example, and try to copy it exactly. When you think you have it right, screenshot the original and place it over yours at 50% opacity. Looking carefully at where the two differ will tell you a lot about subtleties of size and placement that made the original design work. Remember those things and use them in your next project.

  2. Line things up
    Most design programs have guides, pull guidelines out onto your design and use them to start lining things up both vertically and horizontally. You don’t have to make a rigid grid system (unless you want to), just line things up, even if it makes no sense, it will give your design a feeling of order and intentionality.

  3. Give it a backstory
    Imagine your design is a character in a movie. Describe your characters motivation in one sentence, for example ‘I am letting you in on a wonderful secret’ or ‘Brace yourself, we’re going to do some thinking’. Put the sentence on a note, post it in a prominent place in your workspace, and look at it each time you start to work.

  4. Make your layout a map
    Find a block of text in the layout that’s not the largest or smallest on the page, but roughly in the middle, and draw an even 8x8 grid on top of it. Fill one grid square with a color and imagine that square is a car. If you drove it around the white space of the layout would it fit? Could another car pass? Are there awkward intersections? Is there a clear hierarchy eg. highways, avenues, streets, alleys? Try to make the design more ‘driveable’ and you will make it better.

  5. Color things by size
    Take a design and make a color palette of it’s five key colors arranged from most desaturated to most saturated. Now identify five prominent elements from the design with as large a size variation as possible. Change the colors of each so the smallest is the most saturated and the largest is the most desaturated. Did the design get better? It’s not a hard fast rule but more often than not this works.   

  6. Avoid big changes
    Behavioral psychologists have found that people respond well to what’s familiar, and poorly to what’s strange. At the same time people are keenly aware of very small changes in their environment. The lesson is that big redesigns tend to alienate users. If you are redesigning something, don’t start from scratch. Make a few subtle, eye catching improvements and if possible introduce them gradually over time.

  7. Learn your cultural language.
    Every design element; colors, fonts, icons, patterns, carries a host of cultural connotations that convey meaning before a user ever reads a word. Pastels say ‘baby’, plaid says ‘Scottish’, Helvetica ultra-light says ‘fashion’. You can use (or subvert) these expectations, but only if you know them. Before you start to design, write out a list of connotations you want your design to have and use they to guide your choices.

  8. Set rules for yourself
    Apart from general design rules, give a design its own unique rules, like ‘purple always means premium’ or ‘quotes are never more than 20 words’. The rules can be completely arbitrary, but if you follow them consistently you establish shortcuts the user can rely on to quickly get the gist, like the way stop signs are always red and octagonal.

  9. Get a second opinion
    If you’re at the stage where you have a high-fidelity comp or prototype show it to someone who falls within the target audience. Don’t tell them it’s your design or even that you like it, and above all don’t defend it. Just ask their opinion and pay close attention to how they react. Afterward you will likely find yourself making changes that strengthen the impact of the design on it’s audience.

  10. When all else fails, spend money.
    The web is full of places to buy great design elements and templates of all kinds. If you are stuck, or pressed for time, don’t be afraid to use them. If you do buy assets, don’t be cheap. Really well crafted fonts, icons, illustration, or photography are expensive, but they pay you back in the time you save not having to retouch, re-draw, kern, or color-correct. It’s also worth noting that cheap design assets are like cheap clothes, people can tell.

Keep in mind that heuristics are shortcuts to a quick solution, but if you know anything about behavioral psychology you know that heuristics can lead to biases. When you’ve got time always go back and carefully re-examine the choices you’ve made, do qualitative and quantitative research (survey users, track analytics), and set yourself some objective goals for both quality and ethics. Be sure you are making good things that benefit the people who use them.

Five Reasons Progressive Web Apps will Eat the Web by Kevin Oleary


If you haven’t heard the term ‘Progressive Web App” you’ll soon be hearing it a lot. Though the term is being used by different people to mean slightly different things, here are the basic characteristics.

  • ‘Progressive’ means they use lowest common denominator technology to function under harsh conditions, on older devices, or offline when there's low bandwidth or connectivity.

  • 'Web' means they are served over https and use standard web technology (HTML5, CSS3, Javascript), not native app code like Objective C, or Swift.

  • ‘Apps' means they don't just display content, like websites, they perform tasks, like creating a to-do list or filing your tax return.

Here’s why I believe this combination of features makes Progressive Web Apps a virtually unstoppable force.

1. No barrier to user entry

One of the lasting usability problems in native App ecosystems is the friction of app installation. Even at it's best, finding and downloading an app still takes time and mental effort, which translates into lower app adoption rates across the board. Progressive Web Apps load immediately, like a website, and then offer the immediacy of an app with icon on your home screen.

2. Develop once, publish everywhere

Worst case you are actually writing code per-platform, but even with cross-platform dev tools that compile down to native code, you still have to maintain and debug multiple codebases. You can't beat the simplicity of a single development workflow.

3. Tear down the garden walls

Users don't have to wait or worry if an app will be released for their device”. Releasing once is releasing for all devices and all users.

4. Ride the javascript wave

It’s clear that Javascript is a juggernaut of Development activity and it shows no sign of slowing down. It ate the open web, and jumped the tracks to the server-side with Node.js and it's package manager, NPM (see below) and is now poised to consume the native app world as well. Progressive Web Apps are standing on the shoulders of that ecosystem.


Five year growth of downloads from NPM. Source: https://www.npmjs.com/npm/state-of-javascript-frameworks-2017-part-1

Five year growth of downloads from NPM. Source: https://www.npmjs.com/npm/state-of-javascript-frameworks-2017-part-1

5. Everything users expect from a native app

Progressive Web Apps can: authenticate users in the background, store user data on the device, work offline, control the phone, camera, etc. While the quality of the experience is not yet *exactly* equivalent to native, it will be very soon.

I don't think it's an overstatement to predict that this trend will spawn a new "universal" app ecosystem that changes everything about how we use our devices. If you are developing for the web right now, this is the place to be.

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.