Designers are not users. Users are not designers. (Jakob Nielsen)

I’d be curious to know when this one came out. I think I remember a previous incarnation that said the same thing, but about developers.

And all that’s telling me three things. First, I’ve been in this business for way too long.

Second, designers are definitely the ones in charge these days. Now, they are a lot better than developers when it comes to UI, or UX, or just plain “getting” users. Designers do, though, need to realize that they’re not perfect, and there’s still a lot to learn.

Third, it seems like whoever’s in the driver’s seat is going to have some serious trouble with perspective. It is so easy to design for yourself, or to assume certain things about your users, or to just get lost in the details of the project itself and forget about the real, actual users themselves.

Luckily, the solution is the same as it was 30 years ago (yup, that’s how long I’ve been doing this). First, I would recommend a little humility. Yes, it’s great to be in the driver’s seat, but you still do have to watch for those bumps and potholes and other drivers.

Second, I would recommend being fully user-driven. There are two basic ways of ensuring that happens – one before design happens, and one during design. 

For the former, there simply needs to be some research into who you are designing for – what makes them tick, what do they want, what do they need, how do they operate – who are they? Now, you can do this in one of two ways, quantitative or qualitative. Quantitative is the more popular, and involves surveys, VOC, web analytics, and so forth. It gives you the numbers, but the data tends to be a little on the thin side (i.e., it doesn't give you the whole picture). That, however, can be supplemented by qualitative – interviews, ethnography, focus groups – all resulting in something genuinely useful in the design process, like a persona. Qualitative gives you smaller numbers, but much richer data. In the end, qualitative can have as much impact - if not more - than than quantitative.

For the latter, nothing beats good old-fashioned user feedback. These days, that simply means getting it out there in production and then doing A/B testing, monitoring analytics and VOC, fielding surveys, etc. Once again, though, your data may be a little thin. Plus, you can’t get any feedback until the thing’s actually live.

You can use usability testing, though, to get feedback at any point in the design process – pieces of paper, an Invision prototype, HTML, a test system. Further, the feedback will be very rich. The users will tell you which direction to head, what’s working, what’s not, what needs to be explored further, what needs to be tweaked, what needs to be totally redone. And, most importantly, you’ll get the why’s behind it all. And that means you can feel pretty assured that you may have actually solved the problem and made the user experience better.

No matter who’s in charge when it comes to UX, if you want to stay in charge, never get too far away from real, actual users.