I’ve spent the majority of my career working at small companies. I like to work on a lots of different tasks and pour my skills into the gaps as needed. When it comes to User Experience (UX), this  means I often wear many hats: Visual Designer, Information Architect, Interaction Designer, Content Specialist. It also means I’ve learned a thing or two about small-team UX.

If you’re in a start-up or a small technical team within a larger company, you may not have the space on your team for a dedicated user experience person. When I attended UX Week last year, my eyes were opened at just how big UX teams could be in large organizations, and also how specialized the individual roles could be on these large teams. (See this post for an idea of the kind what UX roles are out there.)

I believe that even if you don’t have a stacked UX team to lean on, you can still have successful user experience practice. You just need to think about the 3 T’s of small-team UX: Talent, Teamwork and Time.

Talent

If you’re looking to hire a lone user experience professional for your small team, it’s important to realize UX roles are quite diverse and you will not likely find an individual who is able to perform them all equally well.

For example, my skills are strongest in visual design, front-end coding, content and information architecture (and I like doing them more, too). I’m a perfectly competent interaction designer, but this doesn’t get me as excited, so it’s a little more effort for me to work through all the different possible pathways through a system. (And I tend to get bored with it after a while.) If I’m honest, I’m really not a researcher at heart.

In a small organization, it’s important to know your UX person’s strengths and weaknesses, so you can make sure they fit well with the other skills on the team. And, since many small teams don’t have the budget for a dedicated user experience person, you will likely end up stealing a little time from other team members to contribute to the product’s user experience practice.

Creating a great user experience with a small team doesn’t come from just one UX pro. (I suspect this is also true on large teams too.) So, if you can’t afford a dedicated UX person, you can probably still build a UX practice by pulling from the talent of people you already have around you:

• Support and sales team members can give you great insight into user’s needs and preferences. While it may not take you as far as a dedicated user testing, it can take you a long way in making good choices for your customers.
• For visual design, look for the people who get twitchy when a pixel is out of alignment or “something doesn’t quite fit.” If you’re lucky, one of them may be a technical writer, programmer or front-end web developer who can tweak graphics or critique the final product for design details.
• Software testers, business analysts and technical writers can be great resources for interaction design input. They often notice when something is off in the workflow that will be hard for the end user. Encourage them to be involved in the development of the product from the beginning and you’ll nip awkward processes in the bud before they get too baked in.

Teamwork

A small-team UX practice absolutely cannot function without teamwork. It’s tempting to hire a UX professional and expect them to give you all the answers laid out and ready to code. But that’s not how good design comes about, and that’s not why user experience roles grew important in the first place.

User interface design on my small team usually goes something like this:

1. Someone comes up with a new feature/product idea.
2. We have a group discussion with business analysts, support techs, developer and myself about what we think the users need and where it might fit in the process. This usually involves lots of hand waving, passionate opinions and informal sketches of wireframes and workflows on the whiteboard.
3. I take away the results of the discussion and do a preliminary mock-up of screens for the steps in the process. Remember, my strength is in visual design and high-fidelity mock-ups in Illustrator seem to work well on our team. You may find wireframes, workflow diagrams or other tools work better for you. We, on the other hand, have usually have jumped through those that in our whiteboard sketching.
4. Once the mock-up in complete, we have a second, usually smaller and shorter, discussion to iron out any obvious kinks or dislikes. This often occurs at my desk, on a big monitor, with Illustrator open. (Rinse and repeat this discussion as the mock-ups evolve.) It often ends with people trying to click on the mock-ups with their mouse to see how they will behave. At this point, I know it’s time to turn them over to the developer.
5. The developer implements the design. This always leads to tweaks. Sometimes it’s an icon we’ve forgotten, for a font or whitespace that needs adding. Sometimes we realize there’s a great way to reuse the existing design of something in the product. Usually, I get the chance to peer over the developer’s shoulder and give a thumbs-up or a few suggestions before it gets checked into source control.
6. As soon as the code is checked in, everyone in the office can grab a build and “play.” Often, this leads to more adjustments and ideas, or even things we’ve missed.
7. For major new features, we usually try to get a preview in the hands of a few friendly customers before general release. For us, this takes the place of formal usability testing (although we would like to eventually like do more). Our customers are scattered across the country, so it is difficult to get them in the room so we can observe. So, for the moment, we let them try it and give us their impressions. We’re also lucky to have a really engaged community of end-users, so scarcity of feedback is not usually the problem.

Time

Good design needs a bit of bake-in time. At each step, it’s good to leave some time to play with the ideas or prototypes.

Around here, I’m fortunate that developers and analysts are in the habit of giving me head’s up a little while before we have that first discussion. And, they realize I need a few days to go from that discussion to prototype… I walk to and from work. My brain does much of the heavy lifting during this “down time.” So, I appreciate when they can give it to me.

Time is also critical when the rest of the team looks at the design. Or when we give our customers a preview version. Time is the chance to try the feature out again and again. Or, to come back to it with fresh eyes after a few days away.

In those cases there you have no time and you push the design out the door, accept and expect you will revisit the it in the next release or after it’s been out in the field for a while.

It’s worth remembering that getting negative customer feedback about something you tried isn’t the end of the world, your product or your business. In fact, addressing those concerns in a timely manner builds a kind of customer engagement and good will that will keep them loyal. Remember to thank customers for the help when they express the concerns, both privately and publicly in any release notes. You don’t have to name the individual, just emphasize that the ideas that came from customer feedback.

Finally, recognize that this team approach to UX will take some time from other tasks from team members who participate. Factor this into your schedule and expectations. Be realistic, but see it as an investment in the product and your business because it’s well worth it.

This post was inspired by the great team I work with to create TaxCycle, by my husband who supports me choosing inspiring work above all,  and by the other battle-weary, small-team junkies I know who push to design great software.