Process | Elisabeth Hubert

Guest Post by: Kofi Aidoo, Intern

It’s been 6 Mondays since I landed at O’hare and came directly to the famed Merchandise Mart ready to begin a new chapter. After spending 3 years placing designers and putting my own creative needs on the back-burner, I was here to start again and begin my journey towards becoming a UX designer. So, exhausted from my last 4 days in New York, I walked into the 1871 space at the Merchandise Mart, luggage in tow and duly impressed by what I saw.

After several years of going to IxDA events and flirting with the idea of UX as a career, I decided that it was time. In making my transition I had spoken to a good number of people in the industry and received some valuable advice. I knew I wanted to dedicate myself to the practice and also that I didn’t want to pay too much money. The ship and build philosophy, the location, and the very reasonable price made Starter League, my current focus, a very attractive option.

For those who don’t know, the Starter League is a 1.5 year old “school” that teaches different aspects of web design and development. The Starter League was founded by Neal Sales-Griffin and Mike McGee, two friends who had faced the challenge of learning the skills needed to build their own digital products. Realizing that there weren’t that many opportunities and resources available that truly help the uninitiated, they began the Starter League. The root of their drive and methodology is to help people learn the skills needed to create and ship viable products fast.

They offer classes in Beginner and Advanced HTML/CSS, Web Development using Ruby on Rails, Visual Design, and User Experience, the class I’m taking. All courses last 3 months and attendees are encouraged to take more than one course to round out their education. The UX class is taught by Carolyn Chandler, co-author of “A Project Guide to UX Design” assisted by Veronika Goldberg, a visual designer turned UX designer and alumnus of The Starter League.

A typical class starts with the review of the homework, Carolyn asks us about any insights and pain points and then we delve into the lesson for the next 3 hours with a ten minute break at the half-way point. We’ve already learned about visual design, heuristics, personas, user stories, surveys and research, as well as, have begun to do some initial wireframing and site maps. All work is project based and done in groups that were formed in the second week. Groups… which leads me to one of the over riding tenets of the course. Collaboration!

Collaboration forms the spine of the learning. In the programming classes, students work in pairs during class, but for the design classes, students work in groups on one “real – life project”. They work together, as practitioners, looking to develop and launch an idea. The high point of all this collaboration is Starter Night at the end of term when teams from all the classes will join together to build an app and then present their app and their process to the rest of the League. Think of it like a 6 week Hack-a-thon without the begging for money at the end. One of the taglines displayed heavily on the Starter League homepage reads: Start Careers. Launch Products. Build Companies. But after 6 weeks here I can definitely say the emphasis, besides being on collaboration, is more heavily on the last 2 tenets.

With such an emphasis, in the UX classes especially, the process can sometimes feel a little lacking on feedback. With 3 months to cover everything there is a speed that is obvious but not overwhelming. However, our homework assignments are mere discussion points and serve ultimately as a roadmap to the construction of an app. Topics and processes are well covered, but we seem to touch on them only once or twice and don’t come back to them as we move on in the class. More than one of my colleagues and I have raised this point, and Carolyn and Veronika have responded admirably. Homework review is taking up a little more of the opening minutes in class while some information that can be consumed as reading material is placed in an extra file. The emphasis on in-class activity and familiarity with the UX process has gone up, and that is great. But enough about Starter League, the question for me remains:

As one of the many here focused on making a career change, and on making UX my livelihood: How do I KEEP IT REAL and become a UX professional while I’m here?

I was trying to keep it real even before I started the program. On deciding to come to this program I have not only left my job but have also made a not so insignificant financial investment. I wanted to make sure I would use the time wisely and be efficient. So, the first thing I did when I was accepted was to prepare myself mentally for the challenge.

Inspired by a Steve Martin quote, “So Good they Can’t Ignore You” is a book by Cal Newport, a Georgetown Computer science professor who’s been writing since high school on different tips for academic success. This latest book looks the idea of Follow your Passion dead in the eye and forces it to blink. To summarize, his claim is that a successful career isn’t about “Following your Passion”, instead your passion arises from using deliberate practice to build career capital, build valuable skills in your industry, gain more control over what you work on and then couple that with a mission statement that drives success and that elusive Passion. Skills are the foundation and that foundation takes work! This has become the backbone of my practice.

