Recently I wrote a new piece of the Women In Tech Blog stating that it’s time for women in the tech sector to be proud to call themselves “women in tech”. By not doing so, we are hindering our ability to create a community that we can relate to, be a part of, and that can move our professions (numbers, salaries, etc) forward. Give Proud to be a Woman in Tech a read (even if you aren’t a woman in tech) and let me know what you think!
This week Johnny Holland Magazine published an awesome article by TheLadders.com Director of UX Jeff Gothelf. In it, Jeff talked about how TheLadders implemented an Agile methodology in their company. It’s a great read, so make sure to check it out: Beyond Staggered Sprints: How TheLadders.com Integrated UX into Agile.
There are several things that I want to point out about the article as well as how TheLadders integrated UX with Agile. First, the article points out that they failed. In fact, they failed several times before they were able to gain momentum and create a functioning system. They admited to their failure, but they didn’t let it deter them. Instead they learned from it and tried again.
Second, and more important, is that Jeff actually describes in detail not only the steps and attempted processes the team took, but also the tools that they used along the way. He also describes when and how they used these tools as well as what worked and what didn’t. This is exactly the type of read I was hoping to see more of when I wrote Issues with Agile, UX and How We Talk About It!
Thus, hopefully we, as a community, will all use this type of article for inspiration. UX can be integrated with Agile. You WILL fail along the way, but you will also learn. The more that information, stories and tips like this become available to us, however, the more we’ll be able to learn and the less we’ll make the same mistakes. Maybe, just maybe, we’re on the right path. Thanks to Johnny Holland and Jeff for starting us off!
My latest Women In Technology post, Let’s Raise These Numbers!, is live. In it, I write about recent survey results from the 2009 A List Apart web survey. As I was reviewing these results, I noticed the lack of women in the industry (only 17.4% of respondents were female) and decided to try to raise some awareness in order to boost our numbers. I hope you enjoy the read!
As a UX designer, I’ve been working in agile development environments for almost 4 years. I know that might seem like a long time since agile still feels new, but I had a great learning opportunity when I was introduced to it back in 2007. At that time, I, as well as other UXers in the company, were constantly trying to understand, practice and tweak the ways that UX was a part of the “system”. I found my experience to be hugely rewarding and I would recommend the approach that we took to almost anyone.
These days we’re pretty lucky in that there are a lot more people doing agile and doing it well. We have groups such as the Agile Experience Design meetup that bring speakers and presenters in to talk through the methods and tools that make them successful. This has been a big win for experience design as well as the agile movement overall.
Over time I have been to this meetup and other meetups and discussions around the topic. The speakers are usually very knowledgeable and do a great job laying out the tools that one needs and the things one can do to find success in their agile systems. I have, however, noticed a trend in these discussions. Overall, no matter what meetup I’m at, or what knowledgeable expert I’m talking to, I consistently hear the same line. That being something along the lines of “Here are the tools you can use in Agile and you’ll need to determine what scenarios call for which tools. Sometimes you use this and sometimes you use that. Agile is flexible, yadda yadda.” Ok, I get it, and I agree. But I feel like there is a big gap in knowledge here. How does one determine what tools go with what scenarios? More simply, how do I know what tools to use when…. and how do I make the right decisions for using them. What is the process of determining the right tools?
In these discussions, it seems like we are just supposed to know. For example, here is a new deliverable called a half-wireframe-half-sketch-half-documentation-thingy-guy. You might need it, you might not… it all depends… then we move on to the next topic. I’m going to argue that in order for UXers to become completely comfortable with this methodology we need to talk more like “here is a new deliverable called a half-wireframe-half-sketch-half-documentation-thingy-guy. You use it in scenarios when there is a need to quickly and visually document the interaction, but not a need to capture the visual treatments at this time. You will also need it when you are passing along the work to offshore developers and testers. I wouldn’t necessarily recommend it for executive sponsor sign off, but if you find that your sponsor does bla bla bla go for it. and etc”.
This now turns the information into usable and digestible pieces. Here is the theory, here is how we apply the theory. Basically talking in this regard allows the listener to embrace the tool and empowers them to use it to the best ability. Now, I’m not calling for hard fast rules here. I get, and love that agile is ever changing and flexible. But by establishing some sort of knowledge transfer when we talk about our successes we are providing a foundation for others from which they can create their own flexibility of tools and processes.
So, in short… can we please change this discussion? The next time you get up to speak about or go to listen to an agile and UX talk, talk about how we actually use these tools and more importantly how we go about making the determinations for use. This will allow us to pick up our pace when it comes to this newer system and help us to better integrate with our development partners… thus leading to products that more closely follow our designs and are ultimately better for our users.
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.
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.