I’m extremely excited today, because tomorrow I’ll be getting on a plane to Savannah, Georgia for IxDA’s annual conference: Interaction 10. My excitement stems from several sources. First, as a local leader for the NYC chapter of IxDA, I’m fully committed to supporting and evangelizing IxDA’s mission and I’m pumped to be surrounded by others that feel the same. Second, this is my very first interaction design / user experience design conference and I’m completely curious as to what’s in store and can’t wait to learn all that I’m about to learn. Third, I’m so happy to be attending with some very great friends, and am looking forward to being introduced to and talking with more awesomely talented UXers.

Here are only some of the talks that I’m hoping to attend:
Scenarios for Design – Liz Bacon
Designing for Billions – Rapheal Grignani
10 Things I Learned About Being a Design Consultant While Living In the Hospital for a Year – Greg Vassallo
The Human Interface (Or: Why Products Are People, Too) – Christopher Fahey

I would love to hear any advice, suggestions, words of wisdom about what I should expect, what I should look for, etc. This is all new to me, and any and all guidance is welcome. I can’t wait to come back with a full report for everyone!

Share this post:

This past week has been a “week off” for me. I’ve finished work with all of my clients, and have been interviewing and looking for new gigs. Being who I am, I’ve also been reflecting a great deal on my career and where it’s taking me. I have had a ton of anxiety around what the next gig/gigs should be, which ones are “right”, and how to make a decision between them. This is, of course, a great place to be for an independent, and I am grateful for the options. There has been some key advice given to me in the past and present that has helped me to calm my anxieties and think clearly, and I’d love to share this advice here. The main point? Know where your endzone is. More specifically, know where you want to end up, the steps you’ll need to take to get there, and what success looks like when you are done.

I’ve been lucky enough to have a ton of “mentors” in my life. One in particular has been with me since my days at UCONN and is the person I always turn to for career advice. One exercise he suggested I go through was a career mapping exercise. The idea is to write down in one column the core competencies for career growth overall as well as specific to my field (examples of these core competencies include: UX knowledge, Leadership ability, Financial knowledge, etc). Then, create a time line across the top that moves out every 3 years. For each time period, I would rate on a scale from 1 to 5 my knowledge of each capability (either where my knowledge is present day or where I wanted it to be 3, 6, 9 years from now). I would also dictate, by year, the stage of my career I wanted to be in (i.e consultant with steady client list), and the steps I took to get there (i.e. networking in nyc). Some years I would grow in certain areas, some I would remain consistent. I tried to project out every 3 years until I retired which was harder than it sounds. This is a document that I look at often and try to keep up to date as my interests and abilities change.

What this exercise helped me to do was create an endzone. Every step I take in my career should somehow contribute to this endzone. Having a clear end point enables me to make decisions about career confidently. I can ask myself, does this strengthen me in the ways I’m looking to grow? Does this gig enable me to do the things I’m looking to do or at least set me up for them? Looking at the document I set up for myself and asking these questions has removed 99% of the anxiety in decision making that I’ve been facing. I know I am better prepared to drive my career and take the decision making time to focus on more important things, like concentrating on my next basketball game .

Share this post:

Over the past couple of days, I’ve been helping to write user stories. For those that don’t know, user stories are the form that requirements take in some agile development methodologies. These requirements are usually (at least from what I’ve seen) a combination of business and user requirements. As myself and my coworker were going through the process of writing these stories I found myself asking the same question over and over again when validating if the story was written correctly. That question: Can someone test this story?

When we write user requirements/stories we are writing them for several different audiences. The two most important are developers and QA testers. Sometimes, however, I think that we tend to forget the testers. We want to be sure that developers can code our ideas and designs to spec, however that means nothing if they are tested improperly and are released into production in an incorrect state.

