A while ago I started thinking more about different wireframing tools. I subscribe to the several wireframe focused feeds, and have begun realizing that I never really read them anymore. And, I was also seeing that although there were some really cool free tools coming out, that I never really have the need for them since I use any one of the more mainstream tools to get my work done.

So, this got me wondering… who out there is really using these tools. They must have some kind of market. If you or someone you know goes out and tries these different tools, I’d love to hear about which ones in the comments. Also, I’d love to hear more about when you use them. For instance, are they just for a quick sketch, or do you make finished client deliverables using them. What are the reasons that they are more appealing that other tools? Is cost the only option?

If you have, do, will use different tools besides the biggies (Illustrator, Fireworks, Visio, Omnigraffle, Axure, Balsamiq) I’d really appreciate to hear from you! Even if just to tame my curiosity .

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!

I have a confession to make… it’s not easy to say and it’s even harder to admit. I do not want to be an interaction designer forever. In fact, I don’t even really enjoy the act of detailed designing as much as one “should”. Over the past couple of months I’ve begun to recognize the things that I really love about my profession and those that I could do without… and interaction design is one that I can do without. Of course, I’ll need to explain further.

First, let me define what I mean by interaction designer. I’m talking about the people who look at and absorb a strategic vision (either business, tech, or design vision… or all three) and then think about how that looks on a screen/interface. We think about the screens that are needed, and what information/content displays where and when and then we put that all into some form of documentation such as a wireframe. What I’m saying when I state I don’t want to be an Interaction Designer forever is that this part of my job, the part where I’m just focusing on the details of the interaction, is one that I can do much much less of (notice I decided to switch from ‘do without’ to ‘do much much less of’).

Now, this is not to say that I don’t at times enjoy this work. On the contrary, it is the majority of what I’m working on right now, and I’m having a great time creating an awesome experience. But, there are times and days where I say to myself “this sucks”.

Because I’m saying that to myself, I have to ask… what is it I’d rather be doing? This job is awesome, so why am I saying these things? Thus, what are the parts of my profession that I do want to do much, much more of. For me, I personally love working on a conceptual and strategic vision. The other people can figure out the screens and then I can tell them if that fits with the vision, but leave the screens to them. I love seeing the big (really big) picture and enjoy matching that up with user research that I’ve done and behaviors that I’m seeing. This is what brings me satisfaction… so why am I so hesitant to make this confession?

In short, as a member of this awesome community, I’ve always felt that I need to do and love everything that we are responsible for. I need to love research, scoping, design, drawing, etc. I’m scared that if I don’t love doing interaction design, then I won’t be able to call myself a member of this community. But, that is just silly. Today I’m taking a stand and saying… I’m just not down with the interaction design as much as I use to be. I wanna play with the other kids and only come to this sandbox from time to time. And you know what guys? That is OK. That does not make me a traitor or any less part of this community that we’ve worked to build. It just means that I have a better idea of what slice of the pie I want to work with, and brings me closer to where I want to and can contribute the most to this awesome thing that we call User Experience. I encourage you to also think more about what it is you love and hate about our world. Making these observations about yourself can help you focus your career and in the end, make you a happier UXer.

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.

I just wrote a new post for the Women In Tech blog touching on an article that appeared on Mashable earlier this month. The idea behind the post is that part of the reason that women feel that we are lacking support and influence in the tech field is because we aren’t taking the time to look around and really see how our population is represented. It’s an interesting take on the debate, and one that I’ll be sure to think more about in the near future. Give Thoughts on the Women in Tech Debate a read and let me know what you think!

Some time ago, I started to think more about writing and how it helps our careers as UX Designers. To read more thoughts check out The Importance of Being a Better Writer and Writing and UXD. Today, I write about yet another instance where writing, better yet communication overall, can improve our work.

Some months ago (yes, it has taken me that long to post this idea), I read another article on the UX Leadership Journal that got my wheels spinning. The UXLJ is a site dedicated to talking about and promoting leadership in the UX field. If you’re someone that is sick and tired of UX not being respected in your organization, or just someone that is looking for thoughts and ideas on where we are and where we are going as far as leadership I would highly recommend checking it out.

The article Understanding Influence by Jess McMullin really drives home how influence is one of the top ways that we’ll become better leaders as well as essential to organizations. It makes total sense, the better influencers that we become, the more we’ll spread our ideas and talents and the more we’ll be needed to lead at a higher organizational level. In this article, Jess shares an infographic that describes the internal factors that a person has as well as the external factors that can be manipulated to influence the internal. The point of this post is to examine how writing contributes to those external factors.

The idea is that writing makes us better communicators. As does drawing, talking, and anything else that helps us practice how to express ourselves clearly and cohesively. I am talking about an active approach to trying to communicate better, and practicing writing is one way to do that. So, the formula is this if I can write better, then I can have more connective conversations with my co-workers/users which enables me to have the skills to influence others.

Ok, aside from just writing better, influence is huge… so try to communicate better. Instead of getting frustrated with your developers, business partners, project sponsors, etc look at ways to use communication to influence their interests, motivations, attitudes and priorities. If we do this, then we’ll no longer have to discuss why UX isn’t respected in organizations. Instead we’ll be complaining that there are too many high level UX jobs to be filled and not enough of us to fill them.