(upbeat music) (applause) - Thank you, John.
I've always had a love for design.
I studied product design at university with a very physical and engineering focus. But, after realising that I was shit at building furniture, cars, and anything physical, I quickly fell into digital. I've worked at enterprise-level consultancies my whole career.
Initially as a UI developer, where I dipped in to both the design and also the code. Five years ago, I made the trip over to Australia and really honed into what I was interested in, design with Servian, where I designed data-driven solutions with a human-centric approach.
Being a consultant, the majority of the time I'm thrown into a client and expected to own the process end-to-end. And I've worked on a lot of projects where they'd been a roaring success.
Others, have fallen flat on their ass and not got past MVP stage.
Today, I'm going to talk to you about subject-matter experts.
But first I'm going to set the scene a little bit. Right there we go.
It's estimated that over 80% of digital projects fail. In the US alone, large enterprises throw away an average of 400 billion dollars per year on failed digital programmes.
In addition to this, 97% of companies have experienced failure in releasing a digital project.
When you dig into this data, there's a barrage of reasons as to why.
Code Computerlove have conducted a survey with mainstream and top-performing organisations, citing that a lot of the reasons for failure as basic flaws in communication.
Now, can we get a show of hands as to who's been a victim of at least one of these aspects behind me? Pretty much about 80% at least? Yeah.
I recently was on a project where a client insisted on added functionality that offered no real value to the user.
We ultimately failed because we were too focused on doing the simple things well.
We were too focused pimping up the MVP and not doing the simple things well.
It really is a real eye opener, but all of us in this room have a responsibiltiy across every single one of these aspects.
And, more importantly, these factors are defined at the early stage of a project.
The discovery stage.
And they involve communication between the business, the project team, the users, and the subject matter experts.
Jeff alluded to this in his talk earlier on. We really need to focus on satisfying the unmet needs of the users in order to succeed.
Just a quick disclaimer, contrary to the premise of my talk, I love subject matter experts.
They make my job and our job a whole lot easier. At least, some of the time they do.
They are vital to the UX design process.
And walking into a room full of experts, and not really having any idea as to what they do, can be very daunting.
So leaning on their expertise to gain an understanding of a product landscape, whether a project is successful from the outset is kind of vital.
SMEs typically have insights that no one else would. So leaning on just these insights could potentially lead you down the wrong path very quickly.
During my time as a consultant, I've come across three very distinctive, disruptive SME types.
Being a UX designer, I've tried to collate them the only way that I know how: personas.
The first of which I like to call, the fake. The most most common of all subject matter types. Also known as the egotistical, ignorant, narcissist. I've encountered this stakeholder many times, where they claim that they are subject matter experts. Giving you an earful about skewed assumptions that have no rationale or evidence as to how something should be designed.
Some insights, yeah, they might be useful.
Others, not so.
As designers it's our job to break down the walls that these stakeholders put up.
The general idea is to take them with a pinch of salt. Avoiding confrontation where you can, and backing up every single assumption or evidence you have with cold hard evidence. I've found that overemphasising any kind of ideas which are worthwhile to the process is a good way of keeping them on the side.
Are you ever thrown into projects where you have very obscure UX cases for very small sets of users.
If the answer is yes, then you've definitely come across the loner. On some projects, internal SMEs are the closest that I have got to users.
Validating your assumptions with just one person is a very dangerous precedent to set.
And in my experience, you're never designing for that one sole user. No matter what the business or the clients says. Who's going to be pushing that data to the platform? What if there's an eventual need for more than one user? How does the person's workflow affect the tasks of others? These are all questions that we have to ask at the discovery stage of the project.
And yeah, some people's processes may be working in solace.
But, there will always be a crossover at some point. I discovered this when designing a cybersecurity platform. The sole user, an SME, left his role and was replaced by someone that had to learn everything from scratch.
Looking at it with a new pair of eyes, he was more open to change and susceptible to new ideas. And believe it or not, he wasn't the only user in the platform.
There was more that kind of, started to come out of the woodwork.
Cheeky buggers.
This brings me, nicely, to my third and final persona. Both this persona, and the previous one, the loner, have very similar personality traits.
I've found that people who are resistant to change, is a common perspective of people who are trying to cover a very small role in a large workflow, that you might be attempting to automate.
I encountered this problem when automating a very spreadsheet heavy process. With my colleague, Catherine, who is just sat over there. Hi, Catherine.
We cut the time to complete the task from days, weeks, to a matter of minutes.
And as a result of this, we saved the company hundreds of thousands of dollars per year.
People are worried about their job becoming obsolete. This is where your empathetic designer traits really have to set in.
Reassure them that time can be spent in other areas, and that work can be done of a higher value. Try and pair in the user and the SME.
The barrage of invalidated assumptions, from strong personality types can sometimes be very daunting.
You can sometimes start to doubt yourself.
However this is where you have to trust your process. Whether it's leveraging methodologies such as design thinking, lean UX, or your own. I'm not going to lecture you on what methodology to choose.
All human-centered design processes are pretty much much of a muchness.
And I think you're all old enough and ugly enough to kind of work those out for yourself.
Sorry.
We introduce regular feedback loops and iterations into every single design methodology that we offer at Servian.
And in my opinion, this is by far the most important factor to any design process.
As Dominic alluded to in his speech, spreading empathy in research is key.
Whether you do this with stakeholders, SMEs, users, or just people in your team, try and listen and be objective as possible. And get down with their lingo and abbreviations, so you can understand the workflows that you are designing for.
Both inside, and out.
You will eventually become a subject-matter expert of yourself.
And please, as a designer, the worst thing you can do is get too hooked up on your own designs.
I've been burnt in the past where, I've decided not to listen to feedback just because it was convenient to my own biassed assumptions.
Of course, there are times when you just can't win. You can't get through to these experts.
And I've been there in the past where key stakeholders haven't been onboard with the human-centered design approach that we've offered from the outset.
They are still stuck in the 'I know best' attitude, even if all of the evidence suggests otherwise. There's just sometimes no getting through to them. A great example of this was brought up by Sara Wachter-Boettcher.
I probably really butchered that name.
(audience laughs) Last year she presented Web Directions Design and she brilliantly describes, in her book, Technically Wrong, a classic fake SME scenario. Stakeholders that were all men, had the assumption just because their wives were always shopping, a smartwatch shopping app would be the bollocks. And by bollocks, I mean, best thing since sliced bread. Like the Amazon of retail smartwatch apps.
The designer, who was a woman, shared research that women rarely use shopping apps on their phones.
So uptake of a smartwatch shopping app would be pretty unlikely.
The input was ignored and the stakeholders made sexist assumptions. The product, of course, failed.
And stakeholders that assumed that they had all of the right answers about a product, left out people who had differing opinions. And this is actually a perspective of many. It's a pretty common occurrence, especially in consulting.
Now for the slightly morbid bit.
Sometimes, being wrong can have catastrophic effects. The Boeing 737 Max air disaster killed roughly 350 people. Black box data suggests that characteristics from both flights were consistent with pilots trying to fight the automated system. Facebook and YouTube have also been perpetrators of bad design recently.
Sorry Bob.
Failure to change their machine learning algorithms have resulted in users being exposed to fake news. A privacy engineer at YouTube last week, came out and admitted that this is a problem that he proposed fixing to high level executives seven years ago.
Seven years.
I was probably about 12 then.
The core problem clearly indicates a lack of communication and feedback between stakeholders, high level execs, users and everyone as a whole. The design decisions being made are clearly harmful, which poses ethical aspects which we really need to be mindful of.
I'm going to shamelessly pull out a quote from Josh, who spoke here yesterday.
When we design products we always need to think about future connotations.
And if anyone hasn't read Jonathan Shariat's- I probably said that name wrong as well - on tragic design, please do.
It really makes me think about how certain design choices can adversely affect users, and provides you with tools and techniques on how you can help avoid harmful design decisions in the future.
Luckily, the majority of the time, failing often and failing fast is considered good. It fosters and breeds innovation.
An example of this, is Facebook.
For the past eight years Facebook has been trying to combat Snapchat's user growth.
Apps like Poke and Slingshot were just cheap knockoffs of Snapchat.
And personally I feel they were never going to succeed. I'd be interested to see if any user research was done. (mumbles) Poke and slingshot would have failed to entice a loyal Snapchat user base.
I remember as a fresh-faced 23-year-old, that I downloaded Slingshot.
The next day I deleted it.
Fancy UI doesn't transfer a loyal Gen-Z user base from one app to another.
It offers no real value to do so.
You could argue that these creations were just Facebook's way of testing a hypothesis outside of the tried and tested Facebook app. A failed standalone app, is better than risking the potential decrease of millions upon millions of daily active Facebook users. Without Poke and Slingshot, we may not have had Facebook stories.
And for me, the beauty of Facebook stories, even though I don't use it, means it doesn't interrupt the daily use of a Facebook user's Facebook.
14 months after it's release, Stories has reached 150 million active daily users. And although this only accounts to the ten percent of the adoption rate across the whole of Facebook. And really only has half the uptake of Instagram stories, Stories have currently grown 15 times faster than Facebook newsfeed sharing.
Just like Facebook, Google uses other products as a testing ground for new features.
Killed by Google has been doing the rounds on the interweb over the last week or two.
It showcases all of Google's failed products, and some were just bloody awful.
Bloody awful.
Too high profile casualties in the last month, has included Google+ and Google Inbox.
And I'm sure some of the learnings of Google+ has gone into YouTube and also some social aspects of Stadia going forward.
By Inbox, Google Inbox, it's so sad to see you leave.
(mumbles) it's reminders, the sleek UI.
Although a lot of features are probably going to be slowly cannibalised into Gmail, I do feel like the bitter ex that's been just dumped by their more attractive partner.
Still love you.
It's okay to be wrong.
And this is something that I always tell my more attractive girlfriend every time we end up fighting.
Just like SME's are wrong regularly with assumptions and hypothesis, so are designers.
As long as we can learn from our own failed assumptions, then we're for the better.
Who's to say the learnings of 80% of failed digital projects haven't turned into the next multi-million dollar idea. I wanted to leave you with a tried and tested inspirational quote.
However, I thought I'd test out a new one of my own. Thank you.
(applause) (upbeat music)
