Entries Tagged as 'Experience Design'

6 frustrations designers have with developers

We know that developers can get frustrated with designers, especially when the designer designs something that’s impossible to build. But there’s plenty for designers to become frustrated about with developers.

Design is often seen as a ‘soft skill’ that is about an opinion of aesthetics, not hard rules, much less the rigorous logic of code. Yet designers work for years perfecting a craft, not just spouting uninformed ideas. However, being able to explain and articulate the ‘method behind the design madness’ is not always easy, and rarely quick, which leads to numerous project frustrations. Fortunately, there is usually a way to defuse the tension.

01. I designed it that way for a reason

Image source: Cat Donmit on Flickr

The Problem: The designer spends weeks creating meticulously crafted visual comps and spec documents, only to have them seemingly ignored by the developer. Beyond ignoring the specifications, some developers simply allow the browser defaults to stand without change if they are not explicitly stipulated in documentation, not just shown in visual comps.

The designer assumes that the developer will look closely at the comps and try to make them match ‘pixel-perfect’. However, this generally leads to interfaces that feel cramped or poorly organized, despite the best efforts of the designers.

The Solution: Designers should assume nothing, and know that documentation is never enough. A good design guide is the first step toward eliminating this problem, but designers also need to work side-by-side with the developers, regularly reviewing their work to ensure it’s what is intended in a design acceptance review when the developer feels comfortable with what they have done.

02. MVP!?!? It’s all MVP!

Image source: Jugbo on Flickr

The Problem: The developer has a finite amount of time to create the end product, even less for each sprint, so they will prioritize features and functionality based on the ‘minimum viable product’ that will meet the product specifications. Most designers, though, view the product as an integrated whole, not a series of interlocking components. But the MVP is often not defined until the development phase, so it can feel more like developers are making the decisions based on their schedule needs rather than user and product needs.

The Solution: The MVP needs to be defined during the initial phases of the product, and truly be the minimum viable product, not just the easiest to make, for different development phases/sprints. Designers can work to create a product that is built-up in stages, rather than completed all at once. This should also make it easier for developers to plan accordingly.

03. This will take how long?!?!?

Image source: Jon Hathaway on Flickr

The Problem: The designer has spent months planning, researching, and creating designs to meet the user needs, only to be told that it will take much longer than expected due to conflicting project schedules, staff shortages, and the dreaded scope creep.

The Solution: One of the facts of any UI development project is that development comes last, and is generally squeezed in time by the steps before (I have never known the discover, define, or design phases to go faster than planned to give development more time).

One way around this is through Agile coupled with Lean UX to allow development in parallel with design, allowing the developers to get started before the design is completely locked down. This approach is not without risks (design may need to be reconsidered) but generally leads to faster output and happier project managers. And really, isn’t that what we all want?

04. What do you mean “I can’t do that!”?

Image source: Peter Kaminski on Flickr

The Problem: The designer has created a really cool experience, but the developer takes one look at it and proclaims, “That’ll never work.” One reason developers might not be able to do something is because it cannot be done, but more often than not it’s one of two other reasons: 1) it would take too long, longer than the project has, or 2) the developer just doesn’t know how to it.

The Solution: If it can’t be done, it can’t be done, and the designer needs to rethink the solution. If it will just take too long, then the team needs to decide whether to scale back or take the time needed. But, if the developer just doesn’t know how to make it work, the designer will need to show them examples of places where the desired technique is working. I find that CodePen.io is my best go to place when I need to show ‘existing art’ to my developers.

05. Usability testing is NOT optional

Image source: Dopey on Flickr

The Problem: For many developers ‘usability’ means that it works as defined by the requirements. If designers want to test anything, they should do that before the developer spends long hours building the UI to specs. However, only so much usability testing can be performed with paper and clickable prototypes. Often, the most effective usability testing is done during development.

The Solution: Plan usability testing spikes into any Agile project with iterations that feedback into the development of the product.

06. They are telling me how to design again!

Image source: Amy McTigue on Flickr

The Problem: A developer reads one article on usability by Jakob Nielsen, and suddenly they are a usability and design expert. Designers spend years developing their abilities, knowledge, and aptitude. One problem is that, because everybody has an ‘opinion’ about design (informed or not) in some projects – especially where there may be a UX team of one – their voice is often drowned out.

