Archive for the 'Retweet' Category

I teach at General Assembly in Seattle as a Part Time UX Instructor. One task that pained me early on while teaching was watching students scour the Internet for templates they could use to do user research, create site maps, and record usability tests — especially documents that could be used by using free collaborative tools. So I created my own. All of them use free tools like Google Docs or Draw.io as the platform, and I’m releasing them to the wild.

As I reminded my students, as a designer you should never create anything from scratch. I may have “borrowed” some of these templates from other people. Additionally, some of the examples show what a Site Map can look like for common website patterns. Most importantly, they emphasize the research and usability testing portion of design, and are orientated to a lean approach of working with others.

Kudos to Rebecca Destello for encouraging me to share these documents. She’ll be using them in an upcoming class at University of Washington.

I would love to hear your feedback so I turned commenting on. The list will continue to grow as I continue to teach.

Draw.io Documents

We can talk about Design Thinking: Empathize, Define, Ideate, Prototype, Test for the uninformed. However, design is more framework and less process. It’s more guideposts, so you have a pretty good idea of where you are going, and adjust when it happens in asynchronous order.

How many times have you gotten to Test and realized you’re solving the wrong problem? It’s called learning. That’s why design thinking it’s is there so that you can back up and start again.

The gates help you have informed point of view, whether it is a start-up project or something that’s been existing for a very long time. The key is to go through the first steps of that process — Empathize and Define — in quick order, so you have a foundation to start.

Here‘s what I answer before designing a single screen.

Who are the users?

Start here: “This is the user, and the problem we are solving for them is…”

Most organizations have a pretty good starting point. Some, like Microsoft, have had personas out there for years and had the muscle memory to use them. For other organizations, especially startups that have lucked into the product-market fit, their personas are a mess. The good news is that personas are never truly finished and may change over time.

If you are designing, it’s always for someone. It’s better to get that someone out in the open so everyone has a common understanding.

Where to start

Start with provisional personas — a baseline of who the users are so you can revise them based on further research. There’s a lot of places within organizations you can start this research. We always had a Customer Success group that conducted research on users. It doesn’t take long, other than pressing an elevator button.

The artifact

Personas, at least three of them. They should pre-exist, and you’ve been using them to design. I wrote an article about creating lightweight personas, and don’t worry about them being right. Prioritize learning over correctness.

Estimated time investment

Less than a day if there are no personas, and 20 minutes if there are. The story always needs to start there.

How are they going to use the feature?

What’s missing from most product development processes is how the users are going to use features within in the context of their environment. Set time duration, other personas or actors that may interact with the product, and what other processes they use. Include offline process, other products, and unforeseen delays.

We did this a lot when at Jobvite: discussing how other products like Microsoft Outlook are used to accomplish the task outside of the application. It was important to understand the hiring process, for example, and how the candidates would go through the workflow.

How important is this? If you ask more users what they want help with most, it’s to save time within in the context of their journey. They want their life to be easier.

Where to start

Write an implementation-free user scenario. State the steps the user will have to take go through the steps of using the feature, including any details on they solve the problem today. Emphasize personas and business process, and how long it will take. The time element is important because it might mean the difference between designing a step by step wizard and a different asynchronous guided process.

The artifact

The user scenario, ideally 500 words or less. People hate reading more than a page. A good way to test it is by reading it out loud. It should take 10 minutes to read it. Need an example? Go here.

Estimated time investment

A good first draft of a user scenario can take less than 4 hours, and there are a lot of good examples to draw from.

Do your products have a similar feature?

The most valuable 30 minutes of this process: Screenshots and URLs of what your product does today. Set the context of not only what the product is, and how your personas use it.

If you are working on an application, you should be familiar how it works, inside and our. Use your product at least a few hours a week.

While your wireframes may be your understanding, everyone else you are working with is living in the product.

Where to start

Document screen shots, so everyone has context. Other participants (i.e. Product Manager or Engineer) in the design process should also be able to do this. The act of documentation meets two important goals: setting the context and forcing the question, “Does this have a similar intent?” Writing and capturing content is a good thing because it forces thought much more than a verbal conversation.

In meetings, refer to these documents all the time. Ask, “Is this a pattern we can use to shorten development time and keep a consistent user interface?”

The artifact

Screenshots. Print them out and tape them to a wall.

Estimated time investment

You should be able to do this in less than few hours if the Product Managers are around. Sometimes it’s as simple as asking them, “We’re trying to solve this problem. Do any of your features do this today?”

Are there other products that fit the mental model?

The internet isn’t a blue sky thing where everything should be reinvented. There are established mental models users understand intimately.

The rule with my teams: Find five products, and talk to five people that may have used a similar product. Takes a day or less, and you get great ideas out of it.

For example:

Spreadsheets: The first electronic spreadsheet, VisiCalc, was invented in 1979 by software pioneer Dan Bricklin. Some spreadsheet applications date back to the 1960’s. The Excel team followed the mental model of other spreadsheets and just did it better. The pre-existing mental model forms the basis of a lot of other applications, like Google Sheets.

Shopping Carts: Online shopping dates back to 1979. There are millions of examples. Amazon is a good place to start.

Classified Websites: Craigslist is the baseline, but I’m sure there’s a cave wall somewhere in the world where someone etched selling an ox for corn to others in the settlement. Before the internet. Before print. Before almost everything.

