All right, everyone.
Thank you.
We have Emily O'Mear for the next talk, and she'll be doing her talk on do more awkward
interview or more awkward user interviews.
Do you feel awkward interviewing users about how they use your project?
That's okay.
Your interviews are often good interviews.
I'll hand it over to Emily.
Okay.
Excellent.
Can everyone hear me?
Cool.
Okay.
So, how many of you feel really awkward when you do a user interview?
Yes?
Okay.
How many of you are really excited to learn about how you can make your user interviews
even more awkward so you can feel, okay, cool.
That's what we're all here for.
So, I'm talking about two things, basically, that you should do more user interviews regardless
of how awkward you feel about them or not, and also that you should proactively employ
techniques to make yourself feel more awkward, possibly also to make your interviewees feel
a little bit more awkward too.
So, I hope this sounds really awesome, and thank you all for joining me.
The first thing that I, the first point that I want to make about doing user interviews
and feeling awkward, because a lot of people actually really hesitate to ask users in the
first place, because they feel like this is a huge ask.
I'm going to ask for like 30 minutes of somebody's time, so they can feel really awkward just
about that part.
So, remember, though, that this isn't actually how your user thinks about it.
Doing a user interview, as in from the user's perspective, is actually a way for them to
contribute to your project.
It's a way for them to tell you what works, what doesn't, help you make the project better,
and also people like to talk about themselves.
You're giving the user an opportunity to talk about themselves, and from their perspective,
you know, hopefully get some of their needs met.
They can give you like their wish list.
That doesn't mean you have to do everything on the wish list, but it is, there is something
in it for the user.
So, don't get too hung up on that first ask and feel like this is like a huge imposition
on your user.
Okay, so then let's talk about a little bit why you need these user interviews.
You need to be able to understand who your users are.
You need to understand why they're using your product or your project, why they care about
it.
You need to understand that in order to figure out how you're going to talk about your project,
and also figure out what you're going to do with your project next, what components of
your project, what features are really useful to people, what things people really don't
care about, what things would actually be helpful if they were added, what things potentially
could actually detract from the value of your product if you were to build them.
So user interviews are really important.
They're also a really important part of building community.
Again, something to keep in mind when you're feeling like really awkward about asking for
that user interview.
It's a way for your users to feel more connected to you as a maintainer and more connected
to the community.
So user interviews, super important to do in the first place.
And this is some of the information that I hope that everyone thinks of when they're
doing their user interviews.
It's just an example of things that you're going to try to be getting, extracting out
of your users as you're doing these interviews.
You want to know what triggered them to find your project, so did they hear about it at
a conference like FOSDEM?
If so, and you want more people to find out about your project, maybe you should go to
more conferences.
But you also want to know what triggered them to even look for something like your project
in the first place.
What were they trying to accomplish in that moment?
Then you also want to know, what do they compare your project to in their head?
And sometimes you'll find answers like some other project, and it will be obvious.
But oftentimes people don't actually compare a project to another project.
They compare a project to spending four hours a month doing something manually.
They might compare a project to paying a fine.
They might compare a project to losing sleep at night because they are worried about whatever
it is that your project solves.
So understanding what that mental comparison is is going to help you talk about your project
more effectively, understand where your project needs to go in the future, and make more of
a connection with your community.
So another thing that you need to understand is how they interact with your project.
Is this something that they actually touch every day, every week, or is it something
that runs in the background and is really critical, but it's very easy for everybody
to forget, especially if you have a project that's used in a team situation.
You want to know who on the team is interacting with a project and in what way.
You'd also want to know who was the champion.
So maybe you have five people on the team who are interacting with your project.
Who was the champion?
How did they then evangelize it within that team?
And then you also want to know if, hopefully, there was one, but if there was a magic moment,
what that moment was.
So when they first started using your project, what was the sort of aha moment when they
were like, oh, now I understand how this is working.
This is so awesome.
And the understanding what that moment is is really important, so that you know what
to optimize and how to make the process for a new user of getting to that magic moment
as smooth as possible.
All right, so let's talk some more about goals, right?
Okay, so what's your goal when you're doing a user-interferent view?
I've just talked about some of these things, this is a pop quiz.
Is it to get some really amazing information about your project, or is it to make yourself
look awesome and smart?
Which?
Okay, so there is a little bit of a caveat here.
You don't want to make yourself look like a total moron, especially, you know, people
are trusting you, so you don't want them, like, if they're using your project, you don't
want them to think you're a total moron, especially if you're trying to monetize this
project in any way, in any way, depending on it financially.
However, you also don't want to get hung up on the idea of making yourself look good
during this interview.
That is not the point of a user interview, the point is to get some really good information.
So some of these techniques, these interview techniques are from journalism, I used to
be a journalist, when you're a journalist you don't really care what your sources think
of you, if they think you're an idiot, that's okay.
So just to acknowledge, there are some limits, but then again, you know, your users are coming
into this, they already respect you, they know your work as a maintainer, they depend
and they like your project, so you don't need to show them how awesome you are, they already
know that.
Okay, so here are the two, like, awkward interview techniques that I want people to take away
from this.
So one is to strategically deploy awkward silences.
The second one is to ask so many follow-up questions you risk looking dumb.
But let's talk about the first one, the awkward silences.
Okay, so in Western cultures, most cultures, it is a little bit culture-bound, but after
a certain amount of time in a conversation, people start to feel like this silence is
really awkward.
And if you're in a conversation, that's really easy.
You just ask the other person another question, boom, problem solved.
But if this is an interview and one person is asking questions and the other person is
answering them, and the interviewee has finished answering their question and the interviewer
doesn't do anything and just sits there and is silent, it's going to make the interviewee
start talking again.
And what happens is that first answer that you get to the question is like the pre-planned
canned answer that they've already sort of mentally vetted to make themselves look good,
possibly to make their organization look good, and not reveal anything that's too embarrassing.
That's good.
I mean, you're going to get some good information there.
But if you want to get beyond that, then after that person has finished answering the question,
let it sit and let it feel a little bit awkward.
And if you can sit with that awkward silence long enough, the interviewee will start talking
again.
And when he or she starts talking again, that's where you get the information that they haven't
really pre-vetted with themselves.
They'll start rambling.
They'll get the sort of like more emotional, more off-the-cuff answers to questions like
why did this matter or why did you want to do that?
Even if you were to interview somebody about what they had for breakfast, I can guarantee
you that if you just let an awkward silence sit there, they would start rambling on about
why they chose whatever they had for breakfast because they feel like they need to fill that
awkward silence.
So the next thing, the next technique is follow-up questions.
Let's use the breakfast example again.
If so, you ask somebody, what did you have for breakfast?
And they said, I had a croissant.
And then you ask them why?
Then you're going to start getting some more information.
And then maybe they say, that's all that was available.
And then you ask them why?
And you keep asking why again.
This can start to feel a little bit uncomfortable because you're really pressing people to talk
about their core motivation.
But you're also getting information that is much deeper, much richer.
And one of the tricks here and the thing that can honestly make you risk looking like an
idiot is that you want to try not to assume anything.
And particularly, this can be hard in like a technical situation because there are sometimes
when you want to show that you're not an idiot, you know why this was important.
When somebody is like, we felt like we had to improve our supply chain security.
And you ask why?
It's like, well, isn't it obvious why we had to do that?
But actually, it's not because why at that moment was that suddenly a priority?
Why hadn't you done it before?
So keep asking those why questions to try to dive into really understanding what the
motivation is and not assuming anything.
Even if it seems like it should be self-evident what the answer is, don't make that assumption.
All right, so I am going to give you some homework.
This homework is really easy.
Choose a friend or a colleague and ask them to do an interview with you.
It can be about anything.
It can be what they did yesterday evening, what they had for breakfast.
And I want you to try and see what happens when you don't jump in with a new question
and just let that awkward silence hang.
The key to doing this is that you have to set the expectations that this is an interview.
So the other person is not allowed to ask you a question in return.
They're only allowed to answer the questions that you're asking them.
And the reason that I actually recommend practicing this is because it is way harder than you
expect.
It should be really easy, right?
You're just sitting there quietly, but it goes against like your whole being to just
let that silence sit there for as long as you can possibly stand.
And that is why it works, quite honestly.
Okay, so that's it.
I'm Emily O'Mear.
I have a podcast.
It's called The Business of Open Source.
You can connect with me on my website.
You can write me an email.
I'm also on LinkedIn.
You can send me a message on LinkedIn.
You can just search for my name and you will find me.
I don't think there's anyone else with my name.
Before we wrap up, though, is there anybody who has questions?
Yes?
Do I need a microphone for this or is it more effective to do this with a microphone or...?
Just ask the question and I'll repeat it.
Is it more effective to do this with a microphone or...?
Oh, is that the question?
You mean if you're doing a user interview?
I mean, honestly, when I do interviews, I use Zoom, so I just use whatever's on my computer.
But no, it doesn't matter.
This is a situation where technology just doesn't matter.
However you do an interview, it doesn't matter.
On the other hand, I will say I understand where the question's coming from because people
do behave differently when you put a microphone in front of their face.
If anything, no, do not put a microphone in front of people's face because that triggers
the self-censor, and what you want is to get rid of the self-censor.
Yes?
So you said that people shouldn't ask a question of you during this interview, so one way information
is...
Yep.
If they do ask a question, do you stay silent to increase your...
So the question is if the interviewee asks you a question, should you just stay silent
to increase the awkwardness?
That's a really good question.
I am not sure.
That's actually never happened to me, so I don't really have a good...
I think I would go for just answering the question and then asking a follow-up, right?
So you're...
Yeah, you could do that too.
So I think I would just...
You want to use the two techniques together anyway.
All right, we probably have time for one more question.
Yes?
Does being awkward ever break the interview or the trust and make it harder to go on?
The question is, does being awkward ever break the trust and make it even harder to go on?
In my experience, no.
I have never had a situation where being awkward broke the interviewee's trust.
I don't think so.
I mean, there's probably...
There is a limit, right?
But as long as you're being polite, then I wouldn't worry about that.
And if you have any sense of social grace whatsoever, you will probably totally max
out on your awkwardness well before you would break someone's trust.
All right.
Yeah.
Okay, we have seven seconds.
So thank you so much.
Thank you.
You're welcome.
Thank you.