The Solution: This is not an easy problem to solve, as it has more to do with interpersonal and group dynamics than it does with actual logic and reason. The best way I have found to deal with these situations is to simply listen without getting defensive. Let them have their say and consider what they say.

Does what they have to say have merit? Let them know, and then explain why you chose to go the path you did, acknowledging even that you are disagreeing with existing ‘best practices’ as prescribed elsewhere. Often developers want to just feel as if the designer is simply listening to them.

Anything else?

I’ve outlined the six frustrations that I commonly see designers having with developers, and previously detailed the six frustrations developers have with designers. What’s your take on this, and can you add to the list? Please suggest solutions in the comments below for us all to benefit from your experience.

Yes, Twitter is broken, but you can fix it!

There’s a lot of talk going around these days about the death of Twitter, but I think the stories of its demise are greatly exaggerated. I’ve been a Twitter user since 2007, and my use ebbs and flows. Like many, I have noticed some alarming trends in the tones of tweets that have come across my feed over the last few years.

To some, the matter is cut and dried: abuse. Not people abusing Twitter, but abusing each other on Twitter. To be sure, this is a huge problem, but I don’t think it’s why people have stopped using Twitter.

From my observation, it comes down what is actually a much larger problem on the web, one that allows the abuse to happen in the first place: trust. We find it increasingly difficult to trust each other online.

In order to trust each other, though, we have to take responsibility for our own use of the internet: in this case Twitter. To help, here are six simple rules I follow to help make Twitter a nicer place to visit.

01. Don’t use autobots


Twitter increasingly seems to be made up of autobots talking to autobots. People set up systems to automatically tweet and re-tweet and re-re-tweet but no actual human is there to see them. It reminds me of the scene in True Genius where students increasingly leave tape recorders to record the class lecture, to the point where the professor simply starts playing a tape rather then delivering the lecture in person.

If you haven’t read it, seen it, or heard it, don’t post it. Autobots can seem like a good idea for repetitive tasks – like saying, “Thanks of following me” or posting the astronomy picture of the day – but are really a disservice since these posts become nothing more than noise. Whenever you post, always add value, either by giving your opinion or just a few words on why you think what you are posting is important.

02. Make your avatar you

Twitter Avatar

Not only does it help people to know what you actually look like to help them trust you, remember that your Twitter avatar gets around. If you ever use Twitter to sign on to other services, they generally default to your Twitter photo.

If you are anonymous in the real world, you have to wear a mask or stand in the shadows. Everyone knows that you are protecting your actual identity. Online, however, you can appear to a known entity, but actually be hiding your true identity.

Don’t get me wrong, I believe in the right to be anonymous. It’s important to be able to say certain things without worrying about reprisals. But if you want to be anonymous be anonymous! Don’t pretend to be something or someone you are not.

03. Don’t RT… QT

If I wanted to see tweets from the person you are retweeting, I would probably follow them. I want to read what you have to say: your take on what the person tweeted.

The ‘quote tweet’ allows you to not only post the original tweet, but add your commentary to it, making the information even that much richer.

04. Use lists

One problem that contributes the signal to noise issue on Twitter is following too many people. I try to keep the number of people I follow down to around 500-600. Lists allow you to create personalised sub-sets of your main Twitter feed, meaning that you better better filter who you see in a particular feed on a particular topic.

I’ve created lists for my friends, scientific sources, news sources, design sources, political sources, and a few others. Some of these I look at constantly (friends), others only occasionally, but it drastically cuts down the signal to noise ratio for me. Of all the things I’m proposing here that will make Twitter useful to you personally.

05. Don’t use the Twitter app

Don't use the Twitter App

A big part of the problem with Twitter is the Twitter app. Regardless of the device, the Twitter app is nothing but the basic – yet incomplete – functionality of the website. It’s just not very good, and seems mostly designed to get you to look at Twitter ads and follow more people. Over the years, Twitter has done a ‘good’ job of killing any unofficial Twitter apps, but there are still a few official and unofficial apps that do a damn site better job.