Even the “new stuff” like Voice UX is not new. An acquaintance of mine, Philip Hunter, works on the Amazon Alexa team. His voice experience for automated systems predates Alexa by 20 years, and he holds patents in the field. It’s a pretty good guess he’s not making stuff up.

There are often barriers to finding examples in your domain. Our competitor’s software requires a significant purchase, which means we regularly don’t have access to competitors. So we look to other categories for the best ideas. If you understand that your users are using all kind of other applications, you can design something that’s familiar and fits their needs.

So now you know you don’t have permission to reinvent the wheel — invented in 3500 B.C. — let’s get to work.

Where to start

Use the same process you performed for your existing product. Find five or so other products that do the same thing and do your research. Admit that you’re stealing ideas and question their context. Use them as a baseline.

Put them in a document that everyone can access. Even better, post the screen shots on the wall in a hallway. You’ll involve more people in the design process, and they’ll suggest other “like” applications.

Artifact

A document containing screenshots. Print them out and tape them to a wall.

Estimated time investment

A day or less. Use Google Image Search.

Conclusion

The elements of this research are simple:

Understand the user

Understand environmental context

Understanding existing tools, internal and external

They’re essential for starting any design process, but they can be done quickly and efficiently within the constraints of your environments.

The time investment you need to make before starting up a wireframe tool like Axure — i.e. doing a bit of guerilla research that sometimes involves not talking to users — is important.

Yes, during your user research you’ll uncover other applications that they use, but if you this, you’ll have a good baseline to start from, which is more than most products have.

You’ve heard all the nightmares: it rains all the time, the traffic is 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. Read On…

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. Read On…

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

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. Read On…

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. Read On…

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? Read On…

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.

You’re running a startup. You ask the developers who the next hire should be.

“We need a unicorn.”

“What’s that?”

“You know, someone who can code, design graphics, design user experience, write copy, and do all the HTML and CSS for us. They’re cheap and easy to find. They should be able to take out the trash. Oh, and wash our cars wearing a bikini.”

And unicorns can fly.

The unicorn designer is the most in demand and rarest of product team members — someone with excellent interaction design skills, visual design skills, and coding ability. Unobtanium.

Unicorn designers exist, but they’re expensive, overworked, and generally can’t cover all the bases as well as advertised.

Unicorn designers exist, but they’re expensive, overworked, and generally can’t cover all the bases as well as advertised. The better ones have over 10 years of experience and the consulting rate to show it. If you get a good one, you’re going to be paying a lot.

Your job is to properly select resources and avoid needing a unicorn. If you have to hire someone to cover that many skill sets, you have failed at building the right team. Working with a great interaction designer is the most important decision you can make for the success of your startup. Design-led organizations succeed.

If you’re looking for a unicorn, many designers will pass because the request will show a lack of knowledge about building a team.

Here’s a few suggestions to avoid the “we need a unicorn” conversation.

I would hire an interaction designer that can build almost production-ready prototypes in HTML and CSS. They can build something that gets you to version one, and integrate outsourced elements if need be. They should also train the developers how to do front end development so they won’t have to later.

The other valuable and common combination is interaction plus visual design, because they can be utilized for producing marketing materials. If this is the skillset hired, the developers have to pick up the HTML and CSS.

Implement the “need three, pick two” rule for the rest of your team

Avoid stay-at-home defensemen: people that can perform only one role.

The reason most developers avoid doing front-end development is because it is time consuming and tedious. Developers are a precious commodity, but coddled developers lead to failed startups. If you’re working on a smaller team, its up to everyone to pull their weight. It’s part of the job.

Avoid stay-at-home defensemen: people that can perform only one role. If they are straight javascript developers, for example, they would be the first candidate for that second skill since they are already working on the front end.

If you have a team of at least two developers, one of them should be able to develop in HTML, CSS and jQuery. If they are missing those skills, or think it’s “someone else’s job,” seriously consider which one is worth replacing and find another one that fits your needs.

Also, consider other team members and their contribution: If you have hired a product manager than only wants to develop features, but doesn’t wireframe, write copy, do marketing or have other skills, they might be a liability. The same goes for the visual designer that is someone’s cousin: If all they know is Photoshop and can’t do HTML, they shouldn’t be a full time resource.

The most common reason why unicorns are needed is because initial team staffing wasn’t done right. It’s up to you to correct it.

Outsource certain tasks

The best thing about the web is that there are a tremendous number of resources to help you find part-time people.

The best thing about the web is that there are a tremendous number of resources to help you find part-time people. Will it be restaurant quality? No, but it will get you to an MVP.

Places where it is ideal to outsource (and where you can do it cheap!) are logo and visual design. Come up with rough layouts, and at the very least you can put it on 99 Designs for a few hundred dollars. The drag on that is there will be more overhead on your part to review submissions.

Front end developers can also be found through online resources like freelancer.com. They’ll take a photoshop file, slice and dice it, and give the final code to your main development team. There will still be integration time, but this may be a solution to this problem.

You can also bring in consultants to review your interaction design if you are doing it yourself. They’ll cost more via a day rate than you would pay them hourly, but in the long run the advice they give you may make or break your product.