But deliberate practice isn’t just about work it’s about receiving critical feedback on that work and then working to make it right. So when my friends in the NYC IxDA community alerted me to this internship I jumped at it. I had known Lis from going to IxDA events and knew she was a well respected straight shooter who would definitely help me refine my craft. Along with this internship I was pleasantly surprised that the Starter League had also put some thought into mentoring and would provide anyone who wanted it with a professional in the city as a mentor for the duration of the course. I was lucky to have been assigned Patrick DiMichale, a colleague of Caroyln’s at Manifest Digital.

The most important thing I’ve done is immerse myself in the work. The Starter League is full of people working to put their ideas to market. Regardless of their experience they are developing projects that require good User Experience design. I’ve aligned myself with 3 of these projects (including my own), and have been using the things I learn in class to look at the projects from a user perspective as well as a business perspective. I’ve given both my mentors a lot to chew on in the past weeks and it’s been invaluable to have their input.

As I look at the next 6 weeks the end seems both far away and right around the corner. I’m not 100% sure if I’ll be ready to start a UX career by the end of my time here, but I do know I’ll be on the right path and will have built a solid foundation from which to move forward. No matter what the challenge, being mindful about the skills that are important, as well as coveted, and working on those will be the guiding principal in my practice. I urge you to read Cal Newport’s book and look at his 4 principals to a happy career. No matter what the environment Keeping it Real starts with knowing your stuff!

When I was first introduced to the field of user experience it was the summer of 2005. After leaving my job as a Java Programmer in Hartford, CT I moved to San Antonio, TX where I randomly fell into a UX job (talk about lucky). It’s an understatement to say that I had no idea what the hell I was doing, and I scraped along for awhile trying to figure it all out. Back in those days, my role was not UX Designer or Interaction Designer, in fact, the term UX didn’t even exist in my world! Instead, those of us that weren’t visual designers were called Information Architects, and that was exactly what we did. It was our job to architect, organize and make sense of the information within a website or application. After we mapped that out (either in an IA doc or some sort of concept mapping), we worked with a visual designer to put our mapping into an interface.

Unlike a lot of what we see today, the first thing I did on the job was NOT learn how to wireframe. In fact I didn’t create my first wireframe until I moved back east to NYC almost three years later. Instead, the first thing I was instructed to do was visit Jesse James Garrett’s site. I was tasked with understanding what the Visual Vocabulary for describing information architecture and interaction design was from a conceptual standpoint, and was then expected to map out IAs for my projects. There are several reasons why this was my first step. Reason one was that we IAs and VDs simply needed to know how information was related and prioritized within a website or application before we could design the interface for that system. How else can you design a proper interface solution unless you understand which information types need to be included in that solution, and which are most important to the solution? Without knowing this information, we would have been guessing at the interface. Reason two was that we didn’t want to show an interface to our non-design partners and stakeholders as our first deliverable because what we really needed from them was not feedback on the visual, but feedback on the content and context that related to the system. It’s seven years later, and, sadly, it seems that the time I’m speaking of has come and gone. And, because of that we are facing a huge problem in the world of UX.

The problem UX is facing is, simply, we are devolving. The definition of de-evolution is to degenerate through a gradual change or evolution, and it seems to me that by removing the information architecture step from our day to day process we might be on that path. To be fair, I’m not saying how that IA phase should be structured in detail (that is for another post), but I am saying that this type of thinking needs to be done and signed off on by certain team partners before we can move into interface design (including wireframes).

We see several problems that come out of skipping the IA phase. First, the team (UXers, Visual Designers, Project team members, other stakeholders) won’t all be in agreement on the prioritization and context of the information to be designed for which will cause disagreement in later phases. Second, by showing wireframes without agreeing on IA, we are focusing our stakeholders and other partners on the interface and not on the real thing we are designing for… content and context. Third, we are, in essence, beginning to lie to ourselves. We are lying to ourselves by telling each other than UX is not just about form, but it is about function as well. Because if it was about function, we’d spend time on the information (the IA phase) before we went right into talking about the form that the information should take (the wireframe phase).

To make matters worse, we, as an industry, have been trying to validate the discomfort that many of us feel subconsciously with skipping the IA step, by turning to “sketching” as the end all be all answer. Of course, sketching is important, but it all matters what we are sketching and when. What I’m talking about is that we UXers think that since sketching doesn’t involve putting our wireframes into an electronic format, than it doesn’t really count as skipping straight to wireframing. But guess what, even sketching the interface without first sketching the structure of the information means you are skipping the one step that will make your designs truly successful. That step is where you think about the content, context and users, and force your stakeholders to do the same, WITHOUT thinking about the interface (also known as the IA step).

So where do we go from here? How do we stop this process of devolution and backwards movement? Well, we bring back IA! Ok, ok, I’m not saying that we should all learn Jesse James Garrett’s Visual Vocab (though it wouldn’t hurt) or that we need to institute a structured process that we follow the exact same way every time. But, what I am arguing we need to do is slow down, put down our sketching pens, and our omnigraffle and just think. Think about, draw out and get buy in on your content, your context, and your users. And do so without a wireframe or a sketch of a wireframe. Pick up the Polar Bear book, and ignore the wireframe chapter and learn IA.

By bringing the IA phase back and by concentrating first on the information, several things will happen. First, your sketching and interface design becomes much, much better because you have prioritization and buy off on the content, context, and users you are designing for. This means that your wireframe/prototyping phase becomes a lot more about the interface and not what content should go in the interface and why. Second, you are showing your stakeholders that UX design truly isn’t just form, but really is also about function. We are moving away from the interface, which is how we started, and towards a real solution of which the interface is only a part. Third, we stop lying to ourselves, and we stop saying that the best UX solutions aren’t just the coolest or the best aesthetically, but they are those that take content, context and users into consideration while creating an aesthetically appropriate interface. Most importantly we stop UX’s slide down the evolution scale back towards the time of print design and outputs, and instead continue our climb up the mountain towards being the user experience experts.

Today, was just another day for this UX Consultant. I had another amazing opportunity to meet with a NYC based startup in order to sell my User Experience wares. Walking away from this particular meeting (and feeling slightly discouraged… *sigh*) I was thinking about how to improve the outcome of similar meetings, and how to move UX forward in the fast paced world of startups. There was one realization that stuck out in my mind… using the term “it depends” just doesn’t work in this world.

We, as UXers, are some how secretly trained to use the term it depends to answer questions about our work. This is not necessarily a bad thing and we usually do this for very good reasons. Those reasons being 1. we don’t want to over promise to our clients and/or partners in other parts of our organizations, and 2. we want to be sure that they understand the breadth of UX’s ability to solve problems so we can promote UX to others and make sure people know its value. Thus, when we are asked how long it will take to design a page, do user interviews and testing, figure out the solution, etc we respond with it depends. We then go into our long winded explanation of how there are so many different techniques that could be appropriate to this situation, that it really depends on nailing down the situation at hand, and defining the problem appropriately. This, of course, is still a valid way for us to sell our capabilities in larger organizations or to well established clients, but is probably a bad idea to do so in world of startups.

In startup world things move fast. Very fast. The business could be void of revenue one day, and the next have 1 – 2 million dollars in funding to spend. Thus, things in startup land really do happen overnight. Therefore, the problems with using “it depends” in this world are two fold. First, startups have no time to listen to our long winded explanations about our process and how great UX is. And, to be honest, they really don’t care. They, instead, care about their product being awesome and serving their users as best it can. Knowing the UX technique to use to get them there is your skill and is the main part of the service you are offering them. Therefore, save your explanation with these guys and gals because they don’t want the “it depends” answer. What do they want instead? The answer. The second issue with using it depends in the world of startups, is that by not tailoring the answer right away to the startup you are talking with, you are showing that you have not taken the time to listen to what they have been saying, and are not expert enough to tailor your UX process, on the spot, to their needs. Why would they spend their precious funding or revenue on you as a resource if you cannot pull this rabbit out of your hat?

Lucky for us, it’s not about magic or pulling anything out or your hat (except maybe a flushed out proposal). It’s very easy to solve the problems that it depends brings you in the world of startups. First, stop using “it depends”. At least, stop using it in the way that you have been. Instead of using it depends to preface a long explanation about how amazing UX is, use it depends to serve up options that are relevant to the specific problem the startup is looking to solve. For example, when a startup asks you how they motivate users from a competitors product to instead use their product, don’t answer like this “Well, it depends. We could do user interviews or focus groups or contextual inquiry. There are so many different methods in our tool belt to choose from!” Instead answer like this “Well, it depends on what we want to learn. If we want to get a throughout understanding of this, we could interview our target users to understand their mental models and behaviors. If we wanted to get a throughout understanding of this as well as know how our product stacks up we could do user interviews as well as some targeted usability testing with tasks that can be done on both websites. These are really the two options that are relevant to this product. In your case, given you needs, I would recommend the second option.”. See the difference? With or without it depends you need to tailor your response to your potential client. Of course, you are not going to have the exact answer, however, you should know the technique that applies to the outline of the situation that has been provided to you. If you don’t have a clear idea of the situation, use your knowledge gathering skills to get it.