For my computer, I keep Tweetdeck running most of the time. Tweetdeck allows me to monitor my whole feed, individual lists, searches, messages, and mentions in an easy to navigate interface. With my mobile and tablet devices, there is no Tweetdeck, but there is a close competitor: Hootsuite. While not quite as refined as Tweetdeck, it still fulfills most of the key features, such as allowing me view individual Twitter lists.

06. If you can’t tweet anything nice (or at least constructive), don’t tweet anything at all

This gets into the abuse thing. Yes, I occasionally make snarky comments, but never with the intent to harm anyone. There’s also a difference between abusive language and constructive comments. If I need to explain that difference to you, then I’m afraid it maybe too late… but maybe not.

When I was young, we had a word called ‘tact’, which does not seem to be in common usage anymore. Apparently in the 21st century someone who is tactful and expects others to be tactful is referred to as ‘politically correct’. But tact is something Twitter desperately needs more of.

Before you post any tweet, just ask yourself one simple questions: What do I want the person’s response to be when reading my comment? If you are simply trying to upset them, scare them, antagonize them or are in any other way being tactless, then you are being abusive. If you want to be abusive, then that’s your own look-out, but don’t expect others to treat you with tact if you are not willing to do the same.

6 things to do to stop climbing the prototyping fidelity cliff

“…In that Empire, the Art of Cartography attained such Perfection that the map of a single Province occupied the entirety of a City, and the map of the Empire, the entirety of a Province. In time, those Unconscionable Maps no longer satisfied, and the Cartographers Guilds struck a Map of the Empire whose size was that of the Empire, and which coincided point for point with it. The following Generations, who were not so fond of the Study of Cartography as their Forebears had been, saw that that vast Map was Useless, and not without some Pitilessness was it, that they delivered it up to the Inclemencies of Sun and Winters. In the Deserts of the West, still today, there are Tattered Ruins of that Map, inhabited by Animals and Beggars; in all the Land there is no other Relic of the Disciplines of Geography.” — Suarez Miranda,Viajes de varones prudentes, Libro IV, Cap. XLV, Lerida, 1658

From Jorge Luis Borges, Collected Fictions, Translated by Andrew Hurley © Penguin 1999.

If you haven’t already, go ahead and read the (very) short story in the quote above. Go ahead, it’s important…

…If you are an experience designer, you can’t but help see the story of the empire of maps as a parable the way we approach interface design. Like the cartographers of old, we try to create 1:1 representations of our ideas in static format, even though we know these prototypes will never be able to exactly mimic the real thing.

A prototype is a model of something we want to build or make, simplified to make it faster to test concepts before taking the time and expense to produce the final version. At their best, a prototype is about helping us answer “What If…” questions – “What if the button flashes when clicked?”, “What if we use blue instead of green for the progress bar?”, “What if we blame the sign-up module on the right instead of the left side of the page?” – allowing us and others to actually see what we are thinking.

But a prototype is not the final product, only an abstract representation of it. So what happens when we start spending more time improving the ‘map’ than working on the reality? That’s what I call climbing the fidelity cliff.

The ‘fidelity cliff’

There is a consistent problem with all forms of prototyping that I have run into again and again. Most design projects start out with a bit of ramp up time (see image below), and then progress along at a steady pace, improving prototype and concept fidelity steadily over time.

The fidelity cliff starts at the point where you sop asking “what If…?” questions and start spending more time to improve the prototype’s fidelity than on improving the actual development versions fidelity

There is a point, however, at which the amount of time you spend to refine your deign begins to increase faster then the improvement of the fidelity of the prototype. In other words, you are spending more and more time, for less and less usefulness. You spend more time making minute adjustments to placement, to colors, to menu name options, to all of the little details that to try and make the design looks exactly what you want the final product to look like.

The base of the Fidelity Cliff is the point where you start spinning your wheels in client and team meetings trying to create a perfect prototype rather than getting on with the actual development. It’s the point where you stop asking the “What if…?” questions and try to use a prototype to answer “How…?” questions.

What causes the fidelity cliff

Over the years, I’ve found three main reason designers start to climb the fidelity cliff:

Desire for pixel perfect deliverables

At the risk of invoking the wrath of Adobe, I have to tell you that Photoshop is not the Web. Neither is Illustrator, InDesign, Sketch, or even more dynamic tools such as Macaw, Just in Mind, and Azure. They can represent the look and to a limited extent the action.