Use templates and frameworks

Every startup that I’ve seen spend a lot of money on visual design early on ended up wasting most of it.

Your first design is not going to be the design you go with long term. You’re going to pivot, change designs, rejigger ideas. Every startup that I’ve seen spend a lot of money on visual design early on ended up wasting most of it.

The solution is to use Template Monster and other sites that have a ton of Photoshop and HTML templates that are pre-built, ready to go, and cheap — sometimes under $50. They are good enough so that your site appears professional when you go out to do usability testing with your interaction designer.

Included in the mix is Twitter Bootstrap, Foundation and other frameworks. While the initial iterations might look like hundreds of other sites, the frameworks are easy enough for most back end developers to use and will get you to something functional.

There are also a ton of templates for them, so you can skin another look and feel. I have an extensive list of resources that should get you to launch.

Keep it basic

Repeat after me — it’s not about the shiny, it’s not about the shiny, it’s not about the shiny.

It’s about shipping so you can test and pivot.

As much as you want your first version to be perfect, you’ll change your idea several times until you find market fit. The most important thing is to have the right guidance to help you find market fit, and that is most likely to happen with a great interaction designer.

You don’t need a Masters degree from Carnegie Mellon to practice user experience.

Every day thousands of people practice user experience in their jobs, and they do so without knowing it. And they might be doing it poorly, if they don’t understand the methods and practices that are used by designers to produce great products.

Researching the market, iteration, or other methods are unknown to them, and there aren’t a lot of publications that service this market of unknowing UX designers.

Aimed at the same market and a great companion to Eric Reis’ Lean Startup, the publication is a very concise overview of what user experience is and how you can apply it in just about any startup environment.

It purposely omits case studies because Laura feels that every situation is unique. Everyone should figure out a process that works for them, iterating until it works. Lean Process for doing Lean UX.

It doesn’t use big words

The book is an excellent guide for mid-career UX designers that want to move to a more iterative process and away from waterfall, and for founders that don’t have the money to pay for a user experience designer and would need to have a go at it themselves.

One of the biggest frustrations for non-designers regarding user experience books is that many of them use overly technical terms to describe some of the process that are used in the field. For example, I have a hard enough time pronouncing “ethnographic research”, much less spelling it.

Laura calls it what it is: “You know, listening to your users.”

She does this consistently throughout the book, explaining terms in a voice that is similar to what I love about her blog — taking complex concepts and explaining them in a way that doesn’t belittle the reader, unlike many other publications in our field.

Testing ideas quicker and cheaper

Engineers are expensive. Designers are expensive. How do you mitigate that cost?

Designing small prototypes and doing quick sketches with pen and paper that test your assumptions is the way to go, and Laura discusses tools that allow founders to do that. She specifically calls out frameworks like Twitter Bootstrap, which is revolutionizing prototyping, and wireframe tools like Balsamiq (which, ironically is what the wireframes in the book are done in).

There’s also solid commentary about the value of interactive prototypes — they take a long time to build — and discussion of when you should use a medium fidelity prototype (testing more complex concepts) versus something simple, like a visual change or a landing page for A/B Testing.

Quick, dirty, and cheap usability methodologies

She advocates methods that are much quicker, and more cost effective so that you can use many more of them.

If you’re working for Facebook, Google, or other large organizations, you have a lot of resources at your disposal — usability testing labs, eye tracking machines, and big budgets to spend on bringing in people that fit your target audience.

That’s. Not. Lean.

The book explains that this sort of testing, especially early on in the product development process, is a waste of time and money. She advocates methods that are much quicker (the book has a whole section on the value of guerilla user tests), and more cost effective so that you can use many more of them.

One of the methods she discusses that I have used personally is the Starbucks usability test: sit down in a local coffee shop, set up your laptop, and offer someone a free coffee to spend 10 minutes using your product. You would be surprised how many people are willing to do it, and I’ve done it several times, most recently for a startup project. We did the test at The Creamery in San Francisco, and we got a demographic that was a lot less techie than you would think.

Measuring every step of the process

The book covers a data-driven design process which explains the value of A/B testing, why it works, and how to use it properly.

Having been through the startup process one too many times, I’ve watched founders spend thousands of dollars on building a product without measuring their progress by gathering user data. They get to the end of development, release the product into the wild, and wonder how to pivot because of low user adoption.

(I think this is where I’m usually screaming at the client, “Your idea is never going to work” before launch, because nothing was tested in front of any live users other than the founder’s wife.)

The book covers a data-driven design process which explains the value of A/B testing, why it works, and how to use it properly. It also explains some of the misconceptions about A/B testing that are often brought up by user experience professionals, and how to overcome the fear of testing everything.

A discussion of when not to design

“Your goal for this type of design is to make things easy, obvious, and useful.”

Most founders get hung up on the shiny when they really should be focusing on user adoption, and this is well covered in the book.

If you’re doing a startup, those initial designs will usually end up in the electronic trash as you pivot and iterate your way to success. Especially in startups.

Laura makes this point exactly: “Your goal for this type of design is to make things easy, obvious, and useful.”

I personally care less about initial designs than the developers and product owners I work with, because I know it’s a starting point. I’ve heard time and again, the designer is the person that cares least about the color of a button.

