A Project Guide to UX Design: For user experience designers in the field or in the making by Russ Unger, Carolyn Chandler
Last week my first post as a guest blogger on the Women in Technology site went up. In Seeing IT Through a Different Lens: User Experience, I write about how being in technology does not mean you have to code, manage projects, be an analyst or know hardware. I’m hoping that this post opens up some eyes about what it means to be a techie. Take a read and let me know what you think in the comments below.
Last night I attended the May 2010 New York Tech Meetup. For those readers that don’t know what that is, it is hands down one of the largest if not the largest tech event in New York City. It is held every month and brings startups and small businesses together to receive announcements about what’s going on in the tech community, and view demos of what other web startups are building and trying to get funding for. This is a huge deal, last night even the FCC was there with announcements and I have seen the mayor’s office there in the past.
During last night’s event, I couldn’t help but note several different ideas for blogs posts, and was planning on combining all of them into one redux post. I think, however, that that would dilute each topic’s importance, so multiple posts it is. Today, I wanted to talk about the lack of UX representation at these events, and how truly sad that is. I may have written about this before, but the thought and emotion behind it struck me again last night, so I felt the need to expound upon it.
As a user experience designer, I personally love attending NYTM as often as I can for several reasons. Most important is that going enables me to communicate and meet others who work in digital but aren’t in the user experience space. Just me being there and talking with others enables the tech community to be more aware of what UX is and how it can be helpful to startups and small businesses. Our UX community is a small world, and frankly I think that we look internally for ideas and even new jobs way too much. It seems that we are Obsessed with the Reputation of being known in the UX community or working at one of the big wig companies, more so than actually solving problems outside of our community. When I walk into these demos at the NYTM there are gazillion UX problems that I see (not that these people aren’t trying their hardest and don’t have great ideas and products because they are truly coming up with some amazing things). I can’t help but ask myself why we, as user experience designers, aren’t jumping at the chance to be part of this community. Think about it. If you live in NYC, why weren’t you there last night? Would you be so careless to miss an opportunity to talk with Jared Spool or another well known UXer? I know that Jared and other well known UXers have a GREAT deal of experience, and have taught me a great deal of what I know, BUT have they given me the opportunity to USE what I know. That opportunity lies within your local tech community, whether you want to face it or not.
Last night a number of new website products demoed. I would say about 80 – 90% of them were hiring, and none of them were hiring UX designers. Does that mean they already have someone on staff? No actually it means they either don’t know what we do or don’t care. Why? Because we aren’t making ourselves known… we aren’t even showing up and trying to be a part of the tech community! These start ups are the future Twittters, Foursquares, Facebooks, Google, etc. These are the ideas at the start of the success, and we are not included and it is not because they don’t “like” us. It’s because we choose not to be included. We are excluding ourselves from the technology world, then wondering why nobody cares about UX.
My message is simple. It’s time to stop whining that no one gets what we do and it’s time to stop being frustrated about it. It’s time to show up to the court, ask who needs an extra player and show off the madd skills we have and how we improve products and businesses. It’s our time… you got game?
In talking with fellow UXer Shaun Rance, he brought up a great point regarding user experience professionals and the need for them to learn new online technologies. I’ve been reflecting on this point for some time, and couldn’t agree more with his reasoning for doing so.
His thoughts were basically: if we don’t learn new technologies, what they are, how they work, and really understand them; then we as UX professionals cannot help our business and developer colleagues understand the most appropriate ways to use these new technologies. Without our expertise and filtering, these new technologies will be implemented just for popularity or other random reasons and without thought given to the experience they provide to the user.
A great example that Shaun used involves all of the implementations of augmented reality that we’ve seen as of late. There have been a ton of implementations, but only a few that provide great experiences and are, more importantly, useful to someone. Imagine that there were more UX teams working in this space and helping to craft the experience behind how the technology is used! Now I know that a lot of times the technology is invented before we are brought in; however, closing that time frame, from invention to UX, is done by us learning more about the technology as soon as we can.
Personally, in my work, I see the benefits of learning new technologies all the time. There have been countless meetings when a client has told me about a technology that is just perfect for what they are trying to do. More often than not, it is not (And they usually don’t always know what they are trying to do… the contents of a future post perhaps). I take it as my responsibility as a user experience designer to be ahead of the curve in order to talk these people off the ledge and show them how the technology they are looking at should be used, and how that either matches or does not match their needs. Usually, they see the value in what I’m saying, and work to change their implementation plan.
The main point of what I’m trying to say is that we should be ahead of the curve as much as we can be. We need to be reaching out all around us in order to find new technologies that people are using and how they are using them. How those uses work and how they fail. Ok I know what you’re thinking, “Lis, we already do that!” Yes, maybe (hopefully) but do you know why? Well that’s the reason why, not just because you like technology or digital, not just because you love designing for users and want to see what’s coming next, but most importantly to be able to help stop the poor use of these incredible technologies that are introduced to us daily. Doing so enables you to provide enjoyment to your users, and to be great at what you do.
In talking with her about this series, fellow UXer Cassie Carter presented me with the number 9 reason that your developer hates you: I’m smart, I know about the web and users, but you don’t take or make the time to listen to my ideas.
I remember back in the earlier days of my career, and still at times today, I had to have a face of stone when describing user experience and its importance. I could not crack, could not let anyone see me back down. I was the user expert, and had to prove myself as such day in and day out. Basically, I thought and was told that that no one else ever thought about the user like I did, and if I didn’t represent the user to the fullest, then no one would. Why then, would I take the time to listen to what someone else had to say about user experience? They hadn’t taken the time that I had to learn all that I knew. They were just trying to get the project done on time, or stay within scope or budget. These people could never truly come up with any purposeful comments or ideas regarding UX.
That was 5 years ago, and things have most definitely changed. It is true that most people don’t think about users and user experience the way we as UX Designers do, but that doesn’t mean they don’t think about them at all. People are more and more aware of the importance of what we do everyday, including your developers. And, keep in mind, developers are really, really, really smart people who come up with really great ideas. If they weren’t, we wouldn’t be so intimidated by them. Developers scour the web day in and day out just as we do, if not more than us. Your developer is finding new trends and ideas and relating these new items to their work all the time. This makes them a fountain of knowledge from which you can pull. However, most of the time, we don’t always take the opportunity to listen to these ideas or put ourselves in positions in which we talk to our development team often enough to hear these new ideas. It’s time to open up your ears.
To bring it all together, the age where we have to think we’re the only ones that can come up with good ideas regarding experience is over, or waning very, very quickly. We, as UXDs, have been exposed. Our secret is out and other people are on to us, and that is ok! Bring your developer into brainstorming sessions or random discussions. Start to extract the knowledge that they have and use their powers for your own good. You’ll be surprised at how much more awesome the experiences you design will become.
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.
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.
This post is the 6th in a series I began called Reasons why your developer hates you. In this series I try to bring to light frustrations from the development world. For this week’s reason entitled “You’re not learning anything about this technology” I go back to a comment that Chris Avore made on the post for Reason #3. Check out the comment here.
Chris’ basic point is that UXers should have some sort of general knowledge regarding technology. When I started to think about this more I began reflecting on comments that I’ve heard from developers in the past. Or, simply, the look on their faces when a UXer has gone to them for the 15th time with the same question and is still not making a connection. I always tell people that in order to be a good UX designer having a technical background isn’t necessary. It is extremely helpful, but I wouldn’t call it a requirement. I would, however, say that having the ability to pick up technical knowledge is a must. And not just having the ability, but the willingness and interest as well. Here is an example:
Jane, a UX Designer, goes to Jamie, a developer, and asks her if her solution is possible. Jamie tells Jane that her design isn’t easy because of ABC. A few months later, Jane returns with a similar design, even though Jamie took the time to explain why the design isn’t easy, and asks if the design is possible. Did you even take in any information that Jamie said Jane?
Bottom line is that there are UXers out there that are highly intimitated by developers and their realm… and that is to be expected. But if these UXers brush off technology as “the developer’s job” they are doing everyone on the team AND their users a huge disservice. It’s easy to ignore something that is a challenge, but this makes the project and later similar efforts inefficient and causes the team to question your credibility, and sometimes the credibility for all UX designers and the value they add. I’m definitely not saying that you need to go out and learn to code. I am saying that you should take an interest in learning about technology and how your designs fit into your technological constraints. This is an invaluable exercise that will no only strengthen your relationship with your developer, but also strengthen the quality of your work… which can only help the end user.
A few weeks ago I started a series on Reasons Why Your Developer Hates You. Check out the first post and others to get some ideas on the reasons I’ve brought up. Today is reason #5 why your developer hates you: “we don’t like when you make us do work”.
I got this statement from a developer colleague & friend in what I thought was a joking manner. And I think it some respects it was meant as a joke, but then when I started thinking about it further it made a lot of sense. I don’t think the phrase, however, captures it all.
We’ve gone through several different reasons why your developer hates you, and those all contribute to today’s point, which I think is a very valid one. Think of it from a UXer’s perspective. You’ve been a part of this team, done a ton of work brainstorming, contributing ideas, forming strategies and solutions and then, after finding at least some success you move on to a different focus. Out of nowhere you get an email or call…. “I need you to update the *insert deliverable here*. Bob thinks that we should do XYZ instead.” There are many different examples for what I’m trying to demonstrate, but basically someone, somewhere has decided that the solution that everyone has agreed upon needs to be changed. This can be a good thing in our view if it’s based on user research, new information, etc. However, when it is based on opinion or “gut feel” then it’s extremely frustrating.
I’m going way out on a limb with this one, so developers *please* provide feedback. But I’m assuming that this is parallel for developers. How so? This is a little bit harder to grasp, but as we’ve talked about before, developers have standards & best practices that they follow in their field as well. When we come to them with a change that is based on opinion (even if it is not our own) then it screws up the whole vision they have for their solution (sounding familiar). This is causing more work yes, but it is also causing “useless” work. Work that will need to be redone later on to improve this solution, which was put in place to improve another solution, and so it goes. But if we brought forth a change based on system research (i.e. I think this will decrease page load by 1 second based on this article) I don’t know that there would be this overall feeling of “stop making me do work”, because this work would not be “useless” but would prove helpful and be based on some sort of background and knowledge.
The idea that someone is mad because you make them work is valid, but not someone who’s hugely talented like my friend that proposed this idea. There has to be something there that isn’t contributing to the greater good that makes someone feel put out.
So I would love to hear thoughts on what you think it is… developer or UXer or both. Why do developers, better yet talented professionals in general, hate when you “make them do work?”
Ok folks it’s time for reason number 4 why your developer hates you. That is “We don’t like when you change your mind… especially when we don’t hear about it”.
Ever been knee deep in some really great experience work? Ideas are flowing; flows, screens and goodness is coming together. You have a great and, more importantly, usable solution and then you present it to the business, and you hear “By the way that requirement, that requirement has changed.” “Really, when?” “Oh some time ago.” “Oh, well why?” “well bla bla bla bla.”. Yes, I’m sure we have all been there, and probably all consumed a good amount of alcohol after said meeting. There is nothing worse then being a proactive designer doing your best not to “slow things down” (because that’s what design does afterall) and getting kicked in the gut with miscommunication. Nothing worse perhaps unless you are developer designing the code to support a UX design solution that has changed without your knowledge.
Developers go through similar processes in creating their solutions as we do as UX designers. Whether in a formal or informal way, they take the current development environment, future plans for this environment, other projects and timeframes and put together a design for how to lay out their code. As you are presenting your design, their brains are working to figure out the best way to stay within their constraints while addressing your requirements. They may start actually creating code (especially in an agile environment) to come up with the perfect solution. And while presenting that code (maybe in a prototype of sorts) they hear “By the way that screen, that screen has changed.” “Really when?” “Oh some time ago.” “Oh, well why?” “Oh because bla bla bla.”. You know the feelings and thoughts that come next because you feel and think them yourself. Why the %$#%^ didn’t you let us know?? Why did this have to change, why can’t we do it this way?? This is crap I don’t feel like part of the team. Etc, etc.
We need to treat our developers as partners. We need to go to them right away if there are shifts in our thinking. This is obviously much more essential in an agile working environment, but all the same should be practiced no matter what. Software development is a balance between many different skills and expertise, but should not be a war between them. You know how you feel when requirements are changed, so don’t allow others to feel that way because you’re not willing or don’t think to communicate well. You as a UX designer promote and stand up for the user, but don’t forget to promote and stand up for those that allow your visions to come to life. The lesson of this week is to communicate your ideas and changes to your development team. Let them know why your solution is changing and listen to their ideas and thoughts on the topic. And most importantly, let them know as soon as possible, so that they can revise their design.
Next time: We don’t like when you make us do work.
Tech 
UX 
Developers 
Development
This is the third post in a series devoted to helping UX Designers see where the tension begins between them and their development team. You can read the first and second posts here, and remember if you have suggestions, ideas, other reasons why you think there is tension please, pretty please, pass along your thoughts.
But now let’s talk about reason why your developer hates you numbero 3. I tagged this in the last post as “You don’t really know what I do and don’t take the time to care.”, but I’m not sure that’s the route I’m going to go this week. First let me explain where this idea came from. In my roles both past and present, I’ve seen designers get extremely frustrated with their developers. “Why can’t you just do blah blah blah? I don’t get it it should be easy!”. And the developer says “It depends. etc etc”… sound familiar? Looking at this transaction of words and ideas I can’t help but think about when people ask me what I see as whacky or “it depends” questions about the user experience. If I had a dollar for everytime I’ve heard something like “Why can’t we just throw blah blah on the home page or blah blah blah in the global nav or blah blah”… well you get the point. No one took the time to really understand my role and its importance and constraints. Isn’t that how we are treating developers when we get frustrated with them for working within their role and constraints?
There are several bits of information that we as UX designers may not be aware of. First, developers are working within the role. What does that mean? It means, as a developer I’m trying to stay within some role boundaries and that can lead to “it depends” answers. Solution ABC would be an easy thing to code if we were working on this technical platform, but we’re not, we’re on that platform and in that environment solution ABC is much harder and more expensive. If we want to take the entire site and move it to a new platform then we can do solution ABC easily, but we’ll also be spending millions of dollars. Also, a developer may have expertise in one code base, but not in another. In other words I know all about the code that serves up the blue screens, but the green screens are not my cup of tea so I’m going to tell you what I think, but it really depends on what the green screens team says. And lastly, they have senior developers and tech leads who oversee their work as well, and although a developer might think that solution ABC is easy, their lead is telling them that they must do solution ABC another way… which is more time consuming and therefore more expensive, however it fits better into the design of the code base. The design of the code base is important because it ensures stability of the website and efficiency.
This leads to the next bit of information that UX designers may not be aware of. Developers work with, in some cases, some severe standards and constraints. So, just as we need to work with existing pattern libraries, standards, or experience themes, they also need to work within limits. Page load times, error logs, calls to the back end, the amount of code they put on the servers… they are only allowed by their superiors as well as other units so much leeway in these areas and we need to be aware of this and take this into consideration when compromising with our technology partners.
I would suggest that you talk to your developer about their role and any existing constraints. Do some research, ask them questions, or even interview them informally. This will only inform your design process, and help smooth the rocky road to product delivery. Be warned, that this is not to say that your creativity should be imposed on. By all means go all out and design the ideal solution, but when it comes to scoping a design effort you’ll be much more informed as to what can and can’t be done in the present time, and what will be needed on the technical end to get to your end goal.
Coming next week: We don’t like when you change your mind… esp when we don’t know why.
Tech UX Developers Development