As a developer, I shipped software for companies ranging from Fortune 500 multinationals to mid-sized government contractors and small startups. At these companies, only some of the most senior developers traveled - for speaking at users’ conferences or providing onsite, on-call customer support.

None of these companies sent a developer onsite to learn more about the users. We would hear about users from trainers, support, project managers, or upper management.

Why?

This may play into a common feeling of developers: “Keep us out of meetings. Just leave us alone to write our code.”
Stakeholders might think of developer time in terms of budget. If a developer attends a meeting without the need to be there, having her not attend that meeting is a cost savings.
Development managers who are “players’ managers”, so to speak, may keep their developers out of meetings as a result of their own preference when they were developers.

The theory behind it

Jakob Nielsen has written about developer-centered user experience, which he lists as stage 2 of his UX maturity model. In short, teams who do this actually do care about users. They don’t believe that “a good user is a dead one”.

But they stop short of involving real users in their design process.

Put another way: these teams create what they think is “easy to use” or “intuitive”, and they call that “easy to use” or “intuitive”.

The problem - and one that costs you conversions and user retention - is that there is a disconnect between how your project team understands the world and how your users understand the world.

Jakob Nielsen goes on to say that this problem doesn’t look big if you’re working on a product that’s for people like yourself. Developer-centered user experience works just fine if you’re making a tool for other developers who use your technology stack. But in designing products for people who aren’t like you, it falls apart.

(By the way, teams with designers aren’t immune to thinking this way. Just because they have someone who can jump into Photoshop on day 1 and make a design mockup doesn’t mean that they’re involving their users in design.)

Still, developer-centered design is not always by choice. Nielsen goes on to write that it takes decades for most companies to become “user-driven”. So don’t assume that your upper management or your clients will commission you for an extensive field study. You need to solve this problem a little bit at a time.

How much can remote work help?

Remote development and remote user research

Let’s approach this problem the way that more companies are now approaching remote work.

Every development team I worked on used remote work in one way or another. These included:

Letting key team members work from home after picking up their kids from school
Letting people work from home because of health problems or commute distance
Allowing telework during winter weather - or just when we needed a break from our commutes
Collaborating with onshore business partners or offshore teams via teleconference

And each of these companies saw remote work as an exception, not a rule.

If you don’t have to be in the office to work, you don’t need to be in your users’ offices to get key insights from them.

Fast remote research and design techniques

Here are some UX techniques you can do remotely and fairly quickly:

Reviewing analytics for your product, assuming you have access to this data.
Doing a formal usability heuristic evaluation of your product or its competing products.
Running usability studies where your current or potential users walk through common tasks in your product. This may require extra effort if your product is not web-based or an app.
Creating informal provisional personas to serve as design targets for your UI and UX work.
Drawing storyboards or sketches to show how your users will interact with your product.
Creating static wireframes of individual screens in your product.

Remote-friendly with some extra work

These techniques require more effort but can also be done remotely:

Conducting surveys of your users.
Interviewing your users over the phone or via videoconference.
Cataloguing and auditing your content, if you are dealing with a large website or an product with many screens.
Creating fully data-driven personas that properly model clusters of your product's users. (An analysis that doesn’t superimpose your hypotheses at the beginning can take days.)
Creating mental models to depict events in your real users’ lives.
Understanding how your users’ interactions with your products fit within all of their interactions with your company via experience mapping.
Building interactive prototypes of your product so that people can interact with it before you write any code.
Presenting or reporting on your research findings to other people in your company.

Some caveats

Like remote work, interacting with your users remotely has some shortcomings:

You can see what is on their screen with screen sharing, but you can’t see environmental cues around their desks that may show you what their real problems are.
You can’t see your users’ body language without a webcam, and it becomes harder to interpret silence.
If your user base is international, scheduling sessions with users in different time zones means that one or the other of you (probably you) will need to work during a time of day that you don’t normally work.
If you’re not moderating the studies, your participants have to stick to the test script as well as they can. You won’t be able to ask them questions in the middle of the test or redirect them to the right path if they get away from the features you’re really trying to test.
Your users have to set up additional hardware and/or software tools for you to see them - which can automatically rule out less tech-savvy users - especially if they are using a mobile device.

It also may be hard to convince your upper management or clients to let you interact with users at all if they think that not letting you do that has worked for them before.

Still, the overarching answer is this: You don’t have to solve this problem all at once. When I lay out an overall process in UX for Development Shops, I’m not expecting you to implement the entire thing. That’s why it has a section of quick wins that are all remote-friendly.

Initial user research

If you can’t go onsite to talk to your users, the next best technique is user interviews. You can do these via teleconference or videoconference. This will still require time from you, and if your product is not internal to your company, plan to give interviewees an incentive for participating.

User surveys can give you more quantitative data that lends itself more easily to analysis. You can run these using your own respondents (which you could recruit via an email to your users or a Facebook ad) or via a survey panel website. If you run them with participants who you don’t know, plan to screen them via a shorter initial survey and only give the main survey to people who pass the screener.

User interviews and surveys each provide rich data sources for finding out what your users have in common and how they differ.

To make your design process more data-driven, create a list of the top 15-20 ways that your participants vary in behavior (e.g. how much of their shopping is online vs. in a store). Identify a few that look the most important, and analyze the participants that fall into each segment. This is a starting point for a cluster analysis, a technique that About Face and Designing for the Digital Age go over in detail.

After this, you’ll have the correct segments to use for building user personas and determining which persona represents your best target audience.

And this whole process can happen without your needing to leave your desk.

Ongoing usability testing

To be as helpful to your team as they’re intended to be, personas need to carry through to the rest of your design and development process. Part of this is to involve people who are like your personas in your design.

In other words, conduct think-aloud usability tests with them where you watch them use your product. You can show them your design in progress whenever you have something new for them to look at: a new live product, a staging site, a high-fidelity prototype, a clickable wireframe, or a paper prototype.

Teams can object to usability testing because of budget, time investment, concern about rework, concern about their ideas being stolen, or fear of criticism. But usability studies can correct your focus, save you money on development and support, and even provide you more intelligence about your competition.

Learn more about user research and designing from data

This article is adapted from content in UX for Development Shops: Declutter Your Interface, Design from Data, & Increase User Adoption & Retention. You may buy this ebook at https://davidp.io/ebook.