The idea behind user stories is to break down the requirements, features and intended functionality into the smallest bits possible. When you are done, someone should be able to take a story and turn it into a test case in order to test just that one piece of the pie. Writing these stories becomes an art (in a weird sense) because you want to be sure you include all the factors needed to write a test case properly. For example there is a huge different between “the user should be able to purchase the product in order to be happy” and “the logged in user should be able to purchase the product in order to be happy”. I’m pretty sure you wouldn’t want a bug in your system that allows non-logged in users to do logged-in type functionality. However, according to the one user story, the tester wouldn’t need to be logged in to test the functionality.

The moral of the story is when you are writing user requirements ensure that from them the developers cannot only code your designs, but that they can be tested successfully. This is a huge part of how you as the UX Designer can ensure a quality experience for users.

Share this post:

I have just gotten through my first full week of UX consulting flying solo (without an agency or other a full fledge team to direct my work), and all I can say is: wow. I’ve had several revelations and reflections that I wanted to share with all of you.

First off, I say wow because, put quite simply, I LOVE this work. This type of environment is a huge part of what I’ve been missing in my career. I’ve never been so happy to go to work! There are several reasons. One, no one is responsible for me but me. I determine what I’ll be working on, and I’m the one to say whether or not it’s good enough to hand off. I feel in control of my outputs as well as my inputs. Two, the work is fun, and my team is awesome. I couldn’t ask for a better first solo gig to work on. I’m totally into the product being developed, and the team that I’m working with is super talented. Three, I get to teach people about what I do… and they listen. People are paying you to speak, to teach and to help their product and brand. Knowing that there is a timeline when you’ll be available and that you are an expert outside source completely changes people’s perspectives… well at least for now. Four, I get to use what I’ve learned and use it creatively. Because I’m calling the shots on the UX work (based on business objectives of course) I can be flexible in solving problems. This is refreshing and makes me feel like all of my hard work outside of “work” is put to good use.

Secondly, I’ve really begun to see that it’s not that serious. That any help and hard work is better than no help. Being on my own I have to realize that I’m fully responsible. For someone like me this can be overwhelming in an attempt to reach perfection. Well Lis, perfection is never going to happen. However quality, hard, informed work is better than no work at all. After each project I work on, my goal is to write what went well, what didn’t, and what I would have changed or done better. This will help me develop even more in my solo role.

I’m looking forward to working on these types of projects more and more. I feel like I’m contributing and that I’m making a difference and that is what fuels me to succeed. I can do this!

Share this post:

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.

Share this post:

As the end of the year approaches we see more and more “year end” posts and articles come through. At first, my cynical, sarcastic self thinks “gah I hate all these wrap up, year end articles!”. Then reason takes over and I realize it would probably be a good exercise to reflect on what I’ve done this year. So, here is my year in review.

Sitting back and thinking I realize that 2009 has been a HUGE year for me.

1) I went independent, which meant deciding to do UX on my own. Working for myself has been a dream of mine since I was a kid, and this year I brought that dream to life.

2) I began volunteering with the NYC IxDA. Due to this I’ve not only learned a ton, but I’ve met a slue of awesome, intellegent and talented people. IxDA has helped me to get myself out there and become part of the UX Community here in NY.

3) I spoke on my first panel (you can see me here: http://www.ustream.tv/recorded/2600736) at this November’s New York Entrepreneur week. This was an invaluable experience that I absolutely loved doing and hope I get the chance to do again.

4) I’ve interviewed, met with, talked to, gotten advice from a LOT of awesome people. All of these pieces of advice have allowed me to start to see success as an independent worker and also as a UX Designer as a whole. A HUGE HUGE HUGE Thank You to everyone who took even a few minutes of their time to talk with me and answer my many questions. Hopefully I will get the chance to repay the favor one day.

5) I found one of my niches in the UX Community with my current UX Therapy group. These talented folks meet every week to begin to sort through the issues and good times that we find in our jobs, as well as to exchange ideas and help each other grow. I owe you guys a lot!