How then do you get to a point where you can surface up tailored information and feedback on the spot? Easy, learn the whys behind each and every part of your process (for more on this see: The Ultimate Key to UX Success). It is only then that you can eliminate the inappropriate use of it depends with startups. By knowing the whys, you can match the information that the startup is giving you about their problem with the appropriate tool in your tool belt. You don’t have to take the time to sell UX to them, instead you are taking their time to sell a tailored service to them and calling it UX.

By changing or eliminating your use of it depends when working with startups you are getting to the point and saving them time, as well as coming off as much more of a service professional. The only way for one to get to a point where they can tailor their wares on the spot, is to really understand the whys behind the different parts of their process. By learning these whys, you set yourself up for success. It stops being about educating others (who have little time or interest anyway) on what UX can do, and instead becomes about what you, as a UX designer, can do for others. You can know immediately what would work for this particular client and why, and this not only makes you much more of an expert in your field, but it also does one thing that the startup will be ever thankful for, saves them from having to think (pounds to Steven Krug).

This past summer, thanks to a reference from one of my favorite blogs, Scouting NY, I got my hands on an old and interesting book entitled Sailing Around the World Alone. For those of you who grew up in this area of the country, you may have read this book as a student. But, for others of us the book is probably new, at least it was to me. In short, it was published in 1899 and is the memoir of Captain Slocum’s trip sailing around the world alone (he was the first to do so). It’s an extremely entertaining read, however it was the last page that really gripped me. In it he states “To succeed, however, in anything at all, one should go understandingly about his work and be prepared for every emergency.”. I was moved by this statement, and, naturally, my thoughts turned towards my own profession. The part that stood out to me, and what I want to talk to you about today is “go understandingly about his work”. I want to discuss what that means for me within the field of UX Design, and what I think it should mean to you.

As UXers, we are in an ever evolving profession that, although young, has begun to mature over the past couple of years. Even though we have reached a level maturity, there are many of us that don’t know the whys behind our process, the activities we do, and the outputs we create. Thus, instead of trying to understand the whys, people focus solely on the hows. When I say whys, I’m talking about the reasons why we have the phases of the design process or the reasons why we talk to users. These are in contrast to the hows which are the ways that we go through our process (i.e. persona creation, wireframing, sketching) and the ways we talk to users (contextual inquiry, ethnographic study, user interviews). These two items, hows and whys, although living along the same plane, are in sharp contrast to each other.

To me, the people that only concentrate on the hows are not going understandably about their work. Instead, they are go absentmindedly about their work. They are aware of what they are doing and are probably very good at it, but they do not have an understanding of why they use one method vs another, or why they use one part of the process vs the other. Thus, the problem with UX professionals only focusing on the hows and not the whys is that doing so allows us to go only so far in our profession. By relying on the hows, we will not find ultimate success in both our own individual careers as well as within our field as a whole. Further, how can we sell the idea of UX to organization executives if we don’t know the whys behind our work? If we cannot sell our work then how do we advance in our individual professions as well as as a profession in general? If you are unaware of why the UX process is what it is and/or why the methods we use were put into practice, you will find a hard time with long term happiness, and ultimately long term success, in this field. And to make matters worse UX, on the whole, suffers. (Note: I’ve written about these ideas before. See Getting to the X in UX & When Did We Forget About Behavior for more thoughts).

The solution, if you find yourself in the hows side of the coin, is to reach out and investigate the whys. Use your resources, both electronic and human, to research why you have the process you do. Make it a point to gain knowledge on why certain materials and activities exist and should be used versus others. This, in short, is the only way to begin to turn the tide in your direction. The hard part is that it involves not only a desire to be more successful in your field, but a genuine caring for your career and profession.

By figuring out and understanding the whys, you are, as Captain Slocum put it, “prepared for every emergency”, and ultimately you will be on the path to individual professional success. You’ll make huge strides in not only being the “wireframer” but in being a holistic professional UX designer. But, perhaps more importantly, you will see more success in your own work, and ultimately within the UX world. Thus, let’s all take a lesson from Captain Slocum, and “go understandably about” our work in order to progress not only ourselves, but the profession we love.

I received an email earlier today that I found interesting, and which contained early access to a concept that I would love to hear your thoughts on. The concept that this email wrote to me about was End-User Development, an increasingly more popular way to think about development of software systems. I decided to take a further look at the early access materials and am trying to get a grasp around my thoughts on the topic. Here is some more descriptive text about EUD and what to expect when reading and viewing the materials I’ve linked to below:

As they remark in one of their videos, End-User Development (EUD) is like the ‘atomic bomb’ of computing. It has huge power, which can either be used for good or bad. Bad/wrongful uses of EUD include horror stories like when the Fidelity Magellan fund miscalculated $1.3 billion in their financial records, which resulted in public humiliation and huge loss of share value. Or when the FSA fined Credit Suisse 5.6 million pounds because the design of one of their spreadsheets had incurred substantial errors. Good uses: Microsoft Office has used EUD to solidify its position as the office package of choice as it allows significant customizations and end-user development.

Be sure to take a look and let me know what you think in the comments. As I mentioned, I’m still trying to access and process my thoughts, so some insight from all of you would be extremely helpful.

End-User Development early access materials

This post ranges outside of our UX circle, and is something I’ve been thinking about, and arguing with friends about, for a long time. It deals with becoming a better teammate as well as a better project team member. Brainstorming and generating ideas is something we value very highly in our profession. And rightly so, the more ideas we have the more options we have at getting to a solution. But, generating ideas does not equal solving the problem. I believe that an idea is not really a solution until it is put into action, and generating ideas without knowing what it takes to put that idea into action can be a dangerous thing.

Don’t get me wrong. Generating a good amount of ideas at the right time is not a bad thing. Often it is the reason why a great solution comes along. I’m not saying that during this appropriate idea generating time that you should NOT say an idea because you don’t know how it will be solved. Obviously, that is the point of brainstorming and you should be open minded and generate as many ideas as possible without worry of how to implement those ideas. The problem that I’m talking about is when you are not at a brainstorming time within a project, but are instead in a crucial decision or problem solving instance and things just need to get done. The problem with continually generating ideas and not thinking about how to put them into action, at least at some level, during these times is huge. There are several reasons why. First, by generating a lot ideas without thought as to how to bring them to action, you are putting the work onto someone else to actually solve the problem, and usually during these high pressured times, no one has the time for “extra work”. Thus you are not being sensitive to your team. Secondly, by generating ideas, assuming they are solutions but not thinking about the actions associated with bringing the idea to life, you are not educating yourself on how ideas turn into solutions and thus aren’t learning the work that it really takes to do so. Throwing the work at your teammates causes them to become bitter and untrusting of your ideas and you as a teammate; “oh here we go with Bob, just throwing these ideas out there and expecting me to create solutions from them”. Not educating yourself means you are not sensitive to how work really gets done on a project, and that is a bad quality in a project team member.

So, in order to stop these types of action, you should generate ideas, yes this is good, but think about and try to at some point put them into action. Take note of what this takes and how hard it is to do. Become sensitive to all the work that goes into putting your ideas into a project plan, or solution, and really understand those that are doing so day in and day out.

By doing this, you will become a better teammate because you will have empathy for the doers and empathy for what it takes to put an idea into action. You will also be better at understanding projects overall because you’ll be able to deconstruct ideas into what it takes to see them come to life. And finally you will start to see that generating ideas does not equal solving a problem. It is an important step in doing so, but if it’s crunch time you’ll need to take it a step further to be of great value to your team. You’ll need to be able to figure out how to get sh!t done. Now that equals a great teammate.

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!

Yesterday, UX Booth published an article that Gabi Moore and I wrote entitled Mission Impossible: Shrinking the UX Process. In it, Gabi and I write about the experience we had at her workplace, AnyClip (a site where you can find and experience movie moments), this winter. While there, we worked together to create a UX Strategy for AnyClip, a company that was about to re-release at Austin’s SXSW. The caveat is that we had to create the strategy in only three weeks.

The article outlines what our process was, what worked for us, and also where we went astray. Lastly, the article provides tips for other UXers to be able to recreate the same output that we had. During this time, we found such a great deal of satisfaction and success in our work, that it only felt natural to share it with all of you. Hopefully there is some information that you can glean from our experience to add to yours.

Read the full article here.

UX Booth is a blog for and by the user experience community. It is organized and ran by three awesome, highly intelligent and talented individuals: Andrew Maier, Matthew Kammerer and David Leggett. I cannot thank them enough for giving us the opportunity to present our thoughts to the UX Community. I am proud to have been able to become an author on such an outstanding website.

Special thanks are due to Karen McGrane and Whitney Hess, for contributing feedback as well as helping to edit this piece. Most importantly I owe a huge thank you to AnyClip for letting me join their outstanding team for three completely awesome weeks.

I’d love to hear your thoughts in the comments.