Last night I had the honor of attending the RefreshNYC meetup in Brooklyn. While there, the group had the opportunity to hear Gabi Moore speak about the tensions between designers and developers. Gabi put together an awesome presentation and the discussions that followed were extremely informative. One point that was made by fellow UXer Oz Lubling inspired Reason #8: I don’t need you so get out of my way.

As designers (visual, UX, etc) we know that we need developers to see our creations come to life. We can design the best solutions in the world, but without someone to transform our designs into computer readable format and then take that format and place it on a server, our designs will never see the light of day. Therefore, as designers we’ve “bought in” to the need for developers.

Developers, on the other hand, do not always see the need for designers. After all what do we contribute to their process? They don’t physically need designs to fulfill business requirements and get the product out the door. They are users of technology as well, and know what users want just as much if not more than any silly designer.

More specifically from a developer’s point of view, all we do is make their development time longer and their solutions harder to implement. Let me explain further. Developers’ schedules and deadlines are just as tight if not tighter than ours. They are also often not involved in scoping and thus are usually given an extremely short timeline to develop all of the functionality that the business wants. They’ll begin to design how their code will need to be structured in order to meet these deadlines. They try to find the simplest most efficient way possible to get to the right solution, on time. In walks the designer with these wonderful wireframes and comps that are nothing like what the development team expected to develop! These designs are usually good, even great. Anyone can see that these designs would make a better product. However, anyone can also see that they will take MUCH, MUCH longer to develop and test. In fact, why do we need these designs anyway? We already figured out a way to fulfill the requirements on time and now this is getting in the way!

Ok, so one can see the struggle. Even though in reality, the developer probably knows that your solution is a better one for the user, the pull of meeting a deadline and coding based on the “code design” is more important. After all, that is the developer’s main job and priority, to create a bug free product that meets requirements in the time allotted. Now, I’m not saying that this makes it right for developers or anyone to ignore or argue with us about our designs. I am saying that as a designer, be sensitive to what the real issue is. It is usually not with the work you have done. It might take a little more effort on your part, but pay attention to what the developer is really anxious about and use that to compromise your way closer to your solution, or an even better collaborative solution.

To be clear, I’m also not saying that you should let timeline always rule the team’s end product. Let’s say in working with your developer you realize that their main pushback is not with your design, but with timeline or budget. Then it is time to have a conversation with the business and project management about these two items and see if the constraints they poise can be shifted. The important thing is that by really understanding why your developer disagrees with your solution, you can alleviate the stresses between the two of you, and enable progress instead of constant tension.

As most of you know, I’m constantly learning elements of therapy & counseling and can’t help but relate them to our work as UX Designers. My most recent lesson came from a discussion around Freud’s countertransference. My friend brought the term up to me and since I had never heard it before, I asked him to describe to me what it means, and how he uses it in his work. Transference is, in my short, less informed point of view, when a patient redirects the feelings they have for someone or something to their therapist. Thus countertransference would be when a therapist redirects feelings that they have for someone or something on to the patient. My friend explained that this is one way that he uses to understand his patients better, by relating them to other patients or people that he’s met or worked with before. For example, if the therapist had feelings of unease or distrust for a past patient and then finds himself redirecting those same feelings to a current patient, he can get a better understanding of who the current patient is just by recalling details of the past patient’s character. This is not to say that he basis all of his diagnosis on past patients, but simply uses countertransference as a way to know patients better, especially when they first start seeing him.

Whew… So what does this very short lesson in psychoanalytics have to do with UX Design? Well the first term that came to my mind was empathy. We always say that we should have empathy for our users; as in the capability to share their emotions and feelings. This is different than transferring our feelings, but I believe they are related.

When I started to reflect on this topic further I realized that what most drew me in was the idea of taking feelings and thoughts that I’ve attached to one experience and transferring them to another. This is something that we, as UXDs, try to facilitate. That is, getting our users to transfer feelings that they have for tangible products, for people they love, for things or experiences that bring them joy, to the experiences or products that we are trying to create. This, my friends, has truly helped me to clarify my role as an UXD.

Now, the next question I asked myself is, is there a way for me to use countertransference to better understand my user just like the therapist does with his patients? More specifically, is there a way for me to transfer the empathy I’ve had for a past user (maybe one I’ve seen in testing or have interviewed?) on to the users that I’m currently designing for? For example, let’s say, in the past, I interviewed some users in order to better understand their usage of the iPhone. During these sessions, I developed a certain amount of empathy for these users. Can I say that when I design future iPhone applications or designs that I can redirect this empathy in order to better inform my designs? Well it doesn’t really work like that. I don’t know that you can purposefully transfer empathy for one user to another. It’s more of an observation thing. Meaning really being aware of when you’re transferring empathy, and then analyzing why and if it makes sense to do so. Making these types of connections in the brain will enable you to really understand how you understand the user. This is an introspective process, however, it is one that can help us to better understand from an emotional point of view who we are designing for and what their needs are.

The moral: the closer you are to filling your user’s shoes, the better you’ll be able to design for them. Practicing noticing when you are transferring emotions and empathy from past users or experiences on to current ones will help you to know yourself as well as your user better, and eventually close the gap between you and your user; thereby making your designs more user centric, and therefore just plain old better.

In my new post on New York Entrepreneur Week’s Site, How Can Entrepreneurs Learn About User Experience (UX) Design, I try to help entrepreneurs learn more about what we do as UXDs by providing some beginner/overarching resources. Take a read, and feel free to comment with any resources/tips I may have forgotten. Would love to hear feedback!

