“Designer…ish” speaking

UX Designers are an interesting “species” living somewhere between the client, the users and the developers, bridging them to ensure the product will accomplish its goals. It’s a role that speaks a little of each language.

The client has expectations, a vision to accomplish, the users want their needs satisfied, UX designers want the product to be used with the less friction possible and the developers want the product to be a “well-oiled machine”, working perfectly. But the ability to make a good product requires compromises. Sometimes it’s not possible to get all parties fully satisfied (and the priority is usually the client). However, it’s always important to know how to use the project limitations to make the best product out of it. The ability to communicate between all parties is the key.

Here are a couple of situations based on my own experience that give a picture of the most common, I would say “issues” I found on my way (and I’m sure a lot of other UX designers did as well) when dealing with each one of the involved parties.

1. “This is perfect, but can we try another version just to make sure?”

Does this sound familiar? To a lot of designers, especially at UI stage, yes. It’s really very easy to suggest other visual solutions when the visual is so “right there”.

In this situation, I understand that it’s not perfect, and that’s fine! It happens and we, designers, have to be open to improvement by iterating. But when that happens in a well sustained design, I know that we will have to make some commitments to guarantee that we move forward. I always try to make a well studied design to avoid having to make thousands of versions of it. It’s not even recommendable to do it without having user metrics. Making a new version on top of an untested one, can be time consuming and, sometimes, we have to go with the first version because the users didn’t accept the second one so well. The best way I found to avoid time-consuming unnecessary changes is by proving that the product is meeting its function… A/B testing, user testing, … use your means! Sometimes the iteration is needed, sometimes it’s not. The best we can do is to show the client how the users are dealing with the current work. If he still wants to do it another way, well … it’s his call!

2. “That’s not technically possible”

These words coming from a developer usually mean that “It’s possible, but not without tricking the code” or “We don’t have the time to do it in the project timeframe”.

When hearing this, I dig to figure out what’s the real problem talking to the developer and asking to explain (sometimes in a designer-user-friendly-way, like if he was teaching his kids how to code). Well, we designers know a little code ourselves, but it’s not really our main expertise. If it justifies, I also review the drawings to adapt it better to the budget. Not without notifying the client for that and, sometimes, testing it again with the users. We all want it to work well, but we have to keep our feet on the ground. This kind of evaluations should always occur in an early stage of the project, where the costs to change it are still reduced. Engaging the developers on the design process to make sure we are all on the same page decreases the chances to have entropy later on.

3. Small changes, huge impact

Very often, the client tends to make design suggestions in the product development phase (when himself already approved the design prototype). The designers should be aware of that, because it’s easy to loose track of the changes. Situations like these made extremely important the continuous cooperation between designers and developers along the product development cycle and that’s what I believe to be the best for the final outcome of the products. As close as designers work with developers the better. I found myself in my professional live one day or another validating functionalities “full of surprises”. In that scenario it’s common to hear the developers saying: “Oh but that’s just a flashy button the client asked me to add to this screen!”, and as a designer I think … “and there goes the screen balance and a new “funny feeling” the users will have about that screen will arise”. Everyone involved in the project should be aware that a small request can have a huge impact on the final product outcome. That “button” can be the difference between a gained and a lost user.

In that case, I try to understand why the client did it. Perhaps he has a need he didn’t mention, or maybe he just doesn’t realize the impact the button has in the flow, or even on the screen reading. It’s not only a problem for developers or team leaders. The problem is much more frequent with designers. Sometimes the client has a rigid view about the product and wants it to be done the way he imagined working and nothing else. In that scenario, I usually say that “They “are” the designer”. They just need someone to give the product the “looks”, which is a very small part of what a designer can do for his product. Sometimes, even the “looks” are conditioned to how he wants the product to look like. To guarantee the quality of the product, I like to explain the client what is the value of the UX design work, and why there shouldn’t be any pre-conceived ideas about how the product is going to look and work. Of course, some aspects of his branding will always have to be kept, but that’s it, for new products! Already existing (and being used!) products that only need to evolve in functionalities, it’s a whole different story and there’s a lot of aspects to have in mind when designing for that scenario (it’s not just the branding!). Sometimes, more important than doing a functionality really “outstanding” is to make sure it maintains the consistency in the product. The users may be used to work in a certain way and it’s important to guarantee the new functionality fits the same mindset.

4. “What happened to the interface?”

Users typically don’t like other parties to change the way they work. Their minds are so used to do it in a certain way, that trying to make that “easier” sometimes does the opposite.

When the client wants to dramatically change the way a product is working, that change needs to be very well studied and planned. I try to balance the new requirements with the resolution of the bigger problems the users are having without a significant impact on their work. If that’s not possible to avoid, the best way to do it, in my opinion, is through small changes in each release. Step by step, the product will be changed without having angry users, given the idea of a natural evolution. Another possible approach is to assume the new version will be disruptive. But be prepared for handling a few reactions!

5. Asking for guidance

When performing presencial user testing, you explain to the users that there’s no right or wrong questions. You just want real honest feedback, but you know that deep in their minds they are expecting not to fail. Sometimes they look at you almost asking for guidance. You just have to keep your “poker face” and let them try to perform the tasks and fail, like in “real life”.

Deep down, I am also wishing the users understand clearly how they do their tasks and, of course, don’t fail. Well, most of the time. The exception applies when I actually “want them to fail”, sometimes to prove a point, other times to honestly understand which of the prototypes work better (when there’s time to make more than one version). Either way, I need to be absolutely exempted.

“It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.” - Steve Jobs

Well, that’s my perfect user testing outcome. Guilty!

There are many other situations I could tell you about, but for now that’s all I can remember. In Portugal we have an expression called “Ossos do ofício”. It’s about common situations we face and get used to at the job we do. Do not try to translate that expression to english. It’s just not elegant.

Do you have any stories to share? Feel free to comment below! We’d love to hear from you!

At Runtime Revolution we care about the user experience. We are a team of designers and developers willing to make your ideas a success.