Laura makes that point too: “I’ve seen too many companies spending time quibbling over the visual design of incredibly important features, which just ends up delaying the release of these features.”

And any delay for this reason will delay getting feedback from real users.

The Conclusion

The book is an invaluable resource for demystifying the Lean Process. It’s also an excellent guide for mid-career UX designers that want to move to a more iterative process and away from waterfall, and for founders that don’t have the money to pay for a user experience designer and would need to have a go at it themselves.

Designers like myself that have been using some of this approach for a long while before it was called “lean” will find this book a good validation of their methods.

Also, if you’re doing your own startup and don’t have formal user experience training, or you are a designer and don’t know how to build your own product, you should buy this book.

Many UX Designers are prototyping their designs using frameworks like Twitter Bootstrap, and building these prototypes has never been faster. The frameworks support responsive design, so you can develop for different breakpoints without breaking your head on the table.

Ideally, these frameworks should speed up front-end development if teams figure out out the right workflow. I’ve found these tools to be invaluable to speed development, and illustrate concepts to developers.

Here’s the list I have compiled, with descriptions from Wikipedia. It’s my list, so don’t be offended if you aren’t on it.

Twitter Bootstrap

A free collection of tools for creating websites and web applications. It contains HTML and CSS-based design templates font typography, forms, buttons, charts, navigation and other interface components, as well as optional JavaScript extensions. It is the most popular project in GitHub and is used by NASA and MSNBC among others.

NVD3A list of functions that creates some of the most common data visualizations.

RickshawA list of functions that creates some time-based data visualizations.

Angular JS

An open-source JavaScript framework, maintained by Google, that assists with running single-page applications. Its goal is to augment browser-based applications with model–view–controller (MVC) capability, in an effort to make both development and testing easier.

Bigger than Instagram! Bigger than Twitter! Bigger than Facebook! Bigger than Google!

Okay, maybe not. Still, it’s going to be huge. You’ve raised a little money (if you’re lucky), and you want to build a MVP, known as a minimum viable product. That’s the bare minimum you need to get a product out the door and so you can test your concept against customers.

Sounds easy, right?

Even for a MVP, it takes a village to build a product.

The village has several roles, and selecting the right team early can make or break your idea. Your village will never be of an ideal size, but understanding what you need from your townsfolk can help you make some hard decisions on how to staff the team. Early on, flexibility is the key. You may also have to split up the work if it’s a side project and everyone has a day job.

Even for a MVP, it takes a village to build a product. The village has several roles, and selecting the right team early can make or break your idea.

The composition of the ideal team has been a question that’s been on Quora, and great advice can be traced to a simple model that Dave McClure of 500 Startups advocates — Hustler, Hacker, and Designer — but it has to be viewed within the context of what you’re building. This article covers all the roles that go into building a product, and places where you can “cheat”, i.e. fill in with people that are in other roles. Minimum viable product projects are about building something to a level that gets you started, within extreme constraints.

When building the MVP, everyone’s favorite word should be “No.” As in, “No, we aren’t going to build a big product. We’re going to build something simple so that we can test our idea and see if it’s viable.”

And remember, it’s just not about the MVP, but planning for something bigger: use team members that can play multiple roles now, so you can grow and expand later. If your friends can’t perform the vital tasks of Sales, Marketing and/or Business Development, they might not be a good fit. The team will also vary depending on your idea — the roles needed for a tech-heavy idea differ significantly from something like Groupon or Uber, which are more sales driven.

Following are the typical roles of any software development team.

Each is essential to the success of a product. Each is priced pretty close to the others, depending on experience level. And each needs to be filled by someone who can perform that task. For example, if you don’t have someone in the role of UX Designer or Product Manager you’re still doing the tasks associated with that role — you’re just doing them poorly.

Product Management

A Product Manager is exactly how it reads: they manage the development and the feature set of the product.

It’s the ultimate jack of all trades position: they play several roles, but never have time to do any of them at an expert level.

They should be competent at a lot of things, like writing copy and distilling customer feedback. They own tasks that are pure strategy, like pricing, product roadmap, and product marketing. There are also tasks that are tactical, like day-to-day program management, and making sure everyone is marching in the same direction. That means having a lot of diplomatic skills, because everyone feels like they own the product with an MVP.

Great product managers have to understand technology, the business and the user — at the same time. If they don’t, they will be thrown to the wolves quickly, unmercilessly, and rightfully so. A product manager that doesn’t gain the trust and respect of the team is in trouble from day one. The ultimate test: being able to speak to the business, to the user, and to the technical solution at the same time, and lead without having direct reports. That’s hard.

Product managers should know how to prioritize their time and to delegate appropriately. If they’re working 60 hours a week, they probably aren’t very good at their job.

Product managers should know how to prioritize their time and to delegate appropriately. If they’re working 60 hours a week, they probably aren’t very good at their job.

What job titles should I look for? Product Manager, Program Manager, Project Manager. Some project managers have skillsets that are too narrow for Product Management.

Should I outsource it? Absolutely not — this is the idea role. If your idea is about user acquisition early on, you can skip some of the business modeling or hire someone else to do it. However, understanding your market is essential to the success of your MVP, because it’s going to change, a lot.