6) There is a ton more that I’ve accomplished this year (found the NY Tech community, attended more meetups and events that I ever thought possible, managed to function on almost 0 sleep and still made it to the gym to work out and destress) but I think the most important is that I started to believe in and have confidence in myself. I believe that everything I mention above and everything I’ve done this year has contributed to this accomplishment. All the people that have encouraged me and all of the experiences have meant and continue to mean so much to me.

2009 will go down in history as one of the best, most stressful, and crazy years of my life. Knowing that everything has been preparing me for even bigger and better things, I can’t WAIT to see what 2010 has in store. Stay tuned here to find out .

Share this post:

As tomorrow begins the holiday that my family celebrates during this season, I wanted to take a moment and wish everyone out there wonderful holidays no matter which you choose to celebrate! Given that tomorrow and Friday are non working days for me, I’m going to take some time to plow through today and then shut down my brain for a few days and enjoy my life. I wish that you’ve gotten or will get the chance to do the same.
Look for something insightful (or at least an attempt to be insightful) next week and have a safe and Merry Christmas!

Share this post:

I don’t know that I’ve ever written about this topic before, but it is one I’ve definitely done a great deal of thinking on. Most of my thinking was done a few years ago while at a company that was just implementing agile as a development methodology. My gears started turning again when, yesterday, I came upon David Farkas’ article on this topic: How UCD and Agile can live together.

I love the way that he begins to define and categorize the different terms and phases within this realm. One thing, however, that I think is missing (and may not be appropriate for this article) is the idea that UX is ideally always iterative and therefore should fit pretty well into an agile environment. Otherwise, I mostly agree with the Phases that the author defines. Having a UX strategy is what I believe makes the entire process work. There needs to be solid ground (the purpose and overall “how” in this case) for the entire team (both UX and dev included) to stand on, in order to move quickly, efficiently, but with purpose.

I’d love to hear your take on the article and/or my comments on it. What is he missing? What did he get right?

Also, if you’re in the NYC area and are interested in this topic don’t forget to check out the Agile Experience Design meetup. Great discussion going on there!

Share this post:

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?”

Share this post:

Over the last year, I have learned a lot about what it means to be an independent worker. Mostly it means that you are never satisfied with the project you are on, and that you are continuously looking for new challenges to sink your teeth into. During this past year, I’ve done a lot of reflecting on what types of challenges I want to take on, and have talked to others about this topic at length. It feels like, as a design community, we are always looking for the same big challenges. Working for ABC because they did this campaign, working for XYZ because they did this talk at this conference, working with DEF because only the best designers work there. Talking with my peer review group a couple of weeks ago I found myself asking, are we a profession that is obsessed with reputation? We are always talking about innovation and creativity, yet the majority of us want to work at ABC for the same reasons. How, then, do we expect to foster the principles of change that we all speak of?

What am I trying to get at? I’m asking you as design professionals to tell me the advantages that you see working for the big guys? What products have they produced that are more fun & challenging that Joe Smoe’s website start up? For me, I’m really beginning to think how much of it is what these companies/agencies produce and how much is just for the reputation that they have? We follow these guys like they’re rockstars and we’re the groupies… “John from DEF is speaking at yadda yadda (some UX designer faints from excitement)”, but how different is the work that you are or could be doing for someone that can’t afford to hire DEF? Isn’t it time for our community to expand beyond the big names, isn’t it time for us to start to create different big names and great ideas??

All this being said I know that we are all doing really great work that is creative and helpful in our careers, but my question is would you trade all that work to go to a giant agency? And if so, is it because you will learn more & solve great problems, or is it because of their reputation? I’m definitely starting to lean the other way myself, but that’s not to say I’m not also guilty of being a groupie. What it means is I’ve start asking myself these questions and determining where I want my career to go, and what types of challenges I want to entertain in my future.

What are your thoughts? I would love to hear them!

Share this post: