I was having a hallway conversation at UI11 with Joshua Porter. Lots of fascinating discussion (during which my voice finally played itself down to a rasp). But one of the things that I took away was a renewed interest in reading outside my field for inspiration for my field. You know learning from other crafts to inspire my craft. (In a separate article I will publish my reading list.)
I had started thinking along this line earlier in the year. In fact, Brian Kromrey (Yahoo!) and I were tentatively planning to convene a panel of Yahoo! interaction designers carefully chosen to represent very different design backgrounds. Backgrounds in design from gaming, industrial, motion graphics, theatre, software, comics, and so on. We had tentatively called it, "A Different Box of Tools." Since most of us did not start out as interaction designers/information architects/web designers our craft is certainly enriched by this varied tapestry.
How has your former design training influenced:
- The way you solve problems?
- The way you document solutions?
- The way you communicate design?
Solving Design Problems
My strong background in software architecture led to a passion for clear vocabulary and a deep appreciation in the powerful nature of patterns. The famous Design Patterns book for software was formative in the way I thought about solving problems. No surprise that patterns make up a lot of the way I approach design today.
My exposure to the agile community (eXtreme Programming in particular) reinforced the principles of simplicity, iterative problem solving, and pairwise-thinking. Not surprising that I value doing the simple thing first, communicating via the design in the simplest manner to start with and adding the effects as needed to tune the interface. Iterative problem solving is key to good interaction design. Having the user and other stakeholders early in the loop and rapidly iterating to a solution is critical. Pairwise programming (although I confess the religious adherants of this practice almost made me loathe this approach) can be seen as a reason that I latched onto Alan Coopers "designing in pairs" approach so easily.
Documenting Solutions & Communicating Design
Agile software approaches taught me the lesson to only document what others will read :-) Another way of stating this is who are the users of your documentation? That will determine what and how you document. This has influenced me in trying to keep documentation simple or create tools that make it feel more lightweight. My engineering background also taught me what developers need in documentation, so my background has helped me create solutions that can bridge the gap between design and development.
That's enough for me. Now it's your turn!
Share Your Lessons
So why not share? How about stepping up and telling me how your passion for art or your training as a clown or your training as an architect has crafted your craft. We could all learn an amazing amount from each other.