Boxes And Arrows : The Design Behind the Design

This topic is certainly near and dear to my heart! I'm a one person shop in the newly created position of user interface engineer (whatever that's worth :) and would like to here about others experiences in integrating this process into an existing development model.

I've been recently given this task by our company, any help and advice would go a long way to help me achieve my goal of making the business stand up and pay attention. I'd love to hear from others about how to do this what methodologies and process they use and any word of wisdom they can share.

This is such an important topic. Thanks for suggesting it! Judging by my own experience, I would warn against accepting a challenge to shoe-horn a few techniques into an large-scale, existing project. Try to choose a smaller project that will allow you to apply at least some of the basics at every key stage so you're showing not just a process but a way of life. I can't wait to hear what everyone else shares about their experiences...

Thanks for your comment Kate-- I wholeheartedly agree. One of the worst things you could possibly do (IMHO) is to take on a huge, highly visible, project as a way of introducing a company to usability/UX methodologies! It's not likely that you'll be given free reign to overhaul the entire process on your first project-- especially if it's a critical one and you'll end up trying to squeeze in a few techniques here and there (as you mention). Starting with a smaller scale project where you can track the results from start to finish is an excellent way to ease people into new processes. There are so many different elements that have to be cared for-- not getting in the way of business getting done (that's what we're here for afterall), not stepping on toes, teaching, nurturing, explaining, evangelizing, advertising... it can take a long time to shift culture and processes and it certainly doesn't happen overnight. But what's cool is that people REALLY get it when you can show them how a smaller project, in their very own company, was a huge success because of this new approach to product development. One incredibly important thing I'll add is that it's crucial to really document that first small project because you need to be able to paint the "before and after" picture with real, tangible, points and data to back it all up.

This could be a very influential story to many people out there who are fortunate enough to come across this Web site. I have had a few experiences where I am the only UX advocate and can agree that expectations are very high and people need to understand the results don't always appear immediately. I learned how and when to fight certain battles in some very tech-centric environments and successfully implement a UCD process.. Good luck Amy, I hope this becomes a story as well as a valuable lesson that others can learn from.

I am also pioneering a usability program at my company and I would LOVE to hear your ideas!

I've worked as a solo interaction designer for the past 8 years. I started in at a non-profit who hired me for my HCI background, but at that job, I ended up in a developer role. The company liked the idea of claiming they used a user-centered design process, but didn't like the idea of making time for it. I learned to bootstrap and fit various methodologies into the process as time allowed. It wasn't ideal, but I learned a lot about how to sell UCD. I spent a lot of my "outside work" time doing user research and got very good at quick informal usability testing. At the time, I had no idea this was going to be the best training possible for me. Because since then, I've worked at startups, where user experience is crucial but resources are limited. I've found the following things to be crucial to success: 1) Don't try to do everything all at once. I've seen a ton of young UED folks join a company who wasn't familar with any design process and get completely eaten alive because they didn't ease into it. People don't want to be told that what they've known their whole careers is wrong. Nor do they want to be told your "better way" is the right way. People need to be shown that something works not told that something works. I've found the most effective way to introduce design methodologies to a new company is to not ask permission but to just do things. Think something should be tested? Ask some friends or co-workers who aren't familar with the project to be your test subjects. They may not be "real" users but they will help to demonstrate the value of usability testing to the non-believers. 2) Understand the key business metrics and use them to support your case. I've found this to be invaluable. We've all been in meetings where people discuss which color is better or whether that critical thing should be here or there. I've found the most effective way out of these arguments is to suggest, let's do both and measure which one performs better. This is another great way to bring evaluation methodologies to the forefront. 3) The role of user research. This is the toughest one to bootstrap. This may be the most controversial one, but I've found that user research is not always necessary. The easiest way to turn a company off of doing user research is to spend a bunch of time and money learning something that people felt they already knew. They key here is to identify what the different stakeholders think about their users. Are they all on the same page? Are they designing for themselves? What is the bare minimum required to get them on the same page and to start to understand real users. This is the hardest, in my opinion, to integrate from an organizational standpoint. Even if you can only do a little bit of it, be sure to highlight what you've learned and the impact that knowledge has on the success of the product. It will make it easier to win time for more research in the future. Eventually, if you are patient, the smarter stakeholders will start asking for the research upfront.

Excellent idea! I seem to find myself if this situation over and over again, that is, trying to implement a process that many people are initially resistant to. Before I was a UI/IX Designer, that is, before the concept of user interface design even existed in its current iteration, at least outside of Xerox and Apple, I started up a design group for a new division at Microsoft. We initially did documentation design, and later, once it became clear that the UI needed design help, we evolved and hired industrial designers to take over the UI work. Back in those days, when printed documents shipped with software, Microsoft had a number of products whose documents looked like they came from different companies, when in fact they came from different product groups. I proposed a standard design that would be used across all product lines. The initial response from writers, editors, managers, and even some of the other designers was that we would be taking away their creativity by doing this. I sold this concept to a hall full of somewhat hostile people by explained that we were doing this for the end-user and that we would be designing living documents that would adapt to the product requirements, but still be transparent to the user so it would still be perceived as a MS document with the same cues and the same look and feel. Of course, that was just the beginning of a project that took 18 months of gathering information, showing design options, preparing guides for usage and specifications. That design has evolved over the years, but it is still being used by Microsoft Press for its technical books. Since then, I've been in similar situations, like the one I'm in now (not Microsoft), where I'm trying to change hearts and minds. I think, in general, the hardest thing that all people have to get past/through in their lives is change. So, as designers it seems that we are always trying to get people to see that change is a good thing, even if it's painful in the beginning. Making it less painful, especially, as Teresa said, where resources are limited, is also part of the process. I'm hoping we'll see some good stories here.