WOW! I'm really sorry I let so much time go by. My apologies to the folks that were actually reading once in a while!
To catch you up, I was on a GREAT project in the fall, working for Liz Bacon at Devise to design a browser-based revenue management system for hospitals. It was so cool to learn from her and work with talents like Neil Doxtader and Stacy Westbrook, as well as our cool customer.
Unfortunately, last year's dry spell was more than the project could make up for, so I had to make the difficult decision to go back into FTE-land (sleep for now, dol). However, I landed a great gig with Microsoft (very unexpected for me) with a solid group of designers. I'm in an org called Speech@Microsoft (formerly Tellme), part of the Office team, and am helping partners understand the value of great UX/UI Design, how to do it, and how to measure it. It's a brand new role for MSFT and for me. So far, things are going well. And I really like working for Bill's little company. It's an exciting time to be there. A time when design matters more and more everyday to success. Ask me what it's like. I'd love to share. There's much more!
Personal life has been crazy, but I won't get into that here. I'm just hoping to come at you with more design thoughts and teaching moments, starting now. Don't let me stay away so long next time. (Maybe there won't be a next time!)
Showing posts with label voice interaction design. Show all posts
Showing posts with label voice interaction design. Show all posts
Tuesday, June 1, 2010
Wednesday, September 16, 2009
More isn’t better, but (help me with) Something Else is
Sometimes it occurs to me that we designers have tools in our toolbox that we use trustingly but haven’t explained why to others. Such a tool is usually rightfully worthy of our use and trust, but should be accompanied by sound theories and reasons. To that end, I thought I’d spend a little time on the origins of the VUI design component “help me with something else” and its variants.
Ideas around it first began back in 2000 or so on a project at Intervoice for a British Columbian transit company. We were designing a menu of options and were dissatisfied with the in vogue wording used to point to choices that were on a secondary menu. I.e.:
“You can say ‘plan a trip’, ‘get a schedule’, ‘paratransit’, or ‘more options’.”
That sort of phrasing seemed to be clunky and out of character for the design feel we wanted to deliver and we just felt it was inadequate for callers to latch onto.
In an informal discussion, one of my team members said “we need something else”, referring to the current choices being used in the design world, such as “more choices”, “other”, “none of those”, etc. When he said that, we looked at each other and said, “why not try ‘something else’ in the prompt?” So we began thinking about this:
“You can say ‘plan a trip’, ‘get a schedule’, ‘paratransit’, or ‘something else’.”
We liked where that was going, but quickly thought of a semantic problem in that the instruction seemed not to refer so much to additional choices but rather to telling the caller that they could say just about anything else. That, of course, was not the case and would cause interaction issues. Plus, the phrase seemed overly ambiguous, maybe even more so than “more options”. So after a bit of round-and-round about it, we determined that we wanted to try the phrase “help me with something else” (HMWSE).
“You can say ‘plan a trip, ‘get a schedule’, ‘paratransit’, or ‘help me with something else’.”
Though it might seem pedestrian now, this was a pretty novel idea at that time. The “more options” construction came directly from DTMF IVR menu structures, meaning it was deeply ingrained as the default presentation. Furthermore, in the early days of voice interaction design, there was an emphasis on pithy phrasing and HMWSE seemed like a mouthful. However, it had several strong characteristics that appealed to us. It was clear, used more common wording, and we actually heard similar phrasing in everyday conversations around us.
Fate, though, had other plans then. For a couple of reasons, we weren’t able to use the idea in that current design. But I held on to it for several years and finally had the opportunity to try it out again in 2004 at Voice Partners. We were working a significant redesign for a mobile carrier’s customer service line. As you can imagine, there were many functions for callers to choose from in the application. As soon as I saw the struggle with how to represent the concept of other things the callers could choose, I suggested that we try out HMWSE. I walked through its origins and we had some good discussion about why we though it would work. So we tried it in usability testing in opposition to the traditional “more options” and it was then that the strongest reason for the superiority of HMWSE emerged.
As we watched and listened to participants move through and struggle with the menus, two patterns of behavior became clear around their decisions to access more choices. Many of those who used “more options” seemed to be exhibiting surfing behavior triggered by that phrase. That is, they wanted to hear and think about all possible choices before committing to one because “more options” seemed to mean “more options that you might want to hear before you make a decision”. This frequently led, though, to failures in the menus as callers encountered cognitive load problems having to hold all the choices and their possible meanings in mind. Callers who heard and used HMWSE, however, did not encounter nearly the same number of problems. They were not surfing but rather, and this is the key point, they were listening to and then rejecting previously heard choices when they said HMWSE.
“Help me with something else” allowed them to hear, absorb, then discard choices they did not consider valid and specify to the system that new choices should be presented.
This was a major eye-opener for me, and my co-designers. While we had suspected that HMWSE was better, we had discovered a solid cognitive reason for it. Callers clearly preferred not to surf, but to have a way to eliminate choices rather than play a guessing game. Thus, HMWSE became a new best practice for use when menus exceeded a certain length.
Failing menu: “You can say ‘my bill’, ‘my plan’, ‘technical support’, or ‘more options’.”
Winning menu: “You can say ‘my bill’, ‘my plan’, or ‘technical support’. You can also say ‘help me with something else’.”
Now, to be clear, all the other principles of good menu design still apply. Choices must be clear, unique, and aurally distinct, among others. HMWSE is not a ticket to allow “anything goes” menu construction. But, when used with a solid set of menu items that need to span more than one presentation instance, it is the best choice for letting callers know that if they do not hear what they want in the initial list, they have a clear way of indicating that they want to discard the first list and hear another.
“More Options” for HMWSE
In the several years since that discovery, the use of HMWSE has grown in two ways.
First, I’ve encountered situations where a variation of HMWSE works better than the original wording. Semantically the concept is the same, though. An example is:
“You can say ‘car’, ‘bus’, or ‘train’. You can also say ‘I need different transportation.’”
Additionally, we began using a variant of the idea with open-ended prompts. Until the last couple of years, the standard was to coerce the caller into saying anything at a “What are you calling about today?” type prompt in the hopes we could pin a meaning on it. However, many callers are just not sure what to do or what will happen and so are reluctant to give an actionable utterance. At Voice Partners, then at SpeechCycle, rather then “erroring” into a menu, we began very successfully using “what are my choices” and “give me some choices” as ways callers could specify that they preferred a menu over the open prompt. Such phrases allow caller choice and control versus locking them into a specific interaction method.
The other area of growth is a more widespread use beyond up-front menus where HMWSE can still mean “I don’t want any of those so give me different options”. Some examples are follow-up menus after tasks are completed, lists of items to select from, and lists of global actions. Again, as the previous area indicates, these additional contexts sometimes require variations on the wording.
A Note: SE <> HMWSE
One thing I want to be clear about is that the use of HMWSE is better than just offering callers the phrase “something else”. In the past couple of years, I’ve heard systems presenting simply “something else” in menus, and that’s a mistake for reasons mentioned above. It fails on a semantic level to be a clear instruction to obtain other menu choices and instead at best sounds like an invitation to say anything. I strongly discourage its use.
So, don’t be afraid to offer your callers a good range of choices in more than one menu. In HMWSE you have a tested tool to use for that. Yes, there is research that I consider valid that shows that menus with more than four or five items can work well. However, there are contexts in which doing so might not be the best approach. Because of that, HMWSE helps round out the set of tools to help create great voice interactions when offering choices to callers.
Ideas around it first began back in 2000 or so on a project at Intervoice for a British Columbian transit company. We were designing a menu of options and were dissatisfied with the in vogue wording used to point to choices that were on a secondary menu. I.e.:
“You can say ‘plan a trip’, ‘get a schedule’, ‘paratransit’, or ‘more options’.”
That sort of phrasing seemed to be clunky and out of character for the design feel we wanted to deliver and we just felt it was inadequate for callers to latch onto.
In an informal discussion, one of my team members said “we need something else”, referring to the current choices being used in the design world, such as “more choices”, “other”, “none of those”, etc. When he said that, we looked at each other and said, “why not try ‘something else’ in the prompt?” So we began thinking about this:
“You can say ‘plan a trip’, ‘get a schedule’, ‘paratransit’, or ‘something else’.”
We liked where that was going, but quickly thought of a semantic problem in that the instruction seemed not to refer so much to additional choices but rather to telling the caller that they could say just about anything else. That, of course, was not the case and would cause interaction issues. Plus, the phrase seemed overly ambiguous, maybe even more so than “more options”. So after a bit of round-and-round about it, we determined that we wanted to try the phrase “help me with something else” (HMWSE).
“You can say ‘plan a trip, ‘get a schedule’, ‘paratransit’, or ‘help me with something else’.”
Though it might seem pedestrian now, this was a pretty novel idea at that time. The “more options” construction came directly from DTMF IVR menu structures, meaning it was deeply ingrained as the default presentation. Furthermore, in the early days of voice interaction design, there was an emphasis on pithy phrasing and HMWSE seemed like a mouthful. However, it had several strong characteristics that appealed to us. It was clear, used more common wording, and we actually heard similar phrasing in everyday conversations around us.
Fate, though, had other plans then. For a couple of reasons, we weren’t able to use the idea in that current design. But I held on to it for several years and finally had the opportunity to try it out again in 2004 at Voice Partners. We were working a significant redesign for a mobile carrier’s customer service line. As you can imagine, there were many functions for callers to choose from in the application. As soon as I saw the struggle with how to represent the concept of other things the callers could choose, I suggested that we try out HMWSE. I walked through its origins and we had some good discussion about why we though it would work. So we tried it in usability testing in opposition to the traditional “more options” and it was then that the strongest reason for the superiority of HMWSE emerged.
As we watched and listened to participants move through and struggle with the menus, two patterns of behavior became clear around their decisions to access more choices. Many of those who used “more options” seemed to be exhibiting surfing behavior triggered by that phrase. That is, they wanted to hear and think about all possible choices before committing to one because “more options” seemed to mean “more options that you might want to hear before you make a decision”. This frequently led, though, to failures in the menus as callers encountered cognitive load problems having to hold all the choices and their possible meanings in mind. Callers who heard and used HMWSE, however, did not encounter nearly the same number of problems. They were not surfing but rather, and this is the key point, they were listening to and then rejecting previously heard choices when they said HMWSE.
“Help me with something else” allowed them to hear, absorb, then discard choices they did not consider valid and specify to the system that new choices should be presented.
This was a major eye-opener for me, and my co-designers. While we had suspected that HMWSE was better, we had discovered a solid cognitive reason for it. Callers clearly preferred not to surf, but to have a way to eliminate choices rather than play a guessing game. Thus, HMWSE became a new best practice for use when menus exceeded a certain length.
Failing menu: “You can say ‘my bill’, ‘my plan’, ‘technical support’, or ‘more options’.”
Winning menu: “You can say ‘my bill’, ‘my plan’, or ‘technical support’. You can also say ‘help me with something else’.”
Now, to be clear, all the other principles of good menu design still apply. Choices must be clear, unique, and aurally distinct, among others. HMWSE is not a ticket to allow “anything goes” menu construction. But, when used with a solid set of menu items that need to span more than one presentation instance, it is the best choice for letting callers know that if they do not hear what they want in the initial list, they have a clear way of indicating that they want to discard the first list and hear another.
“More Options” for HMWSE
In the several years since that discovery, the use of HMWSE has grown in two ways.
First, I’ve encountered situations where a variation of HMWSE works better than the original wording. Semantically the concept is the same, though. An example is:
“You can say ‘car’, ‘bus’, or ‘train’. You can also say ‘I need different transportation.’”
Additionally, we began using a variant of the idea with open-ended prompts. Until the last couple of years, the standard was to coerce the caller into saying anything at a “What are you calling about today?” type prompt in the hopes we could pin a meaning on it. However, many callers are just not sure what to do or what will happen and so are reluctant to give an actionable utterance. At Voice Partners, then at SpeechCycle, rather then “erroring” into a menu, we began very successfully using “what are my choices” and “give me some choices” as ways callers could specify that they preferred a menu over the open prompt. Such phrases allow caller choice and control versus locking them into a specific interaction method.
The other area of growth is a more widespread use beyond up-front menus where HMWSE can still mean “I don’t want any of those so give me different options”. Some examples are follow-up menus after tasks are completed, lists of items to select from, and lists of global actions. Again, as the previous area indicates, these additional contexts sometimes require variations on the wording.
A Note: SE <> HMWSE
One thing I want to be clear about is that the use of HMWSE is better than just offering callers the phrase “something else”. In the past couple of years, I’ve heard systems presenting simply “something else” in menus, and that’s a mistake for reasons mentioned above. It fails on a semantic level to be a clear instruction to obtain other menu choices and instead at best sounds like an invitation to say anything. I strongly discourage its use.
So, don’t be afraid to offer your callers a good range of choices in more than one menu. In HMWSE you have a tested tool to use for that. Yes, there is research that I consider valid that shows that menus with more than four or five items can work well. However, there are contexts in which doing so might not be the best approach. Because of that, HMWSE helps round out the set of tools to help create great voice interactions when offering choices to callers.
Tuesday, September 1, 2009
This can be the beginning of a beautiful friendship
An interesting thing about going to tech-oriented conferences that mix business managers and implementers is the tension between messages. There are often competing and conflicting voices promoting technology and customer (user) experience. The technology vendors publicize the latest new thing, the upgrade that brings it all together, and the surefire way to get more customers spending more money. The experience folks shout that whatever is to be done must be done based purely on customer need and desire; that user experience (UX) is all that matters.
Now, it's no secret which side I've been on in most of these public discourses. Though I've been on the tech side in some cases, mostly by far I've preached from the gospel of good experience. And in the situation that it's clear that moving toward a certain technology would harm customer experience, my position would be unwavering.
However, the primary argument and distinction is no longer valid and true to me. I now see these two as elements on a continuum. Even as elements to alternate during and maybe even between projects. They are interdependent, and maybe even codependent.
The way I see it, many of our advances in customer experience have relied on or been part of new technology or new use of existing technology. From the other side, technology relies on good customer experience for successful adoption. Look at Amazon during the emergence of the commercial web. And then there's everybody's favorite example, Apple's iPhone. Both involved a push forward in customer experience AND the use of technology. Neither would be as successful without the blend of both. And neither would be as interesting if one aspect won out over the other.
Where I'm going with this is to request a truce in the tech versus UX battle. Both are good and both are needed. Tech creators need to acknowledge that they need good UX design to win the hearts and hands of consumers. UX-ers need to acknowledge that good technology is needed to advance parts of our cause and that new (good) tech gives us a chance to shine.
Before the truce can be fully agreed to though, we have a little catching up to do in the basics. Too much technology, useful as it can be, has been put out there without the needed UX crafting to accompany it. Because of that, both the users (consumers) and the technology are getting short shrift. Users feel ignored and abused. The tech vendors are getting slammed for very correctable reasons. We need to stop the train for a bit and get the interaction with the technology to the point where users can easily and satisfyingly do what they want to. Get the basics to the right level, then continue with a balanced approach.
(Aside: Not all tech implementations are redeemable, I know. But I am setting those cases aside for now and assuming that much of it can be helped.)
To illustrate, think again about what happened in the iPhone. For all its glory, it introduced very little new technology. Its primary features existed in other released or demoed products. The "new" about the iPhone is the better way that Apple blended the technology and UX.
Alternatively, there is also evidence that drawing back the level of technology used while improving the user experience is also effective. Wired magazine shows the examples of the Flip video camera and Skype, among others, in a recent article. Now, I disagree with the assessment they make that these simpler and easier to use products are just "good enough" since the implication is that they are inferior to the more feature-rich products. By typical standards such as profitability and rate of adoption, the new breeds are superior to their overdone predecessors.
There are many other areas where one approach or the other is needed, and I'll point to voice interaction as my prime example. A great many applications out there use speech recognition technology that is only a few years old. But most of the applications were designed using old or no design principles by people with negligible design training, if any. Furthermore, the technology is often under or incorrectly used. And the consumer reaction has been predictable. Interactive Voice Response is one of the most maligned technologies in our current age. On top of that, it often fails to meet the business goals for which it was brought in. This was avoidable and can be made right. It requires simply taking a break from the bumbling techno-lust and focusing on getting the UX in line with the level of technology chosen. Or even reducing the use of technology while improving performance through a UX focus.
So, it's time for a reset. For catching up and scaling down. We could make a huge positive difference in both business success and customer satisfaction by improving the user experience to the level of being on par with the state of deployed technology. And then we could grow both together. Satisfyingly, profitably, successfully.
Care to join me?
Now, it's no secret which side I've been on in most of these public discourses. Though I've been on the tech side in some cases, mostly by far I've preached from the gospel of good experience. And in the situation that it's clear that moving toward a certain technology would harm customer experience, my position would be unwavering.
However, the primary argument and distinction is no longer valid and true to me. I now see these two as elements on a continuum. Even as elements to alternate during and maybe even between projects. They are interdependent, and maybe even codependent.
The way I see it, many of our advances in customer experience have relied on or been part of new technology or new use of existing technology. From the other side, technology relies on good customer experience for successful adoption. Look at Amazon during the emergence of the commercial web. And then there's everybody's favorite example, Apple's iPhone. Both involved a push forward in customer experience AND the use of technology. Neither would be as successful without the blend of both. And neither would be as interesting if one aspect won out over the other.
Where I'm going with this is to request a truce in the tech versus UX battle. Both are good and both are needed. Tech creators need to acknowledge that they need good UX design to win the hearts and hands of consumers. UX-ers need to acknowledge that good technology is needed to advance parts of our cause and that new (good) tech gives us a chance to shine.
Before the truce can be fully agreed to though, we have a little catching up to do in the basics. Too much technology, useful as it can be, has been put out there without the needed UX crafting to accompany it. Because of that, both the users (consumers) and the technology are getting short shrift. Users feel ignored and abused. The tech vendors are getting slammed for very correctable reasons. We need to stop the train for a bit and get the interaction with the technology to the point where users can easily and satisfyingly do what they want to. Get the basics to the right level, then continue with a balanced approach.
(Aside: Not all tech implementations are redeemable, I know. But I am setting those cases aside for now and assuming that much of it can be helped.)
To illustrate, think again about what happened in the iPhone. For all its glory, it introduced very little new technology. Its primary features existed in other released or demoed products. The "new" about the iPhone is the better way that Apple blended the technology and UX.
Alternatively, there is also evidence that drawing back the level of technology used while improving the user experience is also effective. Wired magazine shows the examples of the Flip video camera and Skype, among others, in a recent article. Now, I disagree with the assessment they make that these simpler and easier to use products are just "good enough" since the implication is that they are inferior to the more feature-rich products. By typical standards such as profitability and rate of adoption, the new breeds are superior to their overdone predecessors.
There are many other areas where one approach or the other is needed, and I'll point to voice interaction as my prime example. A great many applications out there use speech recognition technology that is only a few years old. But most of the applications were designed using old or no design principles by people with negligible design training, if any. Furthermore, the technology is often under or incorrectly used. And the consumer reaction has been predictable. Interactive Voice Response is one of the most maligned technologies in our current age. On top of that, it often fails to meet the business goals for which it was brought in. This was avoidable and can be made right. It requires simply taking a break from the bumbling techno-lust and focusing on getting the UX in line with the level of technology chosen. Or even reducing the use of technology while improving performance through a UX focus.
So, it's time for a reset. For catching up and scaling down. We could make a huge positive difference in both business success and customer satisfaction by improving the user experience to the level of being on par with the state of deployed technology. And then we could grow both together. Satisfyingly, profitably, successfully.
Care to join me?
Sunday, August 30, 2009
Patterns and Experience
Enjoyed giving my two presentations last week at SpeechTEK in New York. Both seem well received, especially the patterns talk. It's gotten 150+ views on Slideshare since, which is very gratifying!
See them both for yourself:
Sorry for the formatting issues in the second one. They appeared after the upload. Not sure what's going on.
Later this week, I'll offer thoughts on SpeechTEK, and some talking points I covered in the presentations.
Good to see lots of folks!
See them both for yourself:
IVR Design Patterns
View more presentations from Phillip Hunter.
People Get Ready
View more presentations from Phillip Hunter.
Sorry for the formatting issues in the second one. They appeared after the upload. Not sure what's going on.
Later this week, I'll offer thoughts on SpeechTEK, and some talking points I covered in the presentations.
Good to see lots of folks!
Tuesday, August 18, 2009
A few thoughts on Consistency
While going through the Apple human interface guidelines, the section on consistency of the interface spurred some thoughts. This has been an discussion-provoking topic within interaction and interface design for some time and most especially for voice interaction.
Many times I've altered a recently seen screen heading, a repeated phrase of instruction, a past sequence of events, or a previously-used command for context and have been accused of "being inconsistent". Most of the time, I've been able to effectively point out how the context allows or even demands the change. Other times I've simply had to say "let's see what data we get." Other, other times I've had to accede to uneducated demands. And I'm sure I will have those arguments again, but, for the record and perhaps the education of a few, here are reasons to be consistent and times where consistency is bad.
Consistency is important for:
- Meeting user expectations and allowing predictability. A thing that looks like a button should be press-able or click-able. If a task seems like it could be done more than once, users should be able to, easily. Be consistent with the good and useful things users know and expect that they learned elsewhere.
- Promoting understanding and predictability of meaning. Users want to get what is happening and will happen. In speech, this is why using good synonyms is so important. We wouldn't (I hope!) dream of telling the user, "Say the same thing you did last time." We'll allow "checking", "checking account", and "debit account" all to mean the same thing. Because they do. Consistency here is the continuity of meaning, not the continued use of identical words.
- Infrequently given instructions and commands/actions. If a user needs to remember something, it should be predictable between tasks and especially sessions.
Consistency is bad when:
- It becomes distractingly repetitive. Hearing or seeing a menu for a third time in a task sequence shouldn't be like the first instance. Repeated instructions and events are easily ignored or glossed over. Items offered in context are more easily absorbed.
- It makes the user wonder if they are in a loop or a previous action was ignored. Let the interaction adapt and implicitly let the user know that the UI is "aware" of the evolving engagement that is occurring.
- It mimics behaviors we would consider highly unusual in people. I.e., "You can choose either your savings account or your checking account. So, just say 'savings account' or 'checking account'." A person being that consistent with the word 'account' would be looked at sideways. Implicature works for machines, too. Better: "You can choose either your savings or your checking account. So, just say 'savings' or 'checking'." Even better: "You can choose either your savings or checking account. So, which one?"
The moral here is, like other design principles, consistency is a fantastic and powerful concept to employ in the right places and ways. Used thoughtlessly, it can cause confusion and discomfort. If you're unsure, study it, ask questions, and most of all, bounce your design ideas off others and listen to feedback. Consistency is not a hammer to use to pound on a design you simply disagree with. In fact, doing so usually is a sign of ignorance of proper design practices. And no one likes to seem ignorant.
Design well.
Many times I've altered a recently seen screen heading, a repeated phrase of instruction, a past sequence of events, or a previously-used command for context and have been accused of "being inconsistent". Most of the time, I've been able to effectively point out how the context allows or even demands the change. Other times I've simply had to say "let's see what data we get." Other, other times I've had to accede to uneducated demands. And I'm sure I will have those arguments again, but, for the record and perhaps the education of a few, here are reasons to be consistent and times where consistency is bad.
Consistency is important for:
- Meeting user expectations and allowing predictability. A thing that looks like a button should be press-able or click-able. If a task seems like it could be done more than once, users should be able to, easily. Be consistent with the good and useful things users know and expect that they learned elsewhere.
- Promoting understanding and predictability of meaning. Users want to get what is happening and will happen. In speech, this is why using good synonyms is so important. We wouldn't (I hope!) dream of telling the user, "Say the same thing you did last time." We'll allow "checking", "checking account", and "debit account" all to mean the same thing. Because they do. Consistency here is the continuity of meaning, not the continued use of identical words.
- Infrequently given instructions and commands/actions. If a user needs to remember something, it should be predictable between tasks and especially sessions.
Consistency is bad when:
- It becomes distractingly repetitive. Hearing or seeing a menu for a third time in a task sequence shouldn't be like the first instance. Repeated instructions and events are easily ignored or glossed over. Items offered in context are more easily absorbed.
- It makes the user wonder if they are in a loop or a previous action was ignored. Let the interaction adapt and implicitly let the user know that the UI is "aware" of the evolving engagement that is occurring.
- It mimics behaviors we would consider highly unusual in people. I.e., "You can choose either your savings account or your checking account. So, just say 'savings account' or 'checking account'." A person being that consistent with the word 'account' would be looked at sideways. Implicature works for machines, too. Better: "You can choose either your savings or your checking account. So, just say 'savings' or 'checking'." Even better: "You can choose either your savings or checking account. So, which one?"
The moral here is, like other design principles, consistency is a fantastic and powerful concept to employ in the right places and ways. Used thoughtlessly, it can cause confusion and discomfort. If you're unsure, study it, ask questions, and most of all, bounce your design ideas off others and listen to feedback. Consistency is not a hammer to use to pound on a design you simply disagree with. In fact, doing so usually is a sign of ignorance of proper design practices. And no one likes to seem ignorant.
Design well.
Thursday, April 16, 2009
Designing for Success - A New Start (again)
This week I stepped out of the airplane again, into the rushing wind hurtling towards earth - beauty, thrill, opportunity, independence, and complete dependence. After three years working with great people on cool stuff, I’ve decided to play on the bigger field, becoming my own boss again, and have left SpeechCycle. I love design and helping people with design and design strategy and I want to do that for a larger group of customers across a larger set of domains.
Of course, this seems like a crazy time to jump when people are losing jobs and homes and all, but I was really inspired by some of the people I met at the IxDA conference and the itch has gotten worse. In addition, I've been shown several times recently that some of the most successful companies of this century and last were started during downturns. And even more specifically, one of the most successful designers in American history, Henry Dreyfuss, started his practice in 1929. As he put it,
I believe right now there are significant opportunities for companies to make the same sort of investments that improve the customer experience and the bottom line at the same time.
I can help make you successful and profitable by making your customers enjoy your services and products more.
I am offering design services in the areas of voice, mobile, and web/desktop applications. Specifically, I can help with design strategy, requirements, prototyping, and of course complete designs and documentation for them.
In addition, for companies looking at how their speech application is performing or thinking about starting a speech recognition project, I can help navigate the waters of performance evaluation and improvement as well as knowing whether a speech IVR vendor is providing the right solution.
To get started, I will consult and contract under design out loud. At some point, there will be a separate web site for that. For now, you can read about my abilities and background on my CV/résumé site, www.phillipwhunter.com.
I look forward to getting to know many more of you. And of course, I welcome the chance to contribute to projects you are involved in or can recommend me to. Please get in touch via phillip (at) phillipwhunter (dot) com.
As always, your comments are welcomed.
Of course, this seems like a crazy time to jump when people are losing jobs and homes and all, but I was really inspired by some of the people I met at the IxDA conference and the itch has gotten worse. In addition, I've been shown several times recently that some of the most successful companies of this century and last were started during downturns. And even more specifically, one of the most successful designers in American history, Henry Dreyfuss, started his practice in 1929. As he put it,
“When business reached bottom, companies began to undercut each other. At the same time, alert manufacturers came to the realization that the answer to their problem lay in making their product work better, more convenient to the consumer, and better-looking.”
I believe right now there are significant opportunities for companies to make the same sort of investments that improve the customer experience and the bottom line at the same time.
I can help make you successful and profitable by making your customers enjoy your services and products more.
I am offering design services in the areas of voice, mobile, and web/desktop applications. Specifically, I can help with design strategy, requirements, prototyping, and of course complete designs and documentation for them.
In addition, for companies looking at how their speech application is performing or thinking about starting a speech recognition project, I can help navigate the waters of performance evaluation and improvement as well as knowing whether a speech IVR vendor is providing the right solution.
To get started, I will consult and contract under design out loud. At some point, there will be a separate web site for that. For now, you can read about my abilities and background on my CV/résumé site, www.phillipwhunter.com.
I look forward to getting to know many more of you. And of course, I welcome the chance to contribute to projects you are involved in or can recommend me to. Please get in touch via phillip (at) phillipwhunter (dot) com.
As always, your comments are welcomed.
Wednesday, April 8, 2009
I don't think I said what you think I said - Interviews and "Natural Language"
"Hi, I've just got a few questions." Not everyone likes it, but I will admit I do. I like to get interviewed. I like to be asked questions. I like to feel like someone cares about my answers, relative truth aside. I like to think the thoughts and words will make their way into a tight, punchy piece that makes a reader or a thousand think a different thought or care more. But, I know enough from a media course and life to know better than to expect much of that.
Now, this week, I received several mentions in a Speech Technology magazine article and I'm glad. It's a bit ironic, given news I'll get to in another post, but I'm enjoying it. At the risk of not getting interviewed in the future, I do need, though, to straighten out a tiny thing or two.
So, if you're not a speech geek, or wanna-be speech geek, skip to the next post, otherwise, a couple of discussion points:
First, the article is a great intro to current thinking about the use of open-prompting (soliciting content constrained by context, not wording). I favor this approach when it makes sense and can be delivered properly. In general, my thoughts are represented well. But, to get to the point, I didn't actually assert "that callers shouldn’t be exposed to a hierarchy of more than five categories." I do think menus structured like that can be problematic and are frequently done poorly, but research (Hura & McKienzie) and deployments (McKienzie, Levine) have shown that the right combination of wording and delivery can allow menus to be fairly lengthy and still be effective. I agree with those findings.
Moving on, the article discusses the idea that a high-frequency example is very important, which is correct. However, open-prompts should almost never start with "How may I help you?" Not only is there a register problem, but putting the call to action before giving the caller space to respond is generally a recipe for disaster, despite enabling barge-in.
Next, "performance anxiety," my (unattributed) quote, is not a technical term. Funny? Yes. Not technical.
Then, the sentence reading "Users are given the option of accessing them by saying something like What are some choices?" really should read "Callers can be given the option to access them by suggesting they say something like "Give me some choices." The difference appears subtle, but trust me, it's important. Control and certainty are increased by this very much directive statement, whereas the other feels too much like browsing.
Lastly, I need to put a finer point on "it’s important to design the back-off menu open-ended like the first prompt." Actually, the true matter is to allow not a full range of open responses, but to look for responses in tuning data for the menu and adding to the grammar utterances that are clearly a response to the open prompt but not in-grammar for the menu. For example, a caller saying "my internet account" to a menu asking them to specify whether their call is about their bill, an order, tech support, or an appointment. And of course adding logic to handle such utterances. Doing this will be effective and caller-pleasing without the trouble of a parallel SLM grammar.
So, these are not slams, but rather just trying to make sure that the right information is out there. The article is, I think and hope, a good discussion starter. Including the last few paragraphs, which are sort of not-directly-on-topic, but are vitally important nonetheless.
Please add your take on the article here. If you want to know more about the concepts presented there or here, or you want to interview me ;), please let me know: phillip at phillipwhunter dot com.
-pnl
UPDATE: Eric Barkin responded very graciously to my post on his SpeechTech blog page. I appreciate his comments and especially agree with the points about the need for a larger design improvement discussion.
Now, this week, I received several mentions in a Speech Technology magazine article and I'm glad. It's a bit ironic, given news I'll get to in another post, but I'm enjoying it. At the risk of not getting interviewed in the future, I do need, though, to straighten out a tiny thing or two.
So, if you're not a speech geek, or wanna-be speech geek, skip to the next post, otherwise, a couple of discussion points:
First, the article is a great intro to current thinking about the use of open-prompting (soliciting content constrained by context, not wording). I favor this approach when it makes sense and can be delivered properly. In general, my thoughts are represented well. But, to get to the point, I didn't actually assert "that callers shouldn’t be exposed to a hierarchy of more than five categories." I do think menus structured like that can be problematic and are frequently done poorly, but research (Hura & McKienzie) and deployments (McKienzie, Levine) have shown that the right combination of wording and delivery can allow menus to be fairly lengthy and still be effective. I agree with those findings.
Moving on, the article discusses the idea that a high-frequency example is very important, which is correct. However, open-prompts should almost never start with "How may I help you?" Not only is there a register problem, but putting the call to action before giving the caller space to respond is generally a recipe for disaster, despite enabling barge-in.
Next, "performance anxiety," my (unattributed) quote, is not a technical term. Funny? Yes. Not technical.
Then, the sentence reading "Users are given the option of accessing them by saying something like What are some choices?" really should read "Callers can be given the option to access them by suggesting they say something like "Give me some choices." The difference appears subtle, but trust me, it's important. Control and certainty are increased by this very much directive statement, whereas the other feels too much like browsing.
Lastly, I need to put a finer point on "it’s important to design the back-off menu open-ended like the first prompt." Actually, the true matter is to allow not a full range of open responses, but to look for responses in tuning data for the menu and adding to the grammar utterances that are clearly a response to the open prompt but not in-grammar for the menu. For example, a caller saying "my internet account" to a menu asking them to specify whether their call is about their bill, an order, tech support, or an appointment. And of course adding logic to handle such utterances. Doing this will be effective and caller-pleasing without the trouble of a parallel SLM grammar.
So, these are not slams, but rather just trying to make sure that the right information is out there. The article is, I think and hope, a good discussion starter. Including the last few paragraphs, which are sort of not-directly-on-topic, but are vitally important nonetheless.
Please add your take on the article here. If you want to know more about the concepts presented there or here, or you want to interview me ;), please let me know: phillip at phillipwhunter dot com.
-pnl
UPDATE: Eric Barkin responded very graciously to my post on his SpeechTech blog page. I appreciate his comments and especially agree with the points about the need for a larger design improvement discussion.
Friday, April 3, 2009
WTF? Public Behavior, Infernal Machines, and Voice Interaction/Interface Design
Recently one of the semi-annually popular questions in the voice interface world floated out of its storage closet and back into the email list shared by many speech designers: “What should our applications do when cursing by a caller is detected?” I thought about not responding this time, but realized that we hadn’t really publicly hashed out the argument for not doing anything too special. Plus, we always joke about having an app say something like “Do you kiss your mother with that mouth?” which has been said enough to worry me that maybe someone will take it seriously. So, I responded that trying to be sure of what sub-context is meant by the caller is very difficult and many times the use of vulgarity is in fact not a sign of trouble or frustration. It is more effective to focus our efforts on creating effective and pleasant interactions for the vast majority of callers who are not swearing out of frustration or at all. That’s what I posted to the list.
The response to that was the equivalent of crickets and instead other respondents focused, as before, on maybe doing this or that, all essentially variations on the theme of giving negative reinforcement to the caller or even punishing them, such as going silent for a while or transferring them to a low-priority wait queue. My thought on that is, as a colleague suggested, let’s figure out how to make mallets bop the caller on the head every time they swear.
The bottom line is that designs must accommodate and respond accommodatingly to a wide variety of social behaviors, some of which will differ greatly from the company’s and designer’s point of views and cultural biases. While an organization might understandably choose to have a strict policy regarding how their customers are allowed to treat employees, it is ridiculous to think of requiring similar behavior standards for actions around or even toward inanimate software. It is not wise or even practical to try to enforce ambiguous, dynamic, class- and culture-based behavior norms on people who are not asking for it and are often already upset or stressed by a situation they perceive as been caused by the company. Make no mistake, designers are in the behavior modification business. However, that is true only as far as required to achieve the person’s desired goal within the allowances of the company.
Be nice to the people using your application, but don’t get bothered if they aren’t nice back. Don’t try to change behavior that is not directly relevant to their success. Focus on getting to success.
The response to that was the equivalent of crickets and instead other respondents focused, as before, on maybe doing this or that, all essentially variations on the theme of giving negative reinforcement to the caller or even punishing them, such as going silent for a while or transferring them to a low-priority wait queue. My thought on that is, as a colleague suggested, let’s figure out how to make mallets bop the caller on the head every time they swear.
The bottom line is that designs must accommodate and respond accommodatingly to a wide variety of social behaviors, some of which will differ greatly from the company’s and designer’s point of views and cultural biases. While an organization might understandably choose to have a strict policy regarding how their customers are allowed to treat employees, it is ridiculous to think of requiring similar behavior standards for actions around or even toward inanimate software. It is not wise or even practical to try to enforce ambiguous, dynamic, class- and culture-based behavior norms on people who are not asking for it and are often already upset or stressed by a situation they perceive as been caused by the company. Make no mistake, designers are in the behavior modification business. However, that is true only as far as required to achieve the person’s desired goal within the allowances of the company.
Be nice to the people using your application, but don’t get bothered if they aren’t nice back. Don’t try to change behavior that is not directly relevant to their success. Focus on getting to success.
Sunday, March 22, 2009
Data, Art, Design, and a big ID/IxD Success Story
Three events occurred, or were publicized, in the past few days that merit posting here and considering all together. First, an apparently widely-respected visual designer left Google using some strong language about his frustration regarding the design mentality there. I'll let you read his words to get your own impression rather than commenting directly.
You back? Ok.
To paraphrase somewhat, he tells a fresh tale of the decades-old battle of design based on data versus what some like to call "art". We in the Voice Interaction realm have had the same challenges and have often said in our little world that VUI Design is a "science and art". And while I have even held forth on that, I have been uncomfortable for the past few years with that way of characterizing it. One reason is that many of our language structure and wording decisions are actually based on researched and published linguistic and thought paradigms, similar to visual design choices about layout and color. Secondly, designing well is often an exercise in doing so within limitations and with compromises instead of letting one's expressionistic soul run free (That's a great thing for your painting or weekend band. Not usually so good for the business needs of your employer.).
Which leads me to the second event. OK/Cancel is a comic and blog by a couple of guys who took a hiatus from the end of 2007 to now and returned strongly with a great strip and good commentary on the ex-Googler and the data/art debate that fits nicely with my comments above and the article I wrote with Roberto Pieraccini linked to above. This is an area we in speech and all designers need to reflect on in order to truly begin the maturation of our practices, processes, and reputation.
Doing so will, I believe, lead to more of the third event. Thursday's NY Times ran this article in the Inside Technology section, A Tiny Camcorder Has a Big Payday. Pure Digital Technologies, the maker of the very popular Flip camcorder (audio warning) was purchased for $590 million by Cisco (About a 2.5-3x valuation as near as I can tell). To me, this is a triumph of good design. Cisco decided that a profitable company focused on simple, good products could add to Cisco's bottom line for years to come. While their decision was most certainly not all about good design, the philosophy of Pure Digital mostly is. This should serve as reinforcement and encouragement to all designers that combining customer focus, good design principles and practices with persistence and reading the market in-between the lines can and does work because success is success.
Good Design in 2009.
-pnl
You back? Ok.
To paraphrase somewhat, he tells a fresh tale of the decades-old battle of design based on data versus what some like to call "art". We in the Voice Interaction realm have had the same challenges and have often said in our little world that VUI Design is a "science and art". And while I have even held forth on that, I have been uncomfortable for the past few years with that way of characterizing it. One reason is that many of our language structure and wording decisions are actually based on researched and published linguistic and thought paradigms, similar to visual design choices about layout and color. Secondly, designing well is often an exercise in doing so within limitations and with compromises instead of letting one's expressionistic soul run free (That's a great thing for your painting or weekend band. Not usually so good for the business needs of your employer.).
Which leads me to the second event. OK/Cancel is a comic and blog by a couple of guys who took a hiatus from the end of 2007 to now and returned strongly with a great strip and good commentary on the ex-Googler and the data/art debate that fits nicely with my comments above and the article I wrote with Roberto Pieraccini linked to above. This is an area we in speech and all designers need to reflect on in order to truly begin the maturation of our practices, processes, and reputation.
Doing so will, I believe, lead to more of the third event. Thursday's NY Times ran this article in the Inside Technology section, A Tiny Camcorder Has a Big Payday. Pure Digital Technologies, the maker of the very popular Flip camcorder (audio warning) was purchased for $590 million by Cisco (About a 2.5-3x valuation as near as I can tell). To me, this is a triumph of good design. Cisco decided that a profitable company focused on simple, good products could add to Cisco's bottom line for years to come. While their decision was most certainly not all about good design, the philosophy of Pure Digital mostly is. This should serve as reinforcement and encouragement to all designers that combining customer focus, good design principles and practices with persistence and reading the market in-between the lines can and does work because success is success.
Good Design in 2009.
-pnl
Thursday, February 19, 2009
Finally: IxDA 2009 – Vancouver, BC, Canada, in five parts
Arrival
The Interaction Design Association is a young professional organization that just put on its second annual conference. I missed the first in 2008, held in
Why apprehensive? I felt like the new kid starting school in the middle of the year as well as a bit of an interloper. All of these people probably knew each other well and I had only met a few briefly. Plus, so many of them have degrees in a field barely ten years old! I felt unknown and unqualified to be attending. Also imposing was that my area of focus in interaction design has been speech recognition, little known and less understood. I have done some web and desktop app design, but nothing on the scale of many of the attendees. I was actually going to be around people responsible for design thought and work that I had admired for years. For me, it was a bit like being a guitar player (oh, actually I am) and getting to meet someone like Eric Johnson. But I knew virtually none of them would be able to relate to my daily craft. Nonetheless, I was determined not to be a wallflower and so to meet as many people as I could, find out more about them, and hopefully, make some sort of decent impression. Most of all, I hoped to really stretch my brain into design areas I have only dabbled in or read about, especially mobile and service.
Things started well right after arrival. An uneventful flight and border crossing led to sitting on a bus with three guys from Chicago’s Manifest Digital, Jim, Kevin, and Jason. They were there as sponsors and participants. We briefly traded details of who and where and then concentrated on finding our hotel. I would meet up with them again later, to my gain in more ways than one.
The afternoon weather was fantastic and I was able to walk around bit taking photos and had a bite to eat at Steamworks, a brewpub in Gastown. Their Coal Porter brew was the best micro I’ve had in a long time. After that, I headed to the room (by the way, I found the Four Seasons to be very comfortable and I had a great view) early due to no energy and wanting to be ready to learn in the morning. I followed a few arrivals via twitter and settled in.
Saturday, January 3, 2009
Do your dinner guests quiver in excitement...or in fear?
Can you cook? I mean really cook? I mean your friends and family love it when you host the dinner party and your appetizer is the first one attacked at the potluck. If so, chances are that the word recipe has significance similar to "guidelines" or even "suggestions" rather than "rules" or "the straight and narrow". Design is like cooking. And as with cooking, there are those who generate joy and delight during the creation and consumption, there are those who get a job done, and there are those who really ought to re-examine the color of their parachute.
As I was contemplating writing this post and using this metaphor, I came across this from Bill Buxton (in his wonderful book Sketching User Experiences, also linked to earlier): "(L)isting ingredients is always risky. Just because I give you flour, milk, yeast, eggs, and an oven does not mean that you know how to make bread at all, much less the multitude of variations that you might find in a good bakery." This is exactly the sort of analogy I had been thinking about. Just because someone knows the design process and a pattern or two and what the end product is generally supposed to be like does not mean that that person is a designer. He goes on to discuss the complexities and content of designing, but let me make sure this is clear. Neither I, nor he, are drawing a parallel to needing more unrestrained creativity in design. In other words, the parameters of cooking are typically a little larger and looser than the design we practice, and I am not stating that designers should practice wild creativity, though it can be a good thing. I am saying that far too many people calling themselves designers are at best good only at finding and following a recipe and at worst are burning toast. Now, I don't mean most, but simply too many. But that condition has been true for many years and has led to many of the problems that we have with consumer rejection of our interface product. All who call themselves designers need to frequently examine whether they are truly performing a service in the best sense of that word. I have come to believe that there is an element of morality in the design profession, similar to being a physician or a law enforcement official. Which means that practicing design simply to earn a buck or have something to do is lacking ethically and morally. It does a disservice and may even cause harm greater than the negative economic consequences it leads to.
So, if you cannot claim to be even a recipe follower, then I encourage to do some self-examination and consult people you trust about changing careers. If you are a recipe follower, I encourage you to seek the path of becoming a chef. And if you are a chef, I implore you most strongly and even charge you with the responsibility of exercising ethics and morality in your design practice:
Always practice the best design possible.
Always point out when design compromise will lead to intolerable consequences.
Be bold in identifying bad design.
We simply must change the role of design from creating specifications to improving life.
Make 2009 the Year of Good Design.
Happy New year!
As I was contemplating writing this post and using this metaphor, I came across this from Bill Buxton (in his wonderful book Sketching User Experiences, also linked to earlier): "(L)isting ingredients is always risky. Just because I give you flour, milk, yeast, eggs, and an oven does not mean that you know how to make bread at all, much less the multitude of variations that you might find in a good bakery." This is exactly the sort of analogy I had been thinking about. Just because someone knows the design process and a pattern or two and what the end product is generally supposed to be like does not mean that that person is a designer. He goes on to discuss the complexities and content of designing, but let me make sure this is clear. Neither I, nor he, are drawing a parallel to needing more unrestrained creativity in design. In other words, the parameters of cooking are typically a little larger and looser than the design we practice, and I am not stating that designers should practice wild creativity, though it can be a good thing. I am saying that far too many people calling themselves designers are at best good only at finding and following a recipe and at worst are burning toast. Now, I don't mean most, but simply too many. But that condition has been true for many years and has led to many of the problems that we have with consumer rejection of our interface product. All who call themselves designers need to frequently examine whether they are truly performing a service in the best sense of that word. I have come to believe that there is an element of morality in the design profession, similar to being a physician or a law enforcement official. Which means that practicing design simply to earn a buck or have something to do is lacking ethically and morally. It does a disservice and may even cause harm greater than the negative economic consequences it leads to.
So, if you cannot claim to be even a recipe follower, then I encourage to do some self-examination and consult people you trust about changing careers. If you are a recipe follower, I encourage you to seek the path of becoming a chef. And if you are a chef, I implore you most strongly and even charge you with the responsibility of exercising ethics and morality in your design practice:
Always practice the best design possible.
Always point out when design compromise will lead to intolerable consequences.
Be bold in identifying bad design.
We simply must change the role of design from creating specifications to improving life.
Make 2009 the Year of Good Design.
Happy New year!
Wednesday, December 10, 2008
Let's try to catch up sometime
One of my favorite things to pick on about the little speech reco world we play in is how often we seem to let it slip our mind that there is a much larger world of interaction design for software and its users out there. It's not that some haven't tried to show us over the past decade, but somehow our entire focus keeps turning back inward to our industry and our practice. I believe this is unhealthy for multiple reasons and said so most publicly in my talk at SpeechTek 2007.
Though it is understandable, to a certain degree, one of my little missions is to change that as I can. So, occasionally, I will link to older content on the web that I think provides valuable input to our efforts from outside our normal ping-pong ball sphere of operation.
These will be in no order other than when I think of them and/or run across them. The first is from a respected and multi-facted web designer, Cameron Moll, and is a presentation he gave in the fall of 2006, Nine skills that separate good and great designers.
While some of this is about visual interfaces specifically, most addresses thinking about and creating great design in general. Enjoy. Please.
Though it is understandable, to a certain degree, one of my little missions is to change that as I can. So, occasionally, I will link to older content on the web that I think provides valuable input to our efforts from outside our normal ping-pong ball sphere of operation.
These will be in no order other than when I think of them and/or run across them. The first is from a respected and multi-facted web designer, Cameron Moll, and is a presentation he gave in the fall of 2006, Nine skills that separate good and great designers.
While some of this is about visual interfaces specifically, most addresses thinking about and creating great design in general. Enjoy. Please.
Saturday, December 6, 2008
Published - VUI - Art with Science
The column I referred to a few weeks ago is out now. Thanks TMA Associates! Read it!
Wednesday, December 3, 2008
Rules and instructions - People behave like water
In a nice Speech Technology mag article from Dr. Susan, she highlights that people, in this case callers to automated systems, frequently behave like water (my interpretation, not hers). That is, they try to find the easiest way to get what they want most of the time. Other times, they barrel over any seemingly arbitrary obstacles when they perceive that there is a way to accomplish what they want.
She rightly points out the fine details of how to deal with these issues in a couple of specific situations. The larger lessons are: a) if you make rules (right or wrong) for customers, make sure they know them and make sure they are consistent across the board; b) to maximize success all the way around, facilitate the fastest, easiest way (according to the customer!) to get where the person wants to go.
Too often, our designs provide interaction that is more like dams and channel locks and less like soothing mountain streams.
She rightly points out the fine details of how to deal with these issues in a couple of specific situations. The larger lessons are: a) if you make rules (right or wrong) for customers, make sure they know them and make sure they are consistent across the board; b) to maximize success all the way around, facilitate the fastest, easiest way (according to the customer!) to get where the person wants to go.
Too often, our designs provide interaction that is more like dams and channel locks and less like soothing mountain streams.
Tuesday, November 18, 2008
"the art of vui"
From a column to be published soon.
The view (we have) of the art of VUI does not parallel the applied education and craft found among the professional practitioners of the classic arts. In those fields, science is as much a tool as instrument, chisel, and brush. The expert composer deftly manipulates the mathematical intricacies of sound over time. The learned sculptor understands how to wield force against the limits of steel and stone. The master painter possesses the insight to blend and bend hue and light, oil and pigment. All three, though, along with the other arts, have a singular, common, and nearly unknowable component in the final product: the emotional result produced in those that experience their work. Yet that causes the artists to know and master their tools and domain even more.
The view (we have) of the art of VUI does not parallel the applied education and craft found among the professional practitioners of the classic arts. In those fields, science is as much a tool as instrument, chisel, and brush. The expert composer deftly manipulates the mathematical intricacies of sound over time. The learned sculptor understands how to wield force against the limits of steel and stone. The master painter possesses the insight to blend and bend hue and light, oil and pigment. All three, though, along with the other arts, have a singular, common, and nearly unknowable component in the final product: the emotional result produced in those that experience their work. Yet that causes the artists to know and master their tools and domain even more.
Subscribe to:
Posts (Atom)