We, the makers

Recently I’ve heard a lot of frustration from UX people (Interaction Designers and Information Architects too) who feel their expertise is not recognized or appreciated. They feel they don’t have a seat at the table. They complain that product managers talk to customers and determine what features are built while designers have to beg for access to customers. Developers write the code and determine how the product looks and behaves. Design is seen as something “nice to have,” or at worst a bottleneck. Designers trade tips on how to do guerrilla user research, or operate as a UX team of one.

While talking about this subject recently, my friend Josh Seiden observed “the outcome of development work is code. The outcome of design work is sketches.” He’s right, and this is central to the difficulty we face. We’re known (and celebrated) for our ability to emphasize with users, generate ideas, and rapidly generate many concepts via sketches. Unfortunately, this strength is also our weakness. For many of us, the end point of our process is an idea expressed as a report or drawings which are handed off to other people for implementation. When design is dis-engaged from construction, we create silos and hand-offs and don’t gain the full benefit of either discipline. We need to work together more closely to make things real.

As designers, we can be better team members and more active participants in our projects when we educate ourselves in the material of construction. For a digital product, that means learning about code. Educate yourself about the technology you’re designing for. If you’re making iPhone/iPad apps, look into iOS programming. If you’re working Web products, learn about CSS, HTML and Javascript. If you’re working on an enterprise product, you’ll probably want to know something about .net. I’m not suggesting you learn to be a fully-fledged developer, just learn the basics about how a UI is produced. What are the UI guidelines for this environment? What’s the UI framework? What is easy? What is hard? Identify a few different examples of products built in this environment so you can build up your knowledge of UI design patterns.

If you get a chance to do it, it’s a great learning experience to work closely with a developer on an actual project. As Bo Campbell says in his blog “I encourage any UXers to get closer to the engineers, especially if you feel isolated in a product group. Push your way in. It seems crazy, but you really need to show everyone that your obstinance is merely a passion for the quality of the product and that you want the interface to represent the quality of the work behind it.”

If you design Web products, you can learn enough to create simple websites. There are LOTS of great resources like this one. I’ve taught myself a lot just by going through the process of hosting and configuring WordPress sites. There is a huge community of friendly WordPress people out there, ready to share what they know.

So, don’t just design something, make something. As you learn more about how software is made, and grow more comfortable working with code, you’ll find it easier to collaborate and communicate with developers. Once you understand how software is built, you’ll develop a better sense of what activities will be of most benefit and what deliverables are actually useful for moving the project forward.

For an inspiring example of how a team of generalists work together to cover design and development activities,  check out this blog post from from Brittany Hunter at Atomic Object.