Over the past couple of weeks I’ve had the opportunity to work on my first mobile web application. For me this has been truly exciting as I’ve always felt late to the game when it comes to mobile. I was quick to reach out to my twitter network for support and resource options. I ate up anything I could get my hands on in regards to mobile design and development, and now have, what my team and I think, is a great paper prototype and wireframe set for the mobile web app that we are planning to build.

While doing all of the reading and research, I couldn’t help but think about the overall concept for designing for mobile which is to “Keep it Simple”. I started to read more and more (most of my reading was from Brian Fling’s Mobile Design and Development book. Buy it. It’s worth it!), and kept thinking “why aren’t we designing everything this way?” Why aren’t we just designing for what is needed to complete the user tasks? Why do we add so much to our designs?

I know this sounds extremist, and I’m potentially just way late to the game, and everyone else has already picked up on this, so just appease me, but why all the fluff? Why do we create all the features that 20% or less of users actually use. In my research, I stumbled across Luke W’s article from late last year entitled Mobile First. I think that Luke is 100% right in this article. Read it over and you’ll see what I mean. The most important point that I took away was point number 2: Mobile Forces You to Focus. Basically, due to screen real estate, one should only design for the user tasks that would be completed using a mobile device. Everything else gets thrown out the window. Brian Fling mentions it in his Chapter 7: Mobile Information Architecture. He says “If something doesn’t support the defined goals, lose it. Go back to your user goals and needs, and identify the tasks that map to them. Find those needs and fill them.”

My question for everyone is: Why doesn’t this extend to the entirety of our web design? Why is it that we add all the other features that don’t map to these needs? I would argue that one reason is probably because we don’t take the time to really define the needs of the user. Mobile, as Luke W mentions, forces us to do so. We should make non-mobile web design the same. We should be hard on ourselves and not be lazy when it comes to really defining the needs and goals of our users even when we have a bigger screen area to work with. This will allow us to design with a focus on what the user really needs. We can and should still make the experience delightful, but that doesn’t mean adding smoke and mirrors. It means adding value. Let’s just keep it simple.

This past winter I had the esteemed privilege to work with the team at AnyClip as their UX Consultant. It was one of the best experiences of my life as I loved working with the highly talented team there as well as the product that they were working on. Finally the new AnyClip Beta is available! Be sure to check it out at anyclip.com. I would love to hear any feedback or thoughts that you might have and I know that AnyClip would appreciate them as well. To give direct feedback to the AnyClip team, use the Feedback button on anyclip.com (on the far left side of the screen). Otherwise, feel free to leave your comments here and I’ll be sure to pass them along. Have fun searching for Any Movie Moment Ever!

After a long hiatus, reasons why your develop hates you is back! In case you didn’t get a chance to check out reasons 1 – 6 or if you need a reminder, here they are:

Reasons your developer hates you:
1. Your requirements are unclear and incomplete and yet you expect a concrete answer to your question.
2. You bring us to the playing field after the game is over.
3. You don’t really know what I do and don’t take the time to care.
4. We don’t like when you change your mind… especially when we don’t hear about it.
5. We don’t like when you make us do work.
6. You’re not learning anything about this technology.
7. And without further adieu reason number 7 (inspired by fellow UXer Shaun Rance): You don’t know digital.

For most of us, this may seem a pretty far reach. Many UXers work in digital after all. We create websites and mobile applications and immerse ourselves in technology. However, we might not fully realize the amount of work that goes into creating a digital product. “Digital”, as opposed to print or television, is a huge amount of work for most everyone involved. This is not to say that print or television do not include a great deal of work, but in this case it is different work. It is more than just mocking up a wireframe or a comp and passing it along to production. It involves familiarity with the system and with the users of the system. It includes providing detailed instructions on how the entire site or product should work including navigation and more detailed interactions. And not to forget imagery that can be easily consumed by the development team. Also, depending on your team structure UX digital hand off can include front end code (HTML, CSS< JavaScript) that is valid as well as reusable. The list goes on and on.

So, why does the fact that you don’t know digital frustrate your development team? Simply because it makes their job much harder by giving them much more work. This slows the entire process down, and is highly inefficient. Imagine that one hands off imagery that is not properly sized, is unusable and is in a non-web friendly format. Your developer now has to either contact you and get you to redo the work in a format that works, or has to figure out how to size images themselves, which could affect the quality of the images. In addition, some UXers might not think to map out all the interactions that could happen on their website in extreme detail (and I mean detail like saying “hovering over the link invokes this flyover which should disappear in 2 seconds”) but if you don’t, who do you think will? Your developer? Do you think they have time for that? If we want to see our design developed properly and work the way we have in our heads, we have to enable our developers to be successful by providing them the deliverables they need.

What does it all come down to? If you truly want to be a good interaction/user experience designer in the digital world, learn the process. Know your role from start to finish (and yes, you should be involved in the project from start to finish). Understand the deliverables that you are responsible for and the level of detail that you need to provide. This is invaluable, time saving work that not only makes your entire project team more successful, but also, in the end, makes your user’s experience more delightful.

In my latest post on the New York Entrepreneur Week website, I talk a little bit about some more similarities that I’ve observed between UX Designers and Therapists. To find out how I think they relate, be sure to check out the newest post: How User Experience Designers are like Therapists. As always, any feedback is greatly appreciated!