However, just like trying to make a 1:1 map, you are fooling yourself if you think they can perfectly represent the final product. Perusing this goal leads to a lot of wasted time with little to show for it.

Thinking all experience design questions can be answered in the design phase

We want our designs to be “bullet proof” when they get to the developers but my experience time after time is that there are just some questions that cannot be answered until the rubber hits the road.

Thinking static prototypes can fill in for temporal designs

No matter how hard you try, a paper prototype will never be able to answer “What if…?” questions about temporal designs (see image below). Oh, you can talk about the ideas, create static interfaces with all sorts of labels. You can even story board dynamic and temporal ideas out, but you can never truly prototype the idea in order to test it.

The three types of prototypes: static prototypes are great for showing the static design, so-so for dynamic design, but fail completely when it comes to showing temporal design

How to avoid the fidelity cliff

You can never completely eliminate the prototyping fidelity cliff, but you can move the base further down in the process and know when you have reached it in the project (see image below). To do this, the UX profession will need to start to completely rethink how we work, moving away from what were tried and true methodologies to more, dare I say it, lean and agile methodologies.

The aim should be to move the fidelity cliff rather than eradicate it completely

Here are a few ideas to get you started on your path.

01. Forget ‘pixel perfect’ during the design phase

No, this does not mean you get to be sloppy or only create rough designs, but you should know that you are not going to hit every possible design option with perfect clarity. Instead, working on close is close enough and then rely on the techniques below to get the development version to pixel perfection.

02. Iterate, but set time limits

Part of the churn and spin comes when we don’t set hard and fast deadlines for ourselves. The story goes that Leonardo DaVinci worked on the Mona Lisa for over 15 years trying to perfect the work of art, but was never truly satisfied. He was caught in a perfection loop, iterating to an imaginary perfection that does not exist. We are not artists, though, and we need to produce something we are satisfied with in the time we have.

03. Set the scope (and don’t creep)

Setting clear objectives for the project, milestones, and sprints is imperative to making sure you have the time you need to iterate, without getting caught in the perfection loop.

04. Talk and make notes in place of detailed deliverables

I don’t know how many times projects spin their wheels and derail simply because the team members won’t just walk over to each other’s desks and have a conversation. Don’t worry about creating beautiful deliverables, worry about communicating using the most direct, effective, and quick ways possible.

05. Create Style Guides

A style guide can be worth a thousand visual comps. It should the most up-to-date agreed upon rules for how the product is to be put together. Need to change the format for how paragraphs appear? You could change it in dozens of comps or simple change the rule in the style guide.

06. Designers need to learn HTML & CSS – developers need to learn UX

If you are a designer and you don’t know how the basic core web technologies work, then you are doing a disservice to yourself and your audience. You will overlook new idea, new patterns, and best practices.


If you are a developer and you do not understand the basic tenets of experience design, then you are doing a disservice to yourself and your audience. Even the best design interface will cause frustration if the developer doesn’t ensure that attention is given to making sure the product works well. We are all UX professionals!

6 seemingly innocent questions guaranteed to kill creativity

I’ve been in a lot of design critiques, stand-up sessions, and reviews over the years, and began to notice something: there are some questions that get asked over and over again that are time-bombs ready to explode and kill creativity in the project. They are not always asked using the exact same words, but the meaning and results are the same.

The problem is that most of theses questions put the person they addressed to in an immediately defensive position on something that is usually a judgment call. This can be hard to deal with because questions like these almost immediately feel personal.

To help you out, I’m translating the questions into how they make you feel, identifying the problem with them, and then helping you construct a good answer.

01. Why didn’t you do it this way?

What it feels like they are asking: Why didn’t you do it this way, you idiot?

Image credit: Howard Ignatius

The Problem: Maybe you thought about the solution they are proposing, maybe you didn’t, but unless they know that you did from previous discussions, this is a kind of “Do you still beat your wife?” question, where any answer indicts you. It assumes you considered their great idea and discarded it like trash.

The Answer: Recast the question as a more friendly-feeling, “Did you consider doing it this way?” If you did, explain why that solution didn’t work. If you didn’t then the answer is, “I didn’t consider that idea. Why do you think that would work better?” and the conversation can continue around that as a proposed idea rather than why you did or did not think about it.

02. Do you have any research or data to back that idea up?

What it feels like they are asking: Do you have anything to validate your ideas, or did you just pull them out of your ass?

Image credit: janneke staaks

The Problem: When you’re ideating (a fancy term for quickly coming up with ideas), there’s not time to stop and think “is this a good idea or a bad idea” – the point is to just come up with ideas and then do the research later.

The Answer: Depending on where you are in the the process of developing your ideas, you will need different amounts of research to back you up. So, if you are just throwing ideas around, or in the early stages of development, answer with “no, not right now, but let’s see where this leads before we bury our heads in data and research.”

03. Why don’t our competitors do it that way?

What it feels like they are asking: Why do you think you are any smarter than our competitors?

Image credit: Jessica Cross

The Problem: Innovation does not happen by playing ‘me too’ with your competitors. I once spent months arguing with a product manager over the placement of a travel booking module on a page. The most popular sites put it on the left, but, since the main value of our site to the audience was travel stories for inspiration, I wanted to put it on the right and use the more immediately viewed left side for content.

After extensive testing I showed that the change I wanted to make had no effect on customer conversion, but did increase audience engagement with content. The product manger held to his guns, arguing that our competitors were larger and therefore had more experience at this than we did. The module stayed on the left. A year later, our competitors moved their booking modules to the right side of their interface to increase engagement with content. Sigh.

The Answer: Your best bet is to come back with research and data to support your cause, but, as I explained, that will not always do the trick. Be prepared to wait for more evidence or even try to talk to your competitors if you can to see why they did what they did. You may be surprised to find out that the reason they are not doing something a particular way is because you are not doing it that way.

04. Did you know that [information tertiary to the point you are making]?

What it feels like they are asking: Did you know that I know more than you do?

Image credit: Al King

The Problem: If someone isn’t interested in what you have to say, then they will do anything to change the subject, which immediately derails your creative train of thought.

The Answer: Ask yourself: is it you or is it them? Life is too short to talk to people who are not interested in your ideas. This is problematic on a project team where you may not have a choice, but don’t beat your head against a wall. Try to figure out ways to make your ides more interesting or to explain them in more concrete terms the person you are trying to communicate with can understand.

05. When do we get to the critique?

What it feels like they are asking: When do we get to tear apart this self evidently awful idea?

Image credit: Ani-Bee

The Problem: This one comes in a wide variety of more subtle versions, and the ‘critique’ can also be cumulative, like pin-pricks, each drawing a little blood until you look down and realize you are bleeding to death.

My agency was working on a web site for a scientific research company, and I was the UX lead. They also hired a third party consultant – basically to keep an eye on us – but she had to continually prove her value to the project. We were already weeks into the architecture for the site when she comes to her first meeting to review a second round of wireframes with us. Before we can open our mouths to even present our work she opens with, “When do I get to criticize?” This chilled the project team, and set a contentious atmosphere for all future meetings.

The Answer: Generally people who ask questions like this are bullies. The good news is that bullies can be the easiest to manipulate. They want the first word and they want the last word. So, let them. Let them talk themselves silly. If they ask questions, tell them you are writing this down and will answer once they are done with their entire critique.

When they are finally done, get on with your explanations as planned, addressing their questions as possible, but don’t let them suck you into an open debate. Instead, when they ask something, tell them you are getting to that explanation. Guide their rebuttal to the points important to you.

06. Can we try that in the next version?

What it feels like they are asking: Why would we waste our time on this?

Image credit: McKay Savage

The Problem: You probably will not get this into the next version, or even the one after that. This is generally asked as a stalling tactic, basically getting you to agree to assign your idea to the scrap heap. Again, this is often a symptom of the Agile/MVP environment that many development teams are working within these days.

The Answer: Pick your battles wisely. Is this one worth it? If so, then your answer should be “no, it needs to go into this version.” But be prepared to back that argument up and probably give up something else up in its place.

Statements or questions, it’s all the same

Most of these questions also have their statement counterparts (e.g. “We’ll do that in the next version”), but how it makes you feel and how to respond stay pretty much the same. Keep in mind that when dealing with someone else making a firm statement, though, you need to be prepared to be more firm in your own response.

This story has also been published in Medium, where you can add comments and feeback.