Usability Countshttp://www.usabilitycounts.com
User Experience and DesignThu, 14 Jul 2016 14:28:17 +0000en-UShourly1https://wordpress.org/?v=4.729155632UsabilityCountshttps://feedburner.google.comSix Tips Before Moving To Seattle As A UX Professionalhttp://feedproxy.google.com/~r/UsabilityCounts/~3/pP2CMplQuas/
Thu, 04 Jun 2015 14:36:44 +0000http://www.usabilitycounts.com/?p=5852You’ve heard all the nightmares: it rains all the time, the traffic is really bad, Microsoft and Amazon dominate the job market, the male to female ratio is so bad the dating scene isn’t, yadda yadda. However, if you’re one of the California natives that can work through some of these, read on.

Stuff to check out

]]>You’ve heard all the nightmares: it rains all the time, the traffic is really bad, Microsoft and Amazon dominate the job market, the male to female ratio is so bad the dating scene isn’t, yadda yadda. However, if you’re one of the California natives that can work through some of these, read on.

Seattle is a great place to find your next User Experience position, at a place with work-life balance and you can work on products focused on business value instead of the me-too economy.

When I talk to others here, there’s a growing sense that the Pacific Northwest could be the next Silicon Valley, and Onward Search ranks the Seattle market as the third largest in the U.S. for User Experience opportunities. Microsoft, Amazon, Facebook, and Google are located within a bus stop or two of my huge loft that’s half the price of a San Francisco walk-in closet. There are a lot of pluses to living in the Emerald City.

But before you move out of your 510 square foot shoebox in the Mission next to the homeless shelter and drive your U-Haul up I-5, here’s the list.

Cost of living? High, but not even close to the Bay Area, and it offers similar neighborhood experiences.

There may have been a rapid increase in home and rental prices in the Seattle metro, but it’s nothing like the Bay Area. Consider this: a North Beach apartment I rented in December 2009 for $1,500 is now renting for nearly $3,000 a month. The market isn’t as constricted here, and there’s a ton of construction underway to increase the housing stock.

The downside — no rent control. The first apartment I moved into in Seattle is going for close to $500 more than I paid for it, and I moved out last June.

Salaries aren’t as high and companies are less willing to get in a bidding war because there aren’t as many places to go. Outside of Microsoft and Amazon, most salaries will be lower than in the Bay Area, but you keep much more because the State of Washington doesn’t levy an income tax. Net, I’m making much more than I did in the Bay Area.

Seattle is topographically similar to the Bay Area, so there’s a very real division between those that live in Seattle and the Eastside. Each has its advantages, but will also affect the decision about where you work, and there are many places to live that are similar to living in San Francisco without the hassles. Where I live is like a mini San Francisco, but I pay $7 in tolls every day to cross a bridge twice. I mark that up as a quality of life expense.

There’s a lot of jobs here, but not many companies — and they’re big.

I used to describe Seattle this way: It’s Microsoft and Amazon and Microsoft and Amazon and a few startups and Microsoft and Amazon and a few agencies. Also, there’s Microsoft and Amazon.

If you stay here there’s a pretty good chance that you’ll end up working for at least one of them in your career. Many designers have created careers out of contract surfing between the two. There’s a pretty good chance that the boss you have at Amazon used to work at Microsoft, and vice versa.

That’s changing.

Companies see the Pacific Northwest as the next source of technology talent. HP, Oracle, Disney, Facebook, Google, Twitter, and Groupon are growing their bases up here to join established companies like Zillow, Tableau, AT&T, T-Mobile, Starbucks, Staples, Adobe, Boeing, and BestBuy to build technology teams. Walmart Labs and Google also recently opened locations in Portland. There’s also a growing startup community lead by Madrona Ventures that’s drawing talent, plus many of the mainstays that have been here forever, like White Pages, Moz, and Inrix.

This is providing opportunities to find new challenges that many designers need coming out of companies like Microsoft and Amazon. This is a good thing, because it provides a necessary labor circulation that encourages the growing of skill sets.

But much of the work here isn’t exciting conceptual design and innovative startup work: it’s products you’ll be iterating on forever that are less focused on valuations and more focused on making money. That limits the number of green field opportunities, but offers stability.

What I do like about Seattle is there seems to be a greater work-life balance than the Bay Area — there isn’t this constant push to be the next valuation unicorn, and that’s good if you’re just looking for a place to do great work.

Seattle is the world’s biggest small town.

Because I recruit as part of my job, I have a spreadsheet that maps all of the design resources in Seattle that I’ve found so far on different social networks like LinkedIn. The list totals about 1,800 names, roughly 65 to 70 percent of the market. How connected is this market? I’m a connection or two away from many of them, which turns Seattle into the design version of the Kevin Bacon game.

The pluses:

Designers are very approachable because they may know you or of you.

Networking here is much easier than in the Bay Area because the community is more cohesive and accessible.

Getting intelligence on working environments is much easier, because you probably know someone or of someone that has worked there.

The minuses:

Relationships are everything. You can burn bridges all year long in San Francisco. Not so in Seattle.

This limits access to great opportunities as a newcomer because the best opportunities are restricted to those in the know.

The person you’re competing against may be someone you know, which can be awkward.

There are designers on Twitter here, but not nearly the number that are on the social network in the Bay Area. Many of the relationships are going to have to be built the old fashioned way: by meeting people. This means going to meetups, inviting people out for coffee, and reaching out, one person at a time.

If you take great care in building relationships here, you can be successful. However it may be a much slower go of it than in the Bay Area because of the transitory nature of the work there.

True design leadership opportunities are few and far between.

Seattle is three to four years behind San Francisco in design trends — let’s call it a fast follower — so many companies haven’t figured out that design can have an impact on the bottom line and staffed appropriately. Amazon and Microsoft are both engineer-driven cultures which have spawned a bunch of startups that (guess what!) were founded by ex-Microsofties and Amazonian engineers.

It’ll be a while before design really finds its place here like it has in the Bay Area, but things are changing. Just not fast enough.

The dilemma most designers in Seattle face: to grow their careers, they have to leave Seattle and move to San Francisco to get the experience they need growing a design team. Many of the companies here recruit leadership from other places because they know the talent pool here for that leadership is limited, and this is similar to a trend that I saw in Los Angeles.

It’s a “chicken or the egg” problem.

If you expect to move here to find that dream “Director of User Experience” position and you don’t have that experience for more than a couple of years on your resume, you’re probably not going to get it right off the bat. You might have to network quite a bit, and step out of your comfortable zone — i.e. build a team from scratch over a few years instead of marrying into the family — to get the role.

There are a few places in Seattle with sizable design teams (pockets of Microsoft and Amazon, Expedia, Concur, Avvo, Disney, Moz, and where I work at now). If the place does have that position, it’s a true management role, i.e. you’re building a team and not leading the design yourself.

You know that rain thing? Not so much as you would think, but bring your Vitamin D.

When people talk about Seattle, they talk about the rain. It rains all the time according to those that don’t live here.

Not true. But it is gloomy. Very, very gloomy — the average cloud cover during the winter hovers in the 95 percent range.

If you have Seasonal Affective Disorder, Seattle is not for you. In December, the sun rises at 8 a.m. and sets at 4 p.m. November, December, and January can depress even the most cheerful of souls, so much so that I recommend that you move here during the winter so you know what you’re in for.

Conversely, the summers here are amazing.

The sun rises just after 5 a.m. and sets after 9 p.m., so you don’t get that noticeable sunset feel until almost 10. The weather is almost never hot: most places in Seattle have never had air conditioning. With all that rain comes the benefit that places to hike around Seattle — and there’s a lot of them — are green year round. If you’re an outdoors or travelling person, the opportunities to enjoy the outdoors in places like Seattle, Vancouver, Portland, and Eastern Washington are endless.

It’s so green here, something I have never experienced before, that I had allergy problems for the first time in my life.

You know that Seattle Freeze thing? It’s real.

I’ve lived in Seattle for two and a half years, and I have exactly one friend that’s a native to Seattle (waving to Troy Parke!). There are some personal reasons for this — I spend a lot of time in Vancouver — but it’s incredibly hard to get to know people here, for a number of reasons, mostly because we’re one of the most introverted places in the United States.

Building relationships takes a lot of time here. There are a lot of meetups where you can build friendships, but a lot of the people are going to be transplants, so you just have to go with the flow. Once you get to know people, the relationships you build here are deep and lasting. You just have to work at it.

The upshot: This place isn’t the Mission.

The opportunities here, the reasonably fair standard of living and decent work life balance make Seattle a very attractive place to work if you’re a user experience professional. There’s a lot of opportunity for learning and growing your career at a place that is sensible.

Stuff to check out

]]>5852http://www.usabilitycounts.com/2015/06/04/six-tips-before-moving-to-seattle-as-a-ux-professional/The UX Interview: How To Crush Ithttp://feedproxy.google.com/~r/UsabilityCounts/~3/8W1T_Hq4nWU/
Wed, 29 Jan 2014 16:40:03 +0000http://www.usabilitycounts.com/?p=5747Interviewing presents incredible opportunities where designers can take control of the interview. Run the interview preparation through the user experience process, and you’ll be ahead of the pack every time.

Stuff to check out

]]>When you’ve reached the phone screen or the in-person interview step, you’ve gotten past the hard part: you have demonstrated that you have the qualifications to work at the company. You’re now being judged on whether you have the soft skills and culture fit.

After holding previous talks at The Seattle UX Meetup group, I’m reminded that many interview expectations are unstated, and most companies don’t understand how to interview.

The process presents incredible opportunities where you as designers can take control of the interview and show you can fill their need. Run the interview preparation through the user experience process, and you’ll be ahead of the pack every time.I’m going to skip some of the standard stuff, like take a shower or dress appropriately, because that’s common sense. Let’s talk about what really matters.

Research The Company And The Team

Any User Experience activity should start by understanding the target audience, and job interviews are no different.

I don’t just mean what the company has made, or its history. Try to know the people, who they are, what they’ve done in the past, and what they might be doing now.

There’s nothing that impresses me more than when an applicant knows who I am and what my background is. And considering that if they search on Google for my name (“Patrick Neeman”) about the first 60 results, they should know exactly who I am.

The reason?

Any User Experience activity should start by understanding the target audience, and job interviews are no different. It shows that the interviewee understands that any process requires research even before you start.

Remember, the interviewers are your target audience. So how would you do it?

During most interview loops you are interviewing with up to six people, and each represents a different role and possibly a persona. They will all have different skill sets and different needs. They will all ask different questions that are relevant to their role in the company. Before you go into the interview, you should understand their role and background so you can be ready for their questions.

For example, the questions a Product Manager asks should be much different than those from a Design Manager. Understanding that context is key, so that you can answer questions in their language.

I look for commonalities in experience — for example, one candidate I interviewed this week had experience similar to mine in the healthcare field — so we could talk about some of that. It would be awesome if the interviewees actually did that, so that we could discuss what we have learned from each experience and how it applies to our product design today.

A key question I ask: “How would you explain Apptio to your parents?” It’s a question that is really hard to answer well, so getting a good response is a great indication they have researched the position.

Bring An iPad Or Paper Documentation

The presentations I find most engaging are iPads and printed documentation.

Designers bring in their portfolios on different devices. Sometimes it’s a laptop, other times they refer to their website. Occasionally (this happens at Apptio), we present on the big screen.

The presentations I find most engaging are iPads and printed documentation.

For iPads, showing work creates a more intimate experience: you can connect directly with the person you are presenting to. On a flight to Vancouver I had a conversation with a game designer, and he discussed that usability tests they had performed showed that users view iPads as a window to the world, looking down to access content. This experience was much different than playing games on an XBox or Playstation, so they had learned how to design their games differently to account for this context.

Dead tree material can provide the same experience: as you flip through pages, you can tell an amazing story, as with an iPad. It’s a bit more physical with printed paper, but you can be more intimate as you explain your story.

Remember, it’s about engagement and telling a story. As you sit next to your interviewer, look down at the work, explain it, and then look into their eyes to make sure you’re explaining the solution in a context they understand. This creates a very intimate experience that is hard to replicate on other devices, like sit-forward experiences (laptops) or sit-back experiences (presenting on a larger screens).

Get In Front Of A Whiteboard

Turn interviews into a user experience process sessions, using the whiteboard as your ally.

What I like best about interviews is that you can get in front of a whiteboard. Talking about collaboration is one thing; demonstrating it with the interviewer is a completely different experience that very few designers take advantage of. Many companies, including Amazon, use this as a way of judging their talent.

Here’s an approach that works really well, if you’re interviewing with the right company.

They’ll ask you to design a product or page, and will watch to see how you approach the problem to drive at a solution. There is no right or wrong answer, but there is a right or wrong approach to this question.

Turn interviews into user experience sessions, using the whiteboard as your ally and iteration of ideas as your process.

Example questions:

Who are the target personas or actors?

How often will they use it?

What is the mental model of the user?

What is the context? Laptop in the office, or mobile on the road?

What is the prioritization of the flow?

What are the goals?

Each question drives home a different point of process. It does so in a way that doesn’t preach the user experience process, which is very important. It also involves them in the process, so you are showing how you can educate them how to do great product design and be collaborative at the same time.

It’s all about audience context, and this is a great way to show that you understand your audience without being condescending.

Have Your Stories Down

Most important is practicing the presentation with a very critical audience and getting feedback.

One story I have absolutely down is Bob The Chiropractor, a five page website I built for a friend of mine for beers. It’s a small but incredible story about lead generation. I’ve told that story so many times, I show a maximum of two screens to illustrate the value that I brought to the product — the initial home page and the Google Analytics conversion page. It’s also a really powerful story because it’s a small project that still clearly illustrates that you can run user experience on almost anything.

How do you get your stories down? Tell them over and over again, and get feedback from other designers over a drink.

A few weeks ago, I met up with two designers I’ve mentored. One of the designers is looking for a new position in user experience, but they can’t tell the story of where they working at now because the work is is under NDA.

So what did the designer do?

Create a presentation the explains every step of the user experience process they went through, from research to final implementation. Most important is practicing the presentation with a very critical audience and getting feedback. The designer has done this over and over again. Their portfolio is already good, but like any great designer, they want to raise the bar.

When the presentation is done, they will have the story down so it can be told again and again. This presentation is so good, they’ll get hired before having to tell the story too many times.

Engage With The Interviewer

If you engage with the interviewer, you can get them talking (good), telling their stories (better), and understand their needs (best).

During most interviews you’ll have an hour with the interviewer. Your job: engage with that interviewer as much as possible. Show them that you understand their wants and needs.

The first time I did the UX Resume presentation was at UX Speakeasy in San Diego, California. My co-presenter was Dylan Campbell, principal of Highlander Solutions, a recruiting firm.

Dylan is a master of telling stories — he is screenwriter on the side — and even better at engaging with people. That’s his job as a salesperson, because ultimately sales is engaging with customers. I enjoy conversations with him because not only is he entertaining, he listens and engages me. Dylan makes me feel like a million bucks, even if we haven’t talked in months.

Back to the event: that engagement was in full force the first night.

I went to the speakers’ dinner with Dylan, and everyone loved talking with him. He was engaging, telling stories, but more importantly he got everyone else to talk and tell their stories. After the dinner everyone talked about how great Dylan was, but no one really knew who he was. The same goes for interviewing.

The interviewer is your customer.

If you engage with the interviewer, you can get them talking (good), telling their stories (better), and understand their needs (best). When you understand their needs, you can frame your experience in terms of solving their problems. It’s a typical user interview — understand who they are — but you are in essence giving a report of your findings right then. And people love talking, because very few get asked about what they need and then actually listened to, especially in today’s narcissistic world of Facebook and Twitter.

The longer you engage with the interviewer, that’s less time that you are forced to talk, and more importantly, there’s fewer opportunities for you to make mistakes during the interview.

Conclusion

Designers have an amazing advantage over other positions: we can show the work we are involved in and how our value has direct impacts on products. Showing a portfolio is much more powerful than talking about return on investment or performing a code test.

It’s up to you as a designer to take advantage of this context and turn it into a great opportunity.

Stuff to check out

]]>5747http://www.usabilitycounts.com/2014/01/29/kill-ux-interview/Your Mobile Design Strategy: Responsive, Adaptive, Native, Or Not At All?http://feedproxy.google.com/~r/UsabilityCounts/~3/2hxtwKq2sNM/
Wed, 08 Jan 2014 15:28:16 +0000http://www.usabilitycounts.com/?p=5731Responsive design is a buzzword in User Experience. Adoption is moving at blazing speed. Designers are blogging all kinds of advice about what mobile strategy we should follow. But really, mobile first for everything?

Stuff to check out

]]>Responsive design is a buzzword in User Experience. Adoption is moving at blazing speed. Websites such as Disney.com have redesigned their sites so they work across multiple devices. Designers are blogging all kinds of advice about what mobile strategy we should follow.

But really, mobile first for everything?
Like anything in User Experience, it depends on context. There is no single approach, and yet designers make sweeping declarations before understanding the differences in user needs. There is no one size fits all solution, no matter how many presentations at conferences say so.

There is no single approach, and yet designers make sweeping declarations before understanding the differences in user needs.

Determining your mobile needs is like buying a car: the user may be an Italian speed demon that wants to go fast, a soccer mom that wants utility or a naturist that wants to go offroading. Each has a different context, and no one car can fill every need.

Before we proceed, here are the definitions:

Responsive Design: Designed for multiple devices, adjusting the design based on the device. Equal, but different.

Adaptive Design: Designed specifically for a mobile or tablet experience. Not equal and separate.

Native Application: A program designed specifically for iOS, Android or Windows. Different and separate.

No mobile design: Designed for desktop and tablet only.

There may be situations where it makes sense to only adapt part of your application to mobile. Analyze both the tasks (reviewing a document) and the context (in a hotel room) to make a decision on what the application should do.

You may pursue a strategy that is maybe a combination of all approaches– responsive, adaptive, native or not at all, but that strategy should only be defined after asking the following questions:

Does your website have a lot of return users?

How engaged are you with your users? How often do they use your website? Are they coming back daily, weekly, yearly?

Some websites have what I call single serving content: you’ll go there once, and not return until you need it again. It could be a long time until you go back, so the user wouldn’t install a mobile application.

Some websites have what I call single serving content: you’ll go there once, and not return until you need it again. It could be a long time until you go back, so the user wouldn’t install a mobile application.

An example is a marketplace that I designed for a freelance client of mine, Archeo Domains. We went responsive because it was more cost effective. Mobile visits most often would be a “single serving user” — they come once, but would probably return on their desktop computer to complete the transaction. It’s responsive, but there’s no ROI for a mobile application.

Mobile applications for sites like Twitter and Facebook are necessary because there’s a lot of return engagement. Users are performing actions like posts and messages, and reading more content. Their applications are always on and always notifying, so the users are engaged.

Does your website have a lot of expert users?

A great example are business to business applications. Users are in the office or at home performing certain tasks several hours a day. Their screens are very complex because they want access to as much information as possible. Speed and utility trump mobility (and for that matter, emotional design).

Many business to business applications have a lot of expert users that use the application between six to eight hours a day. The users perform complex tasks sometimes on not one but multiple screens. Speed is of the essence. Mobile in any form is not appropriate in that context.

For tasks like reviewing content and approving workflow steps, adaptive mobile design plus adaptive email design makes sense. Anyone may perform those tasks and they could be anywhere — at lunch, on vacation or at home. The application was also designed with the “Everyone Loves Raymond” scenario in mind: managers reviewing documents on their iPad while at home while watching television. Since many applications would contain a single task, it would make sense to adjust the application design for tablet, but not for mobile.

Does your website feature a lot of consumable content?

It is important to build your website so consumable content could be optimized for the viral loop — content that is shared once will likely be reshared to other users. The best way to do that? Responsive web design.

Consumable content is any link that could be shared on a social media network like Facebook, Twitter or Flipboard. The links could be a photo, a news article, or other interesting content that you can share with your friends.

If yes, build responsive because the content will open up within the frame of another application or it will be quick read. This is especially true for non-destination websites. The NY Times redesigned their website, and only the article pages are responsive — that’s the content that will be shared on social media. It’s an interesting and forward thinking choice for business decisions. They don’t necessarily want repeat users to read their site for free, they want to subscribe to the newspaper and download their native application.

When I converted Usability Counts to responsive design, I saw a sizable increase in traffic because many of the users were consuming content in their spare time on their mobile devices. The website also works pretty well in Flipboard (I have to add the customer RSS Feed to truly optimize it), so I also saw a bump from that too. The UX Drinking Game is another example where a site has a lot of consumable content that could be read in many environments. Both mobile and desktop breakpoints average over 12 page views per user.

It is important to build your website so consumable content could be optimized for the viral loop — content that is shared once will likely be reshared to other users on any device. The best way to do that? Responsive web design.

Does your website have a mobile audience?

Are the users on the road all the time? Is it an action they will never perform in front of a computer? Are their needs immediate?

If that’s the case, a mobile application may be the best approach. Instagram is a great example: users are taking photos with your mobile phone, and sharing content on multiple content platforms — my Instagram photos to Facebook, Twitter and Tumblr.

Or, would you walk around San Francisco with a laptop to take photos for Instagram?

Instagram does have a website and it is responsive. However the context is that you want to bring your photos with you to share with your friends, so a mobile application is the way to go. The website is minimalist, and is built in a way to drive traffic to the mobile application.

A site that should have a good mobile application is Caltrain: most of their users need access to updates and timetables, and the only solutions now are applications that aren’t affiliated with Caltrain. Caltrain has failed its users needs, and it probably adds to customer support costs.

Does your website require native technology to create a great experience?

Spotify and Square are both amazing technologies — they allow users to use just about any device to use their systems. Spotfiy allows music discovery, but primarily acts as a background application. Square functions as a cash register for small businesses, and that purchase could be anywhere.

Both work best with native technology, and even Spotify’s desktop use is a native application, sitting in the background as the user performs other tasks, like working. Both are omni channel (the user can access them from any device), but their core use cases are native applications. Square even has an additional requirement — adding a piece of hardware to swipe credit cards, which will go away as soon we adopt digital wallets.

PhoneGap can achieve some efficiencies, but even companies like Facebook admits the limitations of mobile web technologies.

Stuff to check out

]]>5693http://www.usabilitycounts.com/2013/12/10/ux-portfolios-tell-story/Startup Weekend: Five Tips How To Shiphttp://feedproxy.google.com/~r/UsabilityCounts/~3/--HMhBGdPgg/
Fri, 22 Nov 2013 17:43:23 +0000http://www.usabilitycounts.com/?p=5609Watching people build their ideas is a wonderful experience. I've gone through Startup Weekend myself: I participated in the Los Angeles 2009 event, and learned a lot about working with a team in a time compressed environment.

Stuff to check out

]]>I was a coach at Seattle Startup Weekend on Saturday. Thanks go to Madrona Venture Group’s Hakon Verespej for the invite — it was a lot of fun! And congratulations go out to LilyDrive, a startup I coached, for the win.

Watching people build their ideas is a wonderful experience. I’ve gone through Startup Weekend myself: I participated in the Los Angeles 2009 event, and learned a lot about working with a team in a time compressed environment.

This advice is a bit late for Seattle, but there’s hundreds (and I mean hundreds) of other Startup Weekend events going on during the next few weeks. They need help. We should coach or do our own startup. Here’s a few tips.

Put together a schedule

What you don’t do is almost more important than what you do.

54 hours may seem like a lot of time, but it isn’t. When you have a team of seven people arguing about the second or third pivot 5pm Saturday, you’re going to look really stupid come Sunday afternoon without a coherent pitch deck.

Here’s the schedule I would follow:

Within an hour: Have a complete team.

Friday night: Have a domain name, Twitter account, Facebook page and any other social media ready to go. Starting scheduling tasks around the cheat sheet in this folder.

Your team will always be short on time. What you don’t do is almost more important than what you do. Drawing out wireframes on paper instead of using software is one task I would consider doing differently. It’s important that your prioritize your needs crisply, and figure out the right level of effort. The demo and pitch deck is about good enough, not great.

Have the right team

Balance is very, very important for delegating tasks.

The team I was part of was wonderful, but it was overloaded with marketing and project managers and short on engineers. When it came time to do the things that startups do — you know, write code, design, register domain names — it ended up the responsibility of me and another guy that could write code, and a couple of people were sitting around or left to join other teams. We really weren’t balanced.

The Dave McClure model of hacker, hustler, and designer works because the team needs to have the right pieces. Having a visual designer that understands user experience is especially important, because a good looking demo and deck can hide a lot of flaws. If I were to build a team today, I would recruit one hybrid designer, two or three engineers, one marketing person that can write copy, and two or three generalists that can go out and talk to people. Balance is very, very important for delegating tasks.

Team chemistry isn’t important as you would think. It’s only 54 hours. You aren’t working with these people for the rest of their lives — they should likable enough so you can get through the weekend. If you need to, you can “fire” them quickly.

Use existing tools

Your idea doesn’t have to scale to millions of users, it has to work well enough for the demo.

It’s much easier when you have a starting point.

Build a great looking prototype today is much easier than a few years ago. We didn’t have frameworks like Twitter Bootstrap and Foundation, and there weren’t very many open source social networks and other tools.

When I was talked with LilyDrive, I suggested all kinds of ways to leverage other people’s code to build their idea as quickly as possible. WordPress plugins with easy to change code, Chrome extensions that are open-sourced and flat HTML pages that could be designed quickly all came up during the conversation. They went simple with a HTML button and landing page, because it demonstrated the concept clearly.

Another team repurposed open source code to quickly build their idea, so all they had to do was turn it on.

Your idea doesn’t have to scale to millions of users, it has to work well enough for the demo. If it’s an idea worth pursuing, you can rip it apart and build it again.

Find advocates

Since most of the coaches are startup types themselves, they might be willing to help.

Ask for help, you just might get it.

I talked to a few teams, but LilyDrive was the idea that resonated with me — it helps non-profits by attaching filtering technology to my content so people can donate to causes they are familiar with.

During the conversation. we talked through several personas, and I was the closest to a publisher persona because I could see putting their technology on this blog. They worked on the technology on their side on Saturday. I volunteered to write an article about Startup Weekend because I think it’s such a cool idea. So you could say I was their first customer.

This is a lesson for other Startup Weekend founders: research the coaches and figure out how they really can help you. They might be able to help in ways like I helped LilyDrive. There are no rules. The startup world will never be fair, and you have to seek every advantage you can get.

You never know where your advocates are going to come from. Since most of the coaches are startup types themselves, they might be willing to help.

Be laser focused

You don’t have to have every page completed, you need just enough to tell a story.

Showing one use case effectively is good enough. Your pitch is only a few minutes, and the coaches aren’t going to go down every user flow. They will ask more questions around the business model and potential pivots than asking if you have the Lost Password screen done.

Successful startups are laser-focused on their idea, and anything that distracts them from it, they ignore.

Stuff to check out

]]>5609http://www.usabilitycounts.com/2013/11/22/startup-weekend-five-tips-ship/Infographic: So You Want To Do a Startuphttp://feedproxy.google.com/~r/UsabilityCounts/~3/uIpw4-snYVY/
Thu, 14 Nov 2013 02:00:11 +0000http://www.usabilitycounts.com/?p=5598Yup, that’s about right. You just finished reading Infographic: So You Want to Do a Startup! Consider leaving a comment!Stuff to check out UX Drinking Game | UX Resume and Career Guide

Stuff to check out

]]>5598http://www.usabilitycounts.com/2013/11/13/infographic-want-startup/Dogs & Cats: How Product Managers Can Work Better With UX Designershttp://feedproxy.google.com/~r/UsabilityCounts/~3/4kR8-LLdGyg/
Sat, 26 Oct 2013 18:20:51 +0000http://www.usabilitycounts.com/?p=5593Thank you for all those attended this session at Product Camp Seattle 2013. You just finished reading Dogs & Cats: How Product Managers Can Work Better with UX Designers! Consider leaving a comment!Stuff to check out UX Drinking Game | UX Resume and Career Guide

Stuff to check out

]]>5593http://www.usabilitycounts.com/2013/10/26/dogs-cats-product-managers-%e2%80%a8can-work-better-%e2%80%a8ux-designers/Why I Love User Storieshttp://feedproxy.google.com/~r/UsabilityCounts/~3/5BTeG0f5Y1Y/
Fri, 11 Oct 2013 15:08:14 +0000http://www.usabilitycounts.com/?p=5581While they may not replace high-level product requirement documents in all organizations, they can be used to break those requirements into bite-sized pieces that are easier to digest, understand, and build against.

Stuff to check out

They’re a great way to communicate requirements. Combined with epics, user stories tell a product narrative so everyone understand the essence of what they are building, yet don’t restrict creativity.

User stories are an outgrowth of agile methodologies, and are used to state requirements without writing endless pages of documentation. Groups of user stories are called “epics”, and if a user story is too big, it can be broken up into smaller stories for the developers to work with.

While they may not replace high-level product requirement documents in all organizations, they can be used to break those requirements into bite-sized pieces that are easier to digest, understand, and build against.

As an actor, role, or persona, I want to complete a goal so that I achieve this value.

Example of user stories for a system would be:

As a common user, I want to be able to sign in so I can use the system.

As a shopper, I want to be able to checkout so I can purchase the items in my shopping cart.

I’ve been writing user stories for years and have worked with product managers to write them. They are part of just about every single project I work on, big or small. The stories have been instrumental for getting to core user needs; I’ve used them as a checklist for software development and not depended on the whims of a stakeholder.

All user experience and product design professionals should become experts in writing user stories. Here’s why.

Establish requirements in plain English

User stories are written in plain English so both the product owners and engineers understand what is being achieved

Sometimes when product management writes use cases or other product requirement documents, the content is in the language of the domain they are working in. An accounting system might talk about requirements in terms that are familiar to the product owners, which is accounting terminology. However, most engineers aren’t accountants. Unfamiliar jargon and technical terms create confusion, and confusion leads to features that don’t meet the initial requirements.

That’s where user stories come in.

User stories are written in plain English so both the product owners and engineers understand what is being achieved. They are the glue that binds high-level product requirements to wireframes. Every member of the three legged stool — Product Management, Design, and Engineering — can relate to the user story and agree about what it means. The stories can also be used to write test cases, because they contain an achievable goal.

Drive user research

The user story is tied to a persona, actor or role using the system, which should force upfront research.

During the requirements process, personas and user research are sometimes forgotten while writing the use cases. Or the personas are so buried in the requirements they are hard to find.

As documentation grows, we lose the users in the forest as we document the trees.

User stories do the opposite: users are incorporated right into the requirements so all parties know exactly who they are designing for. It’s usually within the first three words of a user story: As an actor, role, or persona. It might be all users in the system — for example, sign-in is used by every user that interacts with the system. Or it might a single role: a database administrator might be the only role that users a feature.

The user story is tied to a persona, actor or role using the system, which should force upfront research. That means more work at the beginning (that you should be doing anyway), but results in less work overall.

Freedom to create within constraints

All user stories are a starting point.

There’s nothing more demoralizing than a use case document that spells out exactly what a designer or developer should build. While it establishes guardrails, it also limits creativity.

The best thing about user stories is that they are precise enough show value, but allow room to improve and iterate. Good user stories generate discussion, collaboration, and rework of the stories to make sure the value is communicated. This discussion encourages conversations about what the designers and developers should build, and allows freedom to be imaginative and innovative.

All user stories are a starting point. If you have a good team they will lead to other stories that are more expansive and provide more value to the user.

Clear demonstration of value

The worst thing about long requirements documents is that the value to users gets lost in those requirements. Pages and pages of documentation are written, and it’s not obvious why the developers are building the features specified.

User stories are the exact opposite of that — within every story is the value the user is getting out of the feature, plus that value can be illustrated in how it relates to the system. This allows user stories to be ranked based on their value. Sign In, for example, is required for most applications. However, that feature is needed even before favoriting an item, so the sign-in user story would be ranked first.

Less to maintain

The biggest waste of time I’ve ever gone through? Writing 1,200 pages of documentation for a software development project. Every time a feature changed, multiple pages had to be rewritten. Sometimes, I would be rewriting 500 words a day just in change requests.

User stories are easy to maintain, and direct the effort to where it should go: on building the final product. Most of the time I’ve written user stories in Excel, and they’ve also made it to tools like Trello, Asana and Basecamp.

Where to start

Talking about user stories is great, but here’s how to get moving on them:

Nearly every application has a base set of stories that are needed to launch. If you start there, you’ll get practice on writing them and understand the format. Collabnet offers a good primer on different user story formats.

Write them with your team members. If you work closely with product managers or developers, pair up to write the stories so all team members understand the effort that goes into them. Ironically, writing less is often harder than writing more, so you may spend over an hour writing a single user story.

Test different formats. Figuring out the right communication style for your team is key. There are several different formats for user stories that are worthwhile, and which one ends up being used can be based on team preference.

Remember user stories cut through reams of over-specified documentation to get the heart of what your user’s need, and make your life as a designer easier.
Use them.

Stuff to check out

]]>5581http://www.usabilitycounts.com/2013/10/11/why-i-love-user-stories/Mike Monteiro: How Designers Destroyed The Worldhttp://feedproxy.google.com/~r/UsabilityCounts/~3/aM3PtPm-oKY/
Fri, 11 Oct 2013 02:02:18 +0000http://www.usabilitycounts.com/?p=5579This is a great video. We all should watch. You just finished reading Mike Monteiro: How Designers Destroyed the World! Consider leaving a comment!Stuff to check out UX Drinking Game | UX Resume and Career Guide

Stuff to check out

]]>5579http://www.usabilitycounts.com/2013/10/10/mike-monteiro-designers-destroyed-world/Five Approaches To Creating Lightweight Personashttp://feedproxy.google.com/~r/UsabilityCounts/~3/kY8MPwc6XVQ/
Tue, 10 Sep 2013 15:00:19 +0000http://www.usabilitycounts.com/?p=5512Understanding your audience is essential to building great products. The first questions for any project should be "Who are we designing for? What are their goals? What are their motivations?"

Stuff to check out

]]>There is always time. Understanding your audience is essential to building great products.

“So who are we designing for?”

That should be the first question of every single project.

It should be followed by, “What are their motivations?” or “What are their goals?” If you don’t know who you’re designing for, wireframing is a waste of time. I was once at fault: I would start projects without doing user research because I never thought there was time. After a few failed projects and wasted hours, I started every new project with at least some research so I could understand the target audience.

There is always time. Understanding your audience is essential to building great products.

One cost-effective approach of modeling your audience is personas.Personas are user models derived from data to solve design questions. They are not new (my apologies to Alan Cooper), but are a derivative of market research with origins in the 1920’s. Personas are valuable, but are biased because they are based on assumptions and data selected by error-prone humans.

Well constructed personas work because they are a starting point to define the users the product owners should identify with. They narrow the design focus and generate questions like “How would much value would this persona have for this product?”

Even at the beginning of the project, you can construct provisional personas because having something is better than having nothing.

Pitch the client or your boss on spending some time performing customer visits. Once you have your personas built out, most smart product owners will understand their value and will want to put more time into understanding their users.

Even without access to your users, you can still build lightweight personas. Here’s a few approaches.

Ask the client

Some clients have a pretty good idea of who they want to market to, and you can tailor your personas that way.

A friend of mine recently designed a website for a wine maker. The initial assumption was that there would be a certain market segment of end customers that the wine maker would want to sell to.

The answer from client surprised him: the wine maker wanted to market to retailers that would be interested in carrying the wine in their stores, not to customers that would buy the wine online. While that significantly narrowed the audience, it dramatically changed to website approach.

With the client’s help, he was able to develop content and branding that had a laser focus on the audience.

Some clients have a pretty good idea of who they want as their customers, and you can tailor your personas that way. Understanding what they want out of the site or the application is a good starting point. It also helps you understand your client’s needs, and you may able to educate them about personas they should be considering.

However, most clients can’t answer this question clearly (or the answer is “everyone”).

Use Wikipedia

Most Wikipedia pages contain enough data that you can infer a lot about a place without visiting.

One project I worked on was the Municipality of Anchorage website.

There was a budget for doing user research, but flying a team of consultants to Alaska from Los Angeles was an expensive proposition. We had to build provisional personas before the first customer visit.

We used Wikipedia and other websites that contained data about the city. The government workers provided research performed by another firm about website needs. While it’s not perfect, most Wikipedia pages contain enough data that you can infer a lot about a place without visiting. In addition to the research, we validated our assumptions with stakeholders and by talking to residents informally.

Things about Anchorage that would surprise you:

Anchorage is a college town. Roughly 25,000 students, or 10 percent of the population, go to four year schools.

Ted Stevens International Airport is the third busiest freight airport in the world. Over 95 percent of the freight bound for Alaska is routed through Anchorage. Most of the air shipments that go through Alaska leave Anchorage because it’s a major refueling stop between the U.S. and Asia.

It’s all about the government and natural resources like petroleum. Flights to and from Anchorage are full of oil workers — something you learn just by being on the flight there and back.

Visitors from outside of Alaska use the city website. We determined from website traffic that many website users were potential visitors that wanted to learn about the city.

We found that many people also move to Anchorage because it’s either a lifestyle choice or they’re assigned there to work (for example, there’s several armed forces bases in the region). We used all this data to develop personas that included needs for visitors, business owners and residents, and made recommendations on content strategy that the city employees followed.

All these additional resources increased the value of the website for very targeted audiences. The personas were determined early on through research without talking to a single user, gave us a head start on redesigning the site.

Get out of the building

Sometimes all you need is three personas to get the conversations about customers started.

Sometimes all you need is three personas to get the conversations about customers started.

If you’ve attended my presentations, you’ll know that I bring up Bob The Chiropractor as a great example of a website where we did a lot of guerrilla user research to figure out what he needed in a site. The budget for my time was several beers.

Bob Benaderet is an online marketer that happens to be a chiropractor, and his business approach reflects that. He didn’t want advertise in the Yellow Pages — studies have show the return on investment is terrible when compared to online advertising — so most of his advertising is digital. The website and social media strategy were key to his business.

We spent time driving around the neighborhood and talking to local residents. We learned that many of his potential customers lived in apartments and talked a lot to their neighbors, didn’t have comprehensive health insurance, and needed immediate access to care.

Build a low-cost price structure: Many potential patients couldn’t afford medical care and were looking for a low cost solution.

Emphasize the relationship: While one persona was about the quick fix, another persona was about a long term relationship with a caregiver.

Keep the local feel: Residents live in Long Beach because they have pride in their community.

The strategy worked — his website converts at a 12 to 14 percent rate, unheard of in website marketing. It has done so for the last five years. He’s years ahead of his business goals because he understands his customers, and has build a very loyal base.

Stay in the building

You may work on projects that are confidential enough that doing user research and testing outside of the building is risky.

My solution: build provisional personas then find people in the building that match them to validate your assumptions. Most companies working on these kind of projects are big enough that you can find people in the building. If you’re working at a company like that, you’re may be in the target audience yourself.

Apple is probably the best example of this. Apple designers are emotionally tied to their brand and are in their target audience. They don’t do external focus groups. They work together in teams that develop ideas collectively and share feedback that results in great products.

There’s no way you can argue with the success of that approach. While not every Apple product is perfect, they’ve built a very successful company through this kind of design culture because they have an absolute understanding of their users.

Research your competitors

Each tiny detail related to an actual persona and contributed to a better experience.

Have competitors in the space? Use them as a starting point.

I worked on a project that was e-commerce based. Much of the research I performed was based on other e-commerce websites that had customers close to the client’s target audience. Not only could I glean a lot of best practices the other sites had spent time perfecting through their usability, but I could also develop an understanding of the merchandising and content strategies they used to reach their target audience. From this I developed provisional personas and very targeted user stories. This lead to design questions.

For example:

How do you ship a purchase to parties in different locations for the sample purchase?

How do we handle visitors that come to the site only once a year?

How do we handle visitors that come back every Tuesday to buy more stuff, and make their login process as seamless as possible?

This lead to user stories like “The shopper should be able to select shipping addresses at the item level” and “The shopper should be able to checkout without creating an account.” Each tiny detail related to an actual persona and contributed to a better experience. The end result was millions of dollars of additional revenue. All without talking to a single user of the website.

The upshot

There’s really no excuse for not performing user research. It’s easy and its necessary: every member of your team from the product manager to the front-end developer has to understand the customers in detail so they can build an effective product.

Model the personas, post them on the wall, and then bring some users by to test your assumptions. This will generate insights about their needs and motivations. As more and more feedback comes in, you can refine your personas and course correct your assumptions.

Stuff to check out

]]>5512http://www.usabilitycounts.com/2013/09/10/five-approaches-creating-lightweight-personas/Five Things I’ve Learned From Usability Testinghttp://feedproxy.google.com/~r/UsabilityCounts/~3/FYVWJhGwofE/
Tue, 20 Aug 2013 15:00:53 +0000http://www.usabilitycounts.com/?p=5471I’ve also learned over time about how to get more effective feedback. Humans are very predictable in our unpredictableness. If you watch for certain patterns, you can increase your ability to discover insights that are normally hidden.

Stuff to check out

There’s nothing like putting your assumptions to the test in front of users. Not only do you get to see the your work in the wild, you’ll frequently get amazing ideas from users because they use the system everyday.

It’s something you have to make time for. I’m surprised by how many designers don’t. They should spend less time drawing and more time talking to users. You know, get out of the building.

I’ve also learned over time how to get more effective feedback. Humans are very predictable in our unpredictability. If you watch for certain patterns, you can increase your ability to discover insights that would normally be hidden.

It’s best to do it within the context of their environment

I’ve found it’s best to emulate the environment users are normally in when they use your application.

The first few usability testing sessions I was involved in were the sort of thing that marketing people love doing: one-way mirrors with a moderator and five or six people sitting on the other side of the mirror. We would sit on the other side, take notes, and frequently joke about users while watching them.

A lot of fun to watch. And sometimes completely useless. All usability testing is biased — seriously, if you pay someone, are they really going to be honest — so your goal is to limit the biases as much as possible. We can still learn alot, so that’s why we continue to test, biases or not.

I’ve found it’s best to emulate the environment users are normally in when they use your application. For example, I wouldn’t do a test for a mobile map app where they are sitting down — they should be walking around, looking for the place. I’ve performed that test with someone holding their phone, and the metric was, “did they get to their destination?”

For other applications, I perform a lot of guerilla usability testing with users at their desk. This gives a better understanding of the application they are using in relation to their environment on a day-to-day basis.

I recently did a test with a client where the users had to interact with three to four applications during their daily tasks. I could see what other applications they were using (Salesforce, Excel, and Outlook were three, as well as six other browser windows). We took notes while watching the interactions and came up with a list of workflow suggestions that involved applications other than the one I’m designing for.

Watch what they do, not what they say

When you call it “usability testing,” end users may view it as a test of their knowledge, not the usability of the application.

Most people love to help, so they’ll be positive just about everything you put in front of them, called Social Desirability. I’ve been through a few usability tests where the user was talking about how much they loved the application. “I love it! I could totally see using this,” they would say.

It was obvious they had no idea how to use the application.

When you call it “usability testing,” end users may view it as a test of their knowledge, not the usability of the application. They don’t want to look stupid, so they’ll talk about how they understand how to use the website or focus on the task more so they won’t make mistakes. Most people love to help, so they’ll be positive just about everything you put in front of them. This alone might be a series of posts I could write.

Watch what they do and how they are reacting to the application on the screen and try to match it up with their comments. Sometimes I record mouse movements so I can get a more accurate representation of what the user was doing, but I usually just take rough notes on the interactions.

Getting people to talk is easier than you would think

Ask them three questions, and they’ll tell you about everything.

When I worked at Jobvite, I extensively interviewed recruiters and hiring managers. There’s no easier group to get feedback from than recruiters.

Ask them three questions, and they’ll tell you about everything. What they had for lunch. Who they last interviewed. What they like about their job. And more importantly, how they use technology — if you guide them. Recruiters talk a lot during the day, but no one really listens to them. When they get the chance, they will gladly talk.

They are not unlike most people — people just want to be heard, because we are a broadcast society. As designers we give them an opportunity for that dialogue, and that gives us the chance to get some real insight into not only how they use the technology you are testing, but how it fits in to the rest of their environment.

All you have to do is ask “Why?”

A lot.

That feedback is crucial to designing great products: understand the user’s pain points in detail, and you will be able to craft solutions to their problems.

The best ideas come from unscripted threads

It’s better to have a loose script, so you can think on your feet.

I’ve seen usability tests where the moderator drilled through an extensive list of questions, took notes, and walked away with almost no feedback of value without even knowing it.

I’ve also seen usability tests where the moderator had a really short list of questions, let the users talk their way through some great ideas, and walked away with product changing feedback.

It’s better to have a loose script, so you can think on your feet. If you can learn how to do that, the tests have more a serendipitous approach which will result into drilling into a particular line of questioning. This is where the real gems come, because you’ll get deeper and deeper into a topic and achieve true user understanding.

A complete prototype isn’t needed to test your concepts

I cannot tell you how many times I have used half-built prototypes to test ideas.

Before we even start, I tell the users that this is a representation of some of the ideas we are trying. I also tell them it’s a prototype, so some things may not work. The prototypes are usually high fidelity enough that they forget this.

I send them to a link. They click on it. It breaks.

“Why did it break?”

“It’s a prototype, but it’s not complete. We’re trying out some ideas. So, when you click on that link, what do you think should happen? Could you explain that step-by-step?”

Most of the time, they’ll do a decent job describing the next steps. What’s really cool is when you happen on a user that describes something step-by-step, you confirm their thoughts and their eyes light up like Christmas. Even better, they give you a great idea that you would have never thought of.

Usability testing isn’t just about testing your current design — it’s about leveraging your users’ collective experience to improve on it. Those ideas will not only validate what you’re working on now, but also make their way into the roadmap as your product grows.

Are you learning from your users?

Make time.

Ask why.

Listen.

It’s not hard, but you should do it everyday, whenever you can. What you learn may surprise you.

Stuff to check out

]]>5464http://www.usabilitycounts.com/2013/08/16/colin-harman-how-would-you-like-your-graphic-design-fast-cheap-or-good-pick-two/Here Are The Hard Skills You Need To Succeed As A New Designerhttp://feedproxy.google.com/~r/UsabilityCounts/~3/hMOnFV2iFYw/
Tue, 13 Aug 2013 15:06:00 +0000http://www.usabilitycounts.com/?p=5433Many of my friends either manage or mentor teams of designers. Their main complaint about new designers? They’re unprepared for the real world of interaction design.

Stuff to check out

]]>Many of my friends either manage or mentor teams of designers. Their main complaint about new designers?

They’re unprepared for the real world of interaction design.

There seems to be a disconnect between what they did in college versus the nuts and bolts of interaction design that need to be done in companies. They don’t have the skills for Lean UX or even for building wireframe after wireframe. So if you’re a new designer just out of college or a class like General Assembly and think you’ll be the next Steve Jobs in two years, you need a dose of reality.

After you’re hired, your boss doesn’t care about your degree from Carnegie Mellon unless you’re building jets or tanks. For other programs, they’ll care about it even less, because the programs are misaligned with real world needs. You may dis your boss for not having the degree, but they’ll have real world experience, awards and more credibility than your college instructors. And many didn’t spend $125,000 to get where they did.

After you’re hired, your boss doesn’t care about the exotic usability project you did about cell phone usage in Uganda during college. That project may be awesome, but it has limited application to the real world of their job. What your boss wants you to do is design a SharePoint intranet. In Seattle. For engineers.

After you’re hired, your boss may care about the visually stunning work you uploaded to Dribble. And it’s only because they know you can resize images in Photoshop, and they have 100 of them that have to be resized because they don’t have a visual designer.

What your boss cares about is filling a need right now. The person that gets hired is usually culture fit first, but also has the right skills (or can learn them) second. If you have fewer skills than other candidates, that makes you less valuable. When you’re a junior designer, flexibility and the ability to learn quickly is the key.

Interaction design isn’t hard, and usually doesn’t require an advanced degree. What it does require is a few skills. If you have these skills, you will always be employed.

The ability to write and tell a story

Almost every designer I have hired possessed exceptional writing skills.

Writing is an essential part of our job. Whether it’s writing annotations, composing help text, or performing content strategy, the words we use and how we structure them affect the usability of the applications we design. Whatever the words are, they have to positively affect the user experience or adequately explain to your engineering team what you want built. Just explaining what a valid email address is, for example, can take half a page in a specification.

You may have to do anything from constructing a simple help dialog to writing 1,200 pages of documentation for an FDA approval, but the ability to write well will reward you well in your career.

Almost every designer I have hired possessed exceptional writing skills. Some were former journalists. They had written everything from help content to marketing materials. They understood writing tone, style, and audience. They understood how to tell a story within the context of their audience.

Do you?

The ability to use tools like Omnigraffle, Visio or Axure

Whatever you’re doing, you shouldn’t be reinventing the wheel because they’re looking for you to follow instructions more than anything else.

It’s great that you did a six month research project in college on different shapes of steering wheels and how they affected the driving experience, or you’re a senior designer that’s coming in as a contractor.

Your boss probably doesn’t need a lot of the fluffy stuff. They need to get stuff done. They want you to wireframe. For some crappy intranet. On legacy technology. By Tuesday.

You’re going to be following someone else’s lead by fixing someone else’s wireframes. You’ll make minor corrections, fix typos and rework wireframes because a redesign is out of scope or can’t be built because the technology is screwed up. You’re going to be using someone else’s research, or maybe the research isn’t needed because you just have to follow best practices.

Whatever you’re doing, you shouldn’t be reinventing the wheel because they’re looking for you to follow instructions more than anything else. Make yourself invaluable by learning the basics of multiple wireframing tools. Omnigraffle, Axure, Visio, and Balsamiq are some of the best tools out there — learn enough about them so you can be proficient with them on day one.

The ability to prototype

You don’t have to be a gourmet chef to work in the design kitchen, but you do have to know how to cook.

The ability to take chicken scratches from a whiteboard and turn it into a clickable prototype will make you your boss’ best friend.

Why?

Because they don’t want to do it. Remember that your job is to do the work no one else wants to do. If you complete these tasks, you’ll be rewarded in the end.

It’s been years since some managers had to build prototypes. Many may not have at all. They came up during a different time where emphasis was on research and documentation, not testing new ideas quickly. Those managers look to their new hires to do it, and with many companies going to smaller teams, this will be an important skill going forward.

Frameworks like Twitter Bootstrap and Foundation have pre-built components that make it easy to produce prototypes that are good enough to test users against. Today, I would ask for this skill before wireframing because this is not only the quickest way to get a product tested and built, but you’ll understand the technology you’re designing for.

You don’t have to be a gourmet chef to work in the design kitchen, but you do have to know how to cook. This is evident in the junior designer job descriptions.

The ability to make best guesses based on limited research

Most of the time, you’ll make design decisions based on best practices and best guesses.

New designers think they’re going to spend months of time researching every nuance of a product or feature — a request that I actually received once from a junior designer I managed.

Early in your career, long-term research projects almost never happen. You might have to design an intranet for users you’ll never meet. Or you may have to design a public website where you have to approximate what the personas want by using Wikipedia to research local demographics.

Most of the time, you’ll make design decisions based on best practices and best guesses.

You’ll consistently ask “why” of your team members. You’ll look at competitors and figure out the design patterns they use. You might use frameworks, or determine other tools like Excel are better for performing some user interactions because your development resources are limited. Whatever it takes, you’ll learn that saying “I don’t know” will be your best friend because you’ll quickly learn how to find solutions.

Conclusion

No matter what you learn in college, it’s the basic skills of being an interaction designer that will take you far in your career. Interaction design isn’t just research, it’s about the ability to use your hard skills to execute on the findings you have–whatever shape they make take.

The better you understand this, the better off you will be in your career.

Stuff to check out

]]>5433http://www.usabilitycounts.com/2013/08/13/here-are-the-hard-skills-you-need-to-succeed-as-a-new-designer/Web Designer Depot: To App, Or Not To Apphttp://feedproxy.google.com/~r/UsabilityCounts/~3/4tjhJKMCrLo/
Mon, 12 Aug 2013 18:00:20 +0000http://www.usabilitycounts.com/?p=5425Great infographic by Web Designer Depot. You just finished reading Web Designer Depot: To App, or Not to App! Consider leaving a comment!Stuff to check out UX Drinking Game | UX Resume and Career Guide

Stuff to check out

]]>5425http://www.usabilitycounts.com/2013/08/12/web-designer-depot-to-app-or-not-to-app/Silly Saturdays: Why You Should Be Drinking More Whiskeyhttp://feedproxy.google.com/~r/UsabilityCounts/~3/cRI61aPzcKs/
Sat, 10 Aug 2013 20:00:40 +0000http://www.usabilitycounts.com/?p=5318Seriously. It’s true, all of it. You just finished reading Silly Saturdays: Why You Should Be Drinking More Whiskey! Consider leaving a comment!Stuff to check out UX Drinking Game | UX Resume and Career Guide

Stuff to check out

]]>5318http://www.usabilitycounts.com/2013/08/10/silly-saturdays-why-you-should-be-drinking-more-whiskey/How To Turn Off Amber Alerts On Your IPhonehttp://feedproxy.google.com/~r/UsabilityCounts/~3/I69xjcbkTKM/
Thu, 08 Aug 2013 16:43:03 +0000http://www.usabilitycounts.com/?p=5414Imagine my surprise when my phone went off at 1:48 a.m. with an AMBER Alert. I agree that the Hannah Anderson story is a sad situation, and I think it’s even more useful that there are now Emergency Alerts on an iPhone. However, I’m pretty sure I’m nowhere near where they are at, and the […]

Stuff to check out

]]>Imagine my surprise when my phone went off at 1:48 a.m. with an AMBER Alert. I agree that the Hannah Anderson story is a sad situation, and I think it’s even more useful that there are now Emergency Alerts on an iPhone. However, I’m pretty sure I’m nowhere near where they are at, and the location based targeting needs work.

There should be some rules when certain non-essential alerts are not sent (like, not 1:48 a.m.). We should be able to configure what time we can receive the alerts.

In the mean time, here’s how you turn Amber Alerts off on your iPhone.

Select the Settings Icon

Select Notifications tab

Scroll all the way down to the bottom to the Government Alerts section

Stuff to check out

]]>5414http://www.usabilitycounts.com/2013/08/08/how-to-turn-off-amber-alerts-on-your-iphone/The Redesign: Questions To Ask Before You Starthttp://feedproxy.google.com/~r/UsabilityCounts/~3/VjgxELlTrMc/
Wed, 07 Aug 2013 15:50:10 +0000http://www.usabilitycounts.com/?p=5387Redesigning your application the right way means putting pieces in place to make sure you can change culture and keep your job. Doing it wrong can get you fired or kill a company.

Stuff to check out

]]>You start a new job at a new company. They talk about infusing design thinking, and the VC’s get all excited. Images of awards go dancing through the CEO’s head and the company is heralded as the next Apple.

A year later the design team is fired, nothing gets launched, and the legacy product design keeps plodding along. It’s status quo, but the company slowly moves towards profitability and a sale.

Hundred of thousands of dollars are down the drain because of political miscalculations, and a culture of design never was adopted. What went wrong?

Doing a redesign right means putting pieces in place to make sure you can change culture. Doing it wrong can get you fired or kill a company. You aren’t just redesigning an application; you’re hopefully redesigning a culture that has higher expectations. Change like this is tremendous, and affects every department in the company.

Here are lessons learned from observations and personal experience. You should ask yourself these questions before starting the process.

What’s the weather forecast?

Do they have the capability understand design? Does someone at the executive level call you a “Userability Expert” or have they worked with Interaction Designers before? Do they even follow some kind of established process?

Before you can start a redesign you have to understand your environment. Take the first few months doing a “design 360” of the business. Judge the capabilities of the team. Determine if they can allocate the right resources to a redesign. Learn if your users want a redesign.

Determine up front if you want to play the long game — slowly putting the pieces in place so design is part of the culture.

It might take months. It might take years. It might never happen. Whatever the amount of time you think it’s going to take, double it. And then think about if you want to stick around and see it through.

Should you ask for permission?

Your roadmap has to be the same as your boss’ because his job is on the line, too.

Ask the VP of Something Something, “What’s your vision for my job?” This conversation is a good indication of whether your boss is someone you can work with and if design thinking is something that’s important to both of you. For this to work, you have to have advocates, starting with your boss, because they are also putting their job on the line.

When the redesign on the roadmap and the resources can be put in place to make it happen, present a plan to get there. The ROI has to be there: what seems to be a simple redesign can cost hundreds of thousands of dollars and has to generate that much revenue to make sense. If the company is willing to take that kind of risk, present your case with data, case studies, and competitive analysis documents to show that design thinking can help the company leapfrog their competitors.

Sometime, asking for forgiveness instead of permission doesn’t just put you in a bad spot, it puts everyone above you in a similar situation. If you do go that route, you better hit it out of the park because it might be the only way to save your job.

Who’s driving the bus?

What’s the company’s dominant culture? Is it engineering? Is it sales? Is it marketing? Is it product?

It’s like playing a chess game — you have to get your pieces in place before you make the next move.

Put together a company structure in your head. Learn who else you have to educate about design thinking before you embark on that redesign. Not only do you have to get your boss on your side, there might be a few other people within the company that will be useful advocates. This will take time.

It’s like playing a chess game — you have to get your pieces in place before you make the next move. You may have to sit down with a lot of people to understand how your desire to do a redesign will impact their ability to do their job.

Are the resources capable, competent, and plentiful?

Can your engineering team cash the checks you’re going to write? Do you have enough resources to do it well? Is the product team committed? Can customer service handle the transition gracefully?

It’s one thing to sit in the corner and prototype beautifully. It’s another thing to get that prototype implemented in a production environment. Sometimes making that transition will mean having the right pieces in place to complete that redesign.

Sometimes I realized early during a redesign on that the engineering team couldn’t deliver, so I had to recruit resources myself to put the right team in place. Be prepared to do that in your situation.

Can designer be integrated with the teams?

To build the right product design culture, you have to involve everyone in the process.

Can you sit with the product managers? Will you be equal partners in the three-legged stool of design, product and engineering? Will you be able to teach design, every day, or are you in a separate group?

Designers may think they want to be an agency in a company — but that is what isolates us most. We should be part of product development, not a service component, where the designers act only at the request of product managers. This fails to deliver great products.

To build the right product design culture, you have to involve everyone in the process. You have to educate people one day at a time. The best way to infuse design thinking in a company is to build teams where designers collaborate with other team members. Sketch ideas, post screens on the wall, and involve everyone in the process. If they see the design and want to contribute, they’ll get involved. It’s collaborative and requires everyone to be on board.

A non-collaborative environment creates silos and gatekeepers. This never leads to a design culture.

Is a redesign really needed?

Are you losing users? Is revenue still growing? Is there other reason your losing to your competition, like product direction?

The first instinct of any designer it to redesign, because they want to make it their own.

A couple years ago I designed a website for a friend’s business. It’s a bit dated, it’s not responsive, the content should probably be rewritten, and a design refresh would be nice. But does it really need a redesign? No.

His site, BobTheChiropractor.com, converts at a 15 percent clip, and has done so for years. His customers love him. The general consensus is “Let it be” because it works.

The first instinct of any designer it to redesign, because they want to make it their own. This is obvious after watching the uproar about iOS7: Every designer is turning their dribble account into their own personal iOS7, as if they’ll be hired tomorrow to assist Jony Ive.

A redesign may be a poor business decision. If you watch many of the major web properties, they go for years before doing a redesign. Some sites don’t redesign at all because there’s no reason to. While that may increase the risk that users will use other better designed services, a redesign done poorly can kill a company.

Redesigns place stress on other parts of the business that may not be capable of handling it.

Designers should respect the business decisions that are made. Design is only one part of the business, and has to be balanced against the rest.

Conclusion

Being successful with a redesign isn’t just putting a fresh coat of paint on the application, it’s about changing the thought processes of a company. It requires the right game plan and asking the right questions.

Remember, it’s not about padding your portfolio, it’s about making a positive impact on the company. If it’s the right approach, your impact will be huge.

Stuff to check out

]]>5314http://www.usabilitycounts.com/2013/08/03/silly-saturdays-creative-director-fashion-guide/Become a Better Designer In Less Than An Hour: Four Wayshttp://feedproxy.google.com/~r/UsabilityCounts/~3/XAGc5NfAYHk/
Wed, 31 Jul 2013 18:00:08 +0000http://www.usabilitycounts.com/?p=5323Here's how you can become a better designer in less than an hour a day. You don’t have to do this everyday, but the more you do it, the more you’ll learn.

Stuff to check out

We want to put on our headphones, dive into Omnigraffle, and crank out wireframes. We design in a corner, without involving anyone else. But that’s not really design — it’s self indulgence for imposing your perspective on a product.

Well crafted interaction design comes out of understanding the environment through the eyes of our users: their wants, their needs, their pain points. It goes beyond the “what” so we can understand the “why.” Our craft requires us to study people and their motivations at a level that most will never understand. That requires us to learn, whether we are on the clock or not.

Here’s how you can become a better designer in less than an hour a day. You don’t have to do this everyday, but the more you do it, the more you’ll learn.

Write on a consistent basis

Writing teaches us how to tell better stories about our passions, and we can improve this skill every single day.

Writing this blog is a lot of work. I promise myself that I’ll crank out at least 1,000 words a week. However, I’ve become a better designer because of it.

The blog helps me define and express my thoughts. I’ve learned how to communicate more effectively. I have learned how to engage with a potential audience. Writing about user experience gives me conviction about what I believe, and also illustrates where I need to learn more.

Having a readership is a pleasant benefit.

When you write, you don’t have to write about user experience. It could be about anything: personal stories, topical stories, or practical stories about your craft. A friend of mine, Winnie Lim, writes a deeply personal blog and in doing so she has learned how to tell great stories. She values the one-on-one connection she has with her readers, and that’s how she learns. It’s her passion that overflows into her work.

Writing teaches us how to tell better stories about our passions, and we can improve this skill every single day.

Get out of the building

There’s nothing worse than than a designer that doesn’t do user research, because that research can be done anywhere.

There’s nothing worse than than a designer that doesn’t do user research, because that research can be done anywhere.

Here’s an example:

I love drinking at a bar called Tony Nik’s in San Francisco. When I was drinking there, I wasn’t just drinking: I was watching people use their mobile devices. Most of them were iPhones, but some of them were Androids. I would ask people questions about how they used them, what kind of applications they were using, and how such a device had changed their lives.

I was talking to users in a place that really was just anywhere.

It might not have been directly related to my job, but I learned how users interacted with technology. I frequently think about some of those conversations today. The same can be applied to your current situation — if you’re designing a consumer application, it can be done in a Starbucks. If you’re designing a SaaS B2B application, go visit the customer in their environment.

That’s what is being prescribed by Lean UX, it’s about getting out of the building. It’s not hard, we just don’t do it enough.

Reach out to other designers

Every conversation leads to more learning and deeper knowledge about our craft.

What I’ve learned most from talking to other designers is that much of our experience is shared. Talking to stakeholders, understanding users, difficulties with establishing process, we all do it, just in different ways. We all work in environments where User Experience is a new concept.

Another thing that I’ve learned is that every designer brings a different angle on those experiences to the table. We can talk about our struggles to educate others about the need for user experience, and we can also compare notes on successes. Our discussions may include methodologies, a portfolio review, or just trading banter over a new trend like flat design.

Every conversation leads to more learning and deeper knowledge about our craft. It can be in person, on Twitter, or over Skype. Where you have that conversation doesn’t matter as much as the conversation itself.

There’s power in sharing our experiences with others. It makes us better designers, because when we teach, we also learn how to express our stories.

Learn how to code

Learning to code turns into building side projects for you to play with and experiment.

There’s nothing better than understanding the tools needed to build what you design, and it gives you greater control over your destiny.

That doesn’t mean you have to learn Java, but prototyping ideas helps you learn the constraints of your craft. You’ll communicate more easily with developers that you work with, and maybe even provide solutions that are outside of the box.

Learning to code turns into building side projects for you to play with and experiment. A lot of enterprise software designers don’t get the chance to come up with new concepts for their applications internally, but they can experiment and play with ideas, even at work. You can even collaborate with developers to come up with new ideas, and some of them may take off.

If you learn how to prototype, you can bring that skillset in-house and learn while you are getting paid. Employers don’t mind this because it increases your value to the company.

The goal: Becoming a better designer by expanding your knowledge

Becoming a better designer is a very gradual process that requires a lot of of practice — think K. Anders Ericksson’s 10,000 Hour Rule, except you can learn faster through collective exploration and knowledge. These are just four approaches out of many that other designers take, and I would ask other designers what they do to learn.

It’s up to you to improve your skills as a designer — now go out and do it.