Who else can perform the role? A good Interaction Designer can cover 60 to 70 percent of any product manager’s role, so someone with that background can do it. One of the founders, possibly the idea guy, should be this person because they’ll care the most. The hustler can also bring ideas from the customers — the key is mining those ideas for great product features.

When should I hire this as a full time position? It depends. Early on, they should be playing other roles, like business development. In some organizations, a designer or engineer might also be acting as a product manager. They act as project management, and with the interaction designer, should be the hub of activity. The best staffing model is one product manager for every three to six developers.

What keywords should I look for in resumes? Most product managers should have a portfolio of products they can point to at being successful at. Look for the following keywords: Research, product marketing, product roadmap, copywriting, pricing models.

What’s a great interview question to ask? “If Dave McClure gives you a million dollars to build a product and a team, what does your product development process look like?”

Interaction Design

Interaction Designers are the people who design a product that will encourage adoption, engagement, and hopefully profitability. They are essentially the product architects — someone that describes the structure of what you are doing so everyone else can fill in the blanks.

Great User Experience designers are OCD about developing products, because the user is who matters most.

Great User Experience designers are OCD about developing products, because the user is who matters most. No engagement and no adoption means no startup, right?

They are trained to build usable products within established constraints, and usually are more familiar with the development process than most product managers. A good interaction designer will save you time and money because they’ll test features quickly with prototypes and say yea or nay. Getting actionable data early and often is invaluable for MVPs.

Should I outsource it? Risky, but it can be done under the right circumstances. This tends to be the hardest role to fill because good Interaction Designers are hard to find, and they like getting paid. This can also be the most essential role in a design-led organization, so depending on your needs you might be better off hiring a designer that can manage product than vice versa.

Who else can perform this role? You can hire a Visual Designer to do interaction design — many visual designers also claim interaction design as a skillset — but there might be an early emphasis on pretty over functional in the product, and this can mean death. The floors of the startup world are littered with the very pretty corpses of non-functional ideas. Or you can learn to do this yourself (This Triptrotting story is an example of founders that learned how to wireframe), but it’s really, really risky. Would you trust your open heart surgery to your cousin?

When should I hire this as a full time position? It depends. A great part time interaction design consultant can dramatically improve the product, but this also means they have no skin in the game. If they are acting as the product manager (many go this route), one interaction designer for every four to eight developers seems to work best. Pairing up an interaction designer with a product manager is ideal.

What keywords should I look for in resumes? Most interaction designers have an online portfolio, and should be able to explain their projects well. Look for the following keywords: Wireframing, Prototyping, User Research, Omnigraffle, Indesign, HTML, CSS, jQuery and Prototyping.

What’s a great interview question to ask? “What’s the best story you have to tell about building a product, soup to nuts, and how you created a great user experience?”

Visual Design

Visual Designers create the look and feel of the product, and are sometimes called upon to establish the the brand voice. They select the colors, the icons, and define the look and feel that will be implemented by developers.

Visual Design is the trickiest skillset to define because it is the most in flux in today’s responsive design environment. Whether we like it or not, visual designers are being called on to do more of their work in HTML and CSS than Photoshop. The workflow from interaction design to final product should contain the fewest steps possible, and a visual designer that can’t function in HTML creates delays.

Most MVPs can survive without a visual designer early on. Resources like 99 Designs can be used, the front end engineer can hack together something. Remember, it’s about testing the idea with a controlled audience.

That initial pretty design you think is so important for the first version — it just isn’t, because you’ll be changing it over and over again.

Some websites have gone strictly with a design that looked like wireframes and launched that way, learning and designing as they went. That initial pretty design you think is so important for the first version — it just isn’t, because you’ll be changing it over and over again. Trust me.

Should I outsource it? Maybe. With an interaction designer or product manager that’s solid, they can manage an outside visual designer to come up with some great work. If you’re really strapped, you can go the 99 Designs route, but this may take more time than if you’d done it yourself.

Who else can perform the role? In smaller teams, Interaction Designers perform the Visual Design role. Some are opting for generalists with a visual and interaction design background. Many don’t need a full-time designer until late in the game. However, if you’re a consumer product, this should be one of the first hires. The best ratio is one visual designer for every four to eight developers.

What should I look for in resumes? Most visual designers have an online portfolio. Look for the following keywords: Illustration, Photoshop, Illustrator, HTML, CSS, jQuery, Prototyping.

What’s a great interview question to ask? “Who are the designers that influence you, and why?”

Content

Writing copy is the redheaded stepchild for any product. No one really wants to write copy because it’s so time consuming, but without it, usability and engagement is severely hindered. Copy is as important as the visual look to setting the tone and brand. Establishing this early with a single resource that can perform consistently is critical.

Copy is as important as the visual look to setting the tone and brand.

If you’re lucky, you’ll find a resource that can do both marketing and content development, solving both problems at the same time. A few members of the team will probably be contributing to this process.

Also, consider this: the product you are building now most likely isn’t the product that will become your startup. Copy and design will be changed early and often.

Should I outsource it? Maybe. Using someone in-house takes away from time they should be spending on something else (you know, like selling). A common solution is to write the first draft in house, and then hire a professional copywriter later on to revise the copy.

Who else can perform the role? Interaction Designers, Visual Designers, and Product Managers should all be able to write copy. For many, this will never be a full time position unless it’s a content-heavy site.

What should I look for in resumes? Great writers should be able to tell their story in a compelling way. Look for the following keywords: Copywriting, content strategy, marketing, lead generation.

Development

Someone has to build it, right? Developers are the people who take the dreams of product managers and designers everywhere and turn them into a working product. If they’re good, they can cut time to market from months to weeks, and give you a minimum viable product that you can test user assumptions against. If they’re not so good, they’ll kill your idea.

Building smaller, agile development teams can be better than building a massive team, because each additional member increases communication overhead.

The developers that you hire should be on the same page with each other on what platform to use and how to build it. Building smaller, agile development teams can be better than building a massive team, because each additional member increases communication overhead.

The best developers know how when to roll their own (build custom code), and know when to use frameworks. If they’re rolling everything custom, that tends to be a really bad sign unless it’s an extremely complex application.

Developers tend to come in two flavors: front-end and back-end. Ideally, the developers should be full-stack: generalists that can play on the front-end or back-end, but it may vary depending on your needs. And you have to watch out for specialists. If they are an architect, they may be rusty in coding. If they’re primarily a front-end developer, they might not know back-end development at all.

Front-end developers are skilled in HTML, CSS, Javascript, and jQuery. They connect the back-end to the design. For most interaction designers and product managers, front-end developers are very important because they implement the User Experience. They are in especially high demand because the difference between a good and a great application starts with a front-end developer that pays close attention to details.

Back-end developers are skilled in languages that connect to databases, like Java, .Net, PHP, Python, and Ruby on Rails. They should also have some database knowledge, and that could be anything from MySQL to Mondo DB. Their primary goals are to make the system flexible for future development and fast for current performance. Data structure is crucial: I’ve seen many a startup killed by poor database decisions.

Should I outsource it? Possibly. With strong project management, it can work, but it’s risky. Sometimes you can hire some in-house developers, and they’ll manage the outsource team. Any outsource development team, however, has very different goals (increasing billing amounts) than you do (building your idea for the lowest cost possible). Ideally, I would have one architect or senior-level developer that has skin in the game. Additional considerations include whether you should buy or build technology, or the complexity of the application. The fewer the variables in the business model, the easier it is to outsource.

Who else can perform the role? I’ve seen product people with development backgrounds, but the roles are so different that it’s hard to combine this role. Developers should be focused on building and testing code, and nothing else. Sometimes front-end development can be handled by the visual or interaction designers, but that’s not an ideal situation.

When should I hire this as a full time position? Most make their early recruits engineers, because if you can’t build it, you can’t launch it. However, with careful project management, I have seen some outsource their development. If your product is not truly technology based, it might be better to use consultants.

What should I look for in resumes? Well executed, completed projects where they worked with a team. Ask for demos. Look for the following keywords: Ruby, Java, PHP, Python, .NET, MySQL. Also look for projects that have similar business goals as your product idea.

What’s a great interview question to ask? “Given a typical e-commerce system, what approach would you take building it? What would the software development lifecycle look like?”

Other Resources

Quality Assurance

Someone has to make sure it works, right? Any good Product Manager or Interaction Designer should be able to put together a test plan that anyone can follow, or even better, you’re doing test-driven development and the engineers are writing unit tests.

However, that’s an ideal scenario.

If everyone else is busy, there are dedicated Quality Assurance resources you can hire. The best analysts I’ve met act almost as an additional product manager or interaction designer because they become gatekeepers for great product development. They help establish process and goals in a chaotic environment, and work to ensure steps are taken to deliver a good product.

Should I outsource it? Maybe. If you’re lucky enough to find someone that’s super detail oriented, it can work. But you can end up doing this yourself and wasting money in the process.

Who else can perform the role? This can be the “all hands on deck” role. The interaction designer, product manager, or developers can write test plans and go through the steps of making sure the product works.

When should I hire this as a full time position? This can wait because other roles can test early on for most products. I would hire it as the 10th or 15th member of the team. The number of developers establishes the staffing level for the rest of the company, and is determined by what kind of business you’re in.

What should I look for in resumes? Test-driven driven software development processes, and ideally a perfectly laid out resume without typographical errors. Look for the following keywords: Agile, automated testing, test plans.

When I speak at events — I just recently returned from SoCal UX Camp — I’m always surprised what I get asked after the presentation. I put the deck online (that’s usually the first request), but much of the information I disseminate is of the spoken variety. I’m kind of like Michael Stipe, who is famous for forgetting lyrics. Every time I do the presentation, I might say something different because I don’t have a script.

The people I love helping show an effort at getting to know me. They also ask great questions that go beyond the standard, “How do I write a resume.”

At the last few events, there’s been a line of people that wanted to talk to me after the presentation. I do these events for personal branding and because I love reaching out, but I can’t help everyone. The people I love helping show an effort at getting to know me. They also ask great questions that go beyond the standard, “How do I write a resume.” They show they’ve researched. Anyone can do this.

Based on my personal experience, here’s a few things that will help you make friends with speakers and make them your advocate.

Research them and read their blogs

The first thing any interaction designer should do to prepare for a conference is research the speakers.

The schedule for most events is usually up on the website for a month or two before the event. If there are particular speakers that you want to interact with, research them. Read their twitter feeds, go through their blogs, find out who they are and what information they are disseminating to their audience, and know it so you can comment it.

