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.
7 comments:
Hi Bill. I like to think of myself as one who designs and engineers interactive experiences, with a deep background in software and the web. As a strong advocate of studying outside one's specialty for inspiration, I recently moved away from the web to challenge myself through exposure to new problems presented by different user experiences.
My current UI work is with industrial designers and human factors engineers for touch screen and hand-carried medical devices. It didn't take very long working together for us to realize how the product could benefit from combining their experience with product design, ergonomics, and usability research (and all related considerations unique to the medical field) with my visual and interaction design experience on the web. My background with dhtml and ajax (thank you, YUI library) is useful for creating interactive UI prototypes. Global participation in usability testing is done easily when the UI prototype is as close as your web browser. We're able to gather feedback quickly to fine-tune our solutions while still making progress on the build. This project requires me to wear many hats: interaction designer/information architect, creative director, web developer, usability specialist... I even work with folks from marketing on branding's role in creative strategy.
This departure has had a profound impact on how I approach problem solving and visual communication and is even more enriching that I expected it would be. A bonus is how rewarding it is to create something that could possibly save a person's life. I see through different eyes when my decisions impact the quality of care a patient receives rather than the quality of a person's online shopping or event planning experience.
Although I haven't given specific details in response to your 3 questions, I wanted to chime in on the value of expanding your horizons to help breath new life into your craft. I'm curious about how I'll see this inspiration realized down the road when I find myself back in the web world, building something old in a new way.
Hi Bill, I was there for the UIE conference and attended your session. I am working as Information Architect since last three years. I am Industrial Designer by profession. I second your thoughts about the influence of our education on our work. I guess it is very natural and there is nothing bad about it. Infact having people from different backgrounds bring variety of ideas on the table.
I used to do a lot of user research before starting my product conceptualization and this clearly is reflected in the way I do my job today. I emphasize of user research before sitting and starting design. I also tend to bring the user's terminology in my work.
As a musician and commercial arranger, I think of design as a well balanced composition:
1) I start with a lead sheet—the melody and the chord progression
2) I look at how other people have arranged the composition—what worked, what didn't work
3) I think about what countermelodies and harmonies will support the melody, and what will distract
4) I think about the musicians—what are their strengths and weaknesses, and how will the arrangement spotlight each individuals talents
5) I build the song—I introduce it and layer in the supporting pieces
6) I end the song with appropriate closure
7) I spend as much time as I can writing the individual players parts out with clarity to ensure that even when I am not their, the piece can be played consistently.
8) I get it played, listen to it obsessively, and revise as needed until it sounds perfect (* This step actually occurs continuously from start to finish)
or:
1) I start with the requirements
2) Next is the discovery and competitive research
3) What are the primary, secondary, etc. goals and tasks
4) What are the users' strengths and weaknesses. How will the design support both a range of beginner to power users
5) I create a cohesive mental model
6) I make sure the user knows where they are, and when their tasks are accomplished
7) I document the hell out of the design so it gets built with a minimum of confusion and fuss
8) I get it tested, analyze the results obsessively, and revise until it works perfectly (* This step actually occurs continuously from start to finish)
Fun exercise. :)
Hi Bill,
What a great post and awesome call for participation of your blog readers.
my background
I have no formal training whatsoever. I am born and bred from the garage work I did when I quit grad school in anthropology to become an HTML-coder which made me a web designer, back in the day (1994).
I think this has allowed me to bring to the table whatever I figured out along the way. The anthro side always had me understanding that we make things for people to use, and that the processes we use for making things are as culturally derived as the contexts of whom we are making things for.
I have always felt the go-between engineering and design and neither a participant of either group, that is until about 5-6 years ago when I finally got that glimpse that design was not purely about aesthetics. Then through my work with IxDA I really took on the designer as an identity. I'm almost in that Nussbaum zealot camp believing that "Design" is the Holy Grail we've been waiting for.
What really threw me over the edge into the designer camp about 2 years ago was my brief formal education with Industrial Design and since then my ways of designing and communicating design have changed radically and I think I'll answer your questions with a before and after response.
The way I solve problems
Before
JAD - Joint Application Design
I would get all the stakeholders in a room and solve problems by committee. There were leaders, and often I was one of them, but the problem solving happened with a large groupo of people using structured conversation patterns.
Oh, out of these meetings, wireframes and screen designs were done in single iteration b/c the JAD sessions themselves "solved" so much of the framework and the essense of the final solution that there wasn't a lot of need or room for creativity. Ergo, nothing really inventive ever really got done.
After
Brainstorming > Design leadership > design presentation > JAD refinement > design refinement
The brainstorming was done by a smaller x-functional group, who helped to understand the constraints and the context of the problem we were trying to solve--problem definition and shared understanding of that definition. Yes, outside sources like user and market research were brought into the game, but so was rapid prototyping of ideas through sketching.
What I mean by design leadership at this point is that after a problem was defined and understood the designer(s) would go off on their own and sketch and sketch and sketch. They would evaluate ideas shrinking, combining, separating, folding options until they felt they had a few options that tell a similar story that solves the problem.
These options were then presented back to the original team for reflection, evaluation, criticism and refinement.
Finally, the designers would go back and refine the solutions parts, creating a language for the narrative, making sure the pieces can interconnect and that new pieces can be added easily as we all know that scope will creap.
document solutions
I find it interesting that you put "document" before "communicate". But since that's the order you put it in that will be the order I'll answer it.
I have a hate/hate relationship with documentation. This is the same now as it was before. I do believe that people READ documentation, but not the people I'm interested in and usually documentation is for people who don't GET the design. They can't internalize it and thus can't make decisions around the design concept. I have usually found that documentation is incomplete and that where the holes in the documentation reside are the places where the designer has internalized their designs so much that it is like saying define "the" for someone. I can explain how to use it, but does it really have a definition? And in terms of defining how to use it, don't we have better things to do than defining how to use "the"?
What I have tended to do is concentrate on
communicating solutions.
Before
Annotated wireframes.
After
Detailed screen shots that I would present (not deliver) followed by an interactive prototype, which would also be presented.
I present so as to tell a story.
I use details because the details are what completes a story. I have learned that people get distracted by their attempt to fill in the details. As I have tried to present wireframes to different stakeholders over time, it has occurred to me that detailed models offer a better conversation during a presentation and I am left answering less questions about areas of the design that are least important.
Bill, a great topic. I think the other aspect to this that will effect people's answers is the environment they work in and what is their relationship to that environment:
Internal Team
Consultancy/agency
Full-time permanent
Contractor
Then the type of solutions they work with will also determine some of this as well.
Product, service, marketingware
information or transaction or interaction
Obviously, this isn't exhaustive, but I'm betting that a complex matrix here would deliver interesting insights into how people communicate design.
In my past life I was a graphic designer -- I've designed corporate identity systems, packaging, and what we used to call "multi-media" presentations. I use all of this in my current role as a hands on design manager.
When I used to design a book, I'd have to think of all the common elements, what things needed to be consistent throughout the experience, like pagination, page heads etc. What elements might create a mood, and leave an emotional impact like color and typography. And, I always thought about who whould be reading this and how they might behave, which might influence all the design elements.
Its as if I was designing a system - starting with a page grid I added and subtracted pieces to build a system. Add in motion and time, and I started thing about "states."
Honestly, I think I still design the same way -- I'm just designing for a different medium.
Kevin Cheng, Yahoo! Designer (and half of the great ok-cancel.com team) left these thoughts:
Technical side informs me (and hinders me) in knowing what is possible (but sometimes misconceiving what is possible). It lets me talk to engineers and understand why something is difficult and come up with creative alternatives instead of just “oh, it can’t be done because it’s hard”.
Comics gives me an innate sense of storytelling and in the end, everything in design reviews and presenting design (or presenting demos, product, myself) is about telling a story in a concise manner. Even when I’m not doing something in comic form, I’ve found that I have a sense of how to present something in a digestible manner that seems more ingrained to me than most.
kevin cheng
interaction designer
yahoo! maps/local
Thanks for that Bill -inspiring,informative and enthusiastic.
My background was that of an Analytical Chemist and I too fell into web design by accident, but the analytical approach gave me the method,practical and conclusion.
Post a Comment