You don’t have to read all of their stuff, but be familiar with what they are saying.

What frustrates me is that I have roughly 45,000 words on my blog on the topic of writing resumes and UX careers with a big fat button that reads “UX Career Guide,” and no one seems to read it. When you search for my name, I’m roughly the first five pages of results on Google. Many of the posts are for my blog. I still routinely get the “How do I make my resume better” or “Where do I find the resume template” questions.

Please, read and research! The first thing any interaction designer should do to prepare for a conference is research the speakers.

Say something nice about the side project

Know how you can make me your best friend in the world? Talk about how you love the UX Drinking Game and share it with your friends.

Almost every single designer I know that hits the road on the speaking circuit has some kind of side project. Sometimes it’s a labor of love, or it might be an end goal for their career, but showing that you care means a lot.

I have the UX Drinking Game, something that I have spent a considerable amount of time and money building into what it is today. I’m neurotic about everything I do (at least everyone said I did a good job this weekend) because of that INTP thing (I’m very introverted, and I need data for most decisions). Positive feedback means a lot.

Know how you can make me your best friend in the world? Talk about how you love the UX Drinking Game and share it with your friends.

Buy their stuff

Do they have a book for $19.99? Are they doing a low-cost class? Do they have an application or two in the iPhone App Store for $2.99?

Do them a favor — buy it.

We try to price these items at a price point almost anyone can reach, and many of us see sales or site engagement as how we are providing value to the community at large.

We may love User Experience, but it also pays our bills. We try to price these items at a price point almost anyone can reach, and many of us see sales or site engagement as how we are providing value to the community at large.

Some speakers actually pimp out the work of other designers. I spoke highly about Russ Unger’s A Project Guide for UX Design Saturday, and I’m starting to use Laura Klein’s book UX for Lean Startups for startup types. I have a library of books by other designers that I routinely speak about and share at events. Many speakers hit the circuit specifically to sell books, and after a while the flights and hotels get to be draining.

I’m not saying you have to go to every $1,400 event that comes along, but spending $19.95 for an eBook doesn’t seem to be much of an ask.

Offer to buy them a drink

The best conversations I have had at events have been outside of actual sessions.

It could be a coffee or a whiskey, but a small token of appreciation is awesome. The best conversations I have had at events have been outside of actual sessions.

At the SoCal UX Camp, a designer with a sociology background, Sara De La Cruz, offered me a cup of coffee. We had a wonderful conversation at a nearby coffee shop about how our careers were similar, and we talked through great ideas about how she could make a career shift to UX design. I offered several suggestions, and further questions showed that she was really taking steps to break into the field.

It wasn’t a long conversation (I think about 30 minutes), but with that small sign of gratitude she gained a friend for life. And the drink didn’t even have any whiskey in it.

Bring business cards

Your cards should list your name, what you do, and a contact method, like your Twitter address or website.

In our virtual world, I know it sounds kind of odd, but a small card is a great way to introduce yourself. There’s almost no friction, it’s an easy way to make an introduction. They don’t have to have your business on them. I paid something like $40 for mine, and I think they look great.

Your cards should list your name, what you do, and a contact method, like your Twitter address or website. It also works with recruiters — if you meet one at an event, you can give them a business card and they’ll usually reach out to you the next week.

Another thing — I remember faces, but I have a really, really hard time with names. If you meet me, ask me about the time I forgot a C-Level manager’s name, six months after working at the company.

Have your shit together

If you’re an interaction designer that has done a bunch of work, or want to be one and have relevant experience, I want to talk to you! We can discuss your difficulties in finding a job, and you become an ideal candidate for user research.

If you have just graduated college and have three college projects in your portfolio, or you’re a used car salesman that’s never touched Dreamweaver or Omnigraffle before, I can’t help you.

There are a ton of resources on the web that talk about how to prototype, start side projects, and learn about the field. If the first question you ask is, “How do I break into User Experience” I know you didn’t do your research, because the first few results on Google include an article that I wrote on the subject.

User Experience is not a passing hobby, it’s something you have to live and breathe. That’s an investment. Respect ours.

It’s because 60 to 70 percent of what Interaction Designers do has a direct correlation in skill set to the Product Management job description. Outside of pricing models and a few other business methodologies, good Interaction designers can easily act as Product Managers in many environments.

Great product management and product design is the crossroads of minimizing risk and maximizing value.

With the advent of the user experience process, it can be argued that many Interaction Designers are better trained in Product Management than the Product Managers they work with. Product Managers are trained in business theory and have to learn how to build and project manage a product; Interaction Designers are trained in the process of building a product and connecting it to engagement and business value.

We can turn conversations from the worthless “make the button blue” threads to “what you are trying to accomplish” within context of great product development.

It has many commonalities with great user experience — we push the boundaries of great design and technology while mitigating user adoption risk. That’s why learning how to act as almost a “second Product Manager” can be impactful: your influence can go much further than just the interactions because of how much you should know about the product development process.

It’s about showing everyone that great product design isn’t about control or dictating direction, it’s about impact and process related results. It’s about a team that where everyone can be a product owner and be part of the process. It’s about changing the dialog from management to team oriented results.

We can turn conversations from the worthless “make the button blue” threads to “what you are trying to accomplish” within context of great product development. Defining that context is the best result any Interaction Designer can deliver for their organization.

Understand the business model

Repeat after me: no service is ever free, you just aren’t paying for it.

Designers design for goals, and what you are solving should meet the goals of the company.

When designing any product, the most likely goal is to make money. Some designers think user experience is some altruistic pursuit that’s funded by a magical non-profit money machine. Unless you work for a non-profit where you are trying to save the world, that’s wrong.

If you’re working for a startup with investors or a larger business that’s bringing in revenue, everything you do should lead to the almighty dollar, whether it be user acquisition, engagement, or the most direct way, a direct conversion. Designers design for goals, and what you are solving should meet the goals of the company.

Know the user journey inside and out, and figure out what you can do to get that user to convert to something tangible. Establish user goals that are directly related, and work with the product manager to make sure those goals are reflected in the product roadmap.

Understand prioritization

The last thing that an Interaction Designer should ever think is that they are the most important person in the organization.

Remember that every minute you spend on a feature it’s costing the company money.

Companies are very complex places where User Experience is but one part of the larger machine. Your wish list is prioritized with the wishes of sales (more features!), marketing (features they can talk about!), and engineering (features that don’t cause the system to crash!).

Pick your battles and ask yourself the following questions when pushing any feature:

Is shipping more important?

Do you really need it to be pixel perfect?

Does every form element need inline help?

Can you get by the minimum viable user experience?

If you take an iterative approach to design, you can learn more with smaller steps than with giant leaps. Remember that every minute you spend on a feature it’s costing the company money. If you ask developers to build it, it costs that multiplied by the number of developers on it. If it’s a feature that is half baked, you’ve wasted precious time and money.

In other words, pick your battles wisely.

Understand the organization

Interaction Designers should never end their thought process at how the user uses the application.

The best opportunities are usually outside of your job description.

What User Experience designers should be doing is talking to almost everyone in the company and figure out how the complete service works, from customer service to accounting to engineering. The best opportunities are usually outside of your job description.

The best example is customer service: representatives on the front lines are some of your best allies. Ask them questions over lunch or a couple of drinks, and learn their jobs. Sooner or later, you can propose solutions that make their lives easier.

Many times, those solutions are what I call “two-fers:” you can solve two pain points at the same time.

At one job examined at the customer service process and figured out low-cost ways to improve the process by including more help text before customers asked questions. Emails dropped 25 percent over a month, and revenue went up. It the end, we had happier customers and cut overtime to zero by providing better solutions.

Understand conflict

The best thing about the three legged stool of Product Management, User Experience and Engineering is the healthy conflict it generates.

Conflict generates passion, viewpoints, and eventually results in better solutions if handled right.

Conflict generates passion, viewpoints, and eventually results in better solutions if handled right. You can turn that conflict into an advantage and control the conversation. Here’s how:

Have a beer with the engineers to understand their pain points. Ask them questions about implementation, and think about solutions. Have a beer with the Product Managers and ask what they are trying to get accomplished. Ask them questions, and learn their pain points.

Then you can be white knight that rides in and saves the day because you can propose the solution that meets both the goals of product (profitability and engagement) and engineering (stability and less complexity). You can facilitate and negotiate. This process builds trust not only in the UX process, but the product management process as a whole.

Understand context

Product development can be the Tower of Babel, but great designers can be the Babelfish of any organization.

We should be speaking in the languages of the people we are working with.

Every once in a while, I slip into UX Speak, which is code for using jargon thrown around at clients for processes and terms that we purposely make hard to understand. Ethnographic research? That’s studying users in their environment. User Journey? That’s that pesky user lifecycle thing. Wireframes? Personas? Use Cases? It goes on and on.

We should be speaking in the languages of the people we are working with. Engineers want to hear engineering terms. Product Managers want business terms. Everyone wants a common language to speak about the common goal.

We should define that common language for them.

Set the common thread of communication by describing the business in language everyone can understand, and evangelize that in every corner of the organization. Gently correct users during the product definition process, and you’ll be amazed how quickly context will be understood.

Great product leaders create one path that everyone can follow, and that’s as simple as defining where the path starts.

Understand ownership

Ownership means that you care.

The biggest difference between being an Interaction Designer and a Product Manager is exactly this: Product Managers are product owners — they are where the buck stops, and are ultimately held accountable for every decision.

They are also responsible for being a leader, and getting buy in from the organization. If they can’t build support with soft skills, no amount of mandates from the CEO will save the product. Everyone from the programmers down to the customer support will ignore the product manager (I’ve seen it, and it’s ugly).

If you show ownership in your work, you’ll fight for what you think is right, and will put your job on the line if you think a way of think. It means taking chances, not playing it safe. It means making decisions that you own, right or wrong. It means taking responsibility for all calls, good and bad.

The Money Shot

Great Designers and Product Managers get people excited about creating great products without the need of a title, and should be able to explain holistically how the decisions made contribute to the long term success of the product.

That may mean making decisions that may seem counter intuitive in the short run, but if they can describe their vision, that all important buy in can be an important asset in product success. Evangelism in any field is a great skill to have, and if you can cover more than just the UX role, that makes any team an unstoppable force.