Personas, then people
Robert | 12.26.2005 @ 2:48 PM
Permalink | 0 Comments
It may have taken four months for me to stumble across this article, but now that I've read
Persona Non Grata, by Dan Saffer at Adaptive Path, I want to debate one of Saffer's statements. Consider the following:
"There’s little sense in having a set of personas around if you don’t beat them against actual projects. Once you’ve developed a persona set, the team needs to use them, by running them through scenarios of use and testing features both for appropriateness and for utility. Would this persona do this task? Could this persona do this task as it is designed?"
I agree completely with the first sentence. And the second one. But the two questions that end the paragraph imply that Adaptive Path continues to rely on personas after their usefulness has run out.
Personas are best used when designing a product. Once the product has been created, or at least prototyped, I strongly feel their usefulness has expired. How can we even pretend that we can objectively answer questions like "Could this persona do this task as it is designed?" We're not character actors, we're designers. We take the information we get from user-research and construct personas from it. Then we use those personas as a target for the design, and we focus the design strictly on the personas, so only what is good for the target audience is created. Once the design becomes a product, the answer to Saffer's question is going to be "yes" far more often than it should be. We're certainly not going to readily admit that we designed something that does not work for our personas. No, no, no.
Most, if not all, interaction designers know, at least to some degree, that programmers don't respect them unless they're decisions are confident and based in reality. Wavering after code has been written is the last thing you'd ever want to do, so when you start asking if your persona will be able to complete a certain task as you've designed it, you're answer is assuredly going to be "yes". If it's not, you're a fool. If it is, you're answer is not based on reality.
Use personas for interaction design (up to and including wireframes and mockups). Once a functioning product is in the works, use real people to test it instead of running what are ultimately imaginary people through imaginary situations (a.k.a "scenarios"). Go back to the same people you interviewed while creating personas and test the product with them. Find people who represent your target audience and test the product with them.
Use personas to guide the design. Use people to validate it.
Permalink | 0 Comments
It may have taken four months for me to stumble across this article, but now that I've read
Persona Non Grata, by Dan Saffer at Adaptive Path, I want to debate one of Saffer's statements. Consider the following:
"There’s little sense in having a set of personas around if you don’t beat them against actual projects. Once you’ve developed a persona set, the team needs to use them, by running them through scenarios of use and testing features both for appropriateness and for utility. Would this persona do this task? Could this persona do this task as it is designed?"
I agree completely with the first sentence. And the second one. But the two questions that end the paragraph imply that Adaptive Path continues to rely on personas after their usefulness has run out.
Personas are best used when designing a product. Once the product has been created, or at least prototyped, I strongly feel their usefulness has expired. How can we even pretend that we can objectively answer questions like "Could this persona do this task as it is designed?" We're not character actors, we're designers. We take the information we get from user-research and construct personas from it. Then we use those personas as a target for the design, and we focus the design strictly on the personas, so only what is good for the target audience is created. Once the design becomes a product, the answer to Saffer's question is going to be "yes" far more often than it should be. We're certainly not going to readily admit that we designed something that does not work for our personas. No, no, no.
Most, if not all, interaction designers know, at least to some degree, that programmers don't respect them unless they're decisions are confident and based in reality. Wavering after code has been written is the last thing you'd ever want to do, so when you start asking if your persona will be able to complete a certain task as you've designed it, you're answer is assuredly going to be "yes". If it's not, you're a fool. If it is, you're answer is not based on reality.
Use personas for interaction design (up to and including wireframes and mockups). Once a functioning product is in the works, use real people to test it instead of running what are ultimately imaginary people through imaginary situations (a.k.a "scenarios"). Go back to the same people you interviewed while creating personas and test the product with them. Find people who represent your target audience and test the product with them.
Use personas to guide the design. Use people to validate it.
The necessity and art of "Just in Time Design"
Robert | 12.23.2005 @ 10:57 AM
Permalink | 0 Comments
In the real world, Alan Cooper's methods don't always work. This is true not because Cooper is wrong, but because too many companies skip the interaction design process completely, leaving it up to programmers to "design" software themselves, making spur of the moment decisions that greatly, and most often adversely, affect the experience of using the application. When design is left up to programmers, software becomes complicated, extremely difficult to use, and bloated with edge-case features that, while giving marketers a hefty list of bells and whistles to cite in marketing collateral, actually inhibit the ability for most users to use the software effectively to accomplish their goals.
As long as this remains true, "Just in Time Design" must be allowed into the process. Just in Time (JIT) design is the act of doing intentional design work right when it's needed the most, which is the moment right after someone has decided to add a new feature and right before the programmer starts producing code. (This is especially true and necessary when the software company adheres to eXtreme Programming methodologies, which creates a constant state of in-flux prioritization.) Excluding quality interaction design work prior to software development is a bad idea, but when it happens (and it happens on a daily basis in the corporate world), JIT design must occur so that at least some intelligent design can make its way into the final product.
I hesitate to call this eXtreme Design, by the way, because doing so grants permission to stakeholders to ignore the interaction design process and latch onto the catchy "eXtreme Design", a phrase which sounds cool and cutting-edge, but cannot ever be as effective as interaction design.
JIT design, in my world anyway, generally entails holding a quick meeting before the coding starts to brainstorm and decide how a new piece of the software will behave, how it will be accessed or invoked, and how it will look. This meeting can take five minutes or three hours, but it must be done. And the meeting should always include someone with user-interaction know-how. If you don't have any experts around, grab the person with the most earnest level of interest in the subject and give him or her ownership of the role (people tend to step up to even extreme responsibility when given ownership).
During this metting, at least one programmer, one designer, and one user should be present. While this sounds like the ever-ineffective "seat at the table" approach, it generally offers exactly what is needed for the purpose: a representative user (usually an interal employee) to talk about what he or she needs and wants, a designer to interpet those needs and make suggestions about possible solutions, and a programmer to map out the feasibility of the suggestions and quietly begin devising a coding plan.
The result of such a meeting may or may not involve assigning the task of creating wireframes for the new interaction. Wireframes are preferable, but when there's no time to wireframe, at least the programmers will have a good idea of what to build and how it should behave prior to making impulsive decisions that lead to more bad software. Believe me, folks, this is the bare minimum of what should be done, but is significantly better than doing no design work at all. This way, at least more than one person has been involved in the decision process, and at least one of them is a real-live user.
Whenever possible, a resident expert on interaction design should be present (whoever might be the best person you can get), so he or she can make educated suggestions about how to make the particular piece of software more usable, more flowing and intuitive, and more likely to help users achieve their goals. In a worst-case scenario, where no interaction gurus are available, you should at least have a graphic designer in the conversation, so that an improved look stands a chance of improving the interaction. Again, this is in a worst-case scenario. Your company should always have in its employ someone who has done extensive research on how people actually use computers so he or she can make educated suggestions about how to improve the experience.
JIT design should not have to exist, as Interaction Design should always occur prior to building anything an end-user will touch, but since interaction design is currently ignored in entirely too many situations, JIT design is the best one can hope for, and the best attempt at a remedy before things get too out of hand and you end up with software loaded with features that make users feel stupid by neglecting their needs and wants.
A user who has his goals ignored is a user who will never be a true fan of your software, and true fans are the best thing a company can possibly acquire. If you cannot include quality interaction design as part of your process, you must, at the very minimum, allow JIT design to run interference between stakeholders and programmers. With modern computing quickly becoming as ubiquitous as sliced bread, it's a moral imperative.
Permalink | 0 Comments
In the real world, Alan Cooper's methods don't always work. This is true not because Cooper is wrong, but because too many companies skip the interaction design process completely, leaving it up to programmers to "design" software themselves, making spur of the moment decisions that greatly, and most often adversely, affect the experience of using the application. When design is left up to programmers, software becomes complicated, extremely difficult to use, and bloated with edge-case features that, while giving marketers a hefty list of bells and whistles to cite in marketing collateral, actually inhibit the ability for most users to use the software effectively to accomplish their goals.
As long as this remains true, "Just in Time Design" must be allowed into the process. Just in Time (JIT) design is the act of doing intentional design work right when it's needed the most, which is the moment right after someone has decided to add a new feature and right before the programmer starts producing code. (This is especially true and necessary when the software company adheres to eXtreme Programming methodologies, which creates a constant state of in-flux prioritization.) Excluding quality interaction design work prior to software development is a bad idea, but when it happens (and it happens on a daily basis in the corporate world), JIT design must occur so that at least some intelligent design can make its way into the final product.
I hesitate to call this eXtreme Design, by the way, because doing so grants permission to stakeholders to ignore the interaction design process and latch onto the catchy "eXtreme Design", a phrase which sounds cool and cutting-edge, but cannot ever be as effective as interaction design.
JIT design, in my world anyway, generally entails holding a quick meeting before the coding starts to brainstorm and decide how a new piece of the software will behave, how it will be accessed or invoked, and how it will look. This meeting can take five minutes or three hours, but it must be done. And the meeting should always include someone with user-interaction know-how. If you don't have any experts around, grab the person with the most earnest level of interest in the subject and give him or her ownership of the role (people tend to step up to even extreme responsibility when given ownership).
During this metting, at least one programmer, one designer, and one user should be present. While this sounds like the ever-ineffective "seat at the table" approach, it generally offers exactly what is needed for the purpose: a representative user (usually an interal employee) to talk about what he or she needs and wants, a designer to interpet those needs and make suggestions about possible solutions, and a programmer to map out the feasibility of the suggestions and quietly begin devising a coding plan.
The result of such a meeting may or may not involve assigning the task of creating wireframes for the new interaction. Wireframes are preferable, but when there's no time to wireframe, at least the programmers will have a good idea of what to build and how it should behave prior to making impulsive decisions that lead to more bad software. Believe me, folks, this is the bare minimum of what should be done, but is significantly better than doing no design work at all. This way, at least more than one person has been involved in the decision process, and at least one of them is a real-live user.
Whenever possible, a resident expert on interaction design should be present (whoever might be the best person you can get), so he or she can make educated suggestions about how to make the particular piece of software more usable, more flowing and intuitive, and more likely to help users achieve their goals. In a worst-case scenario, where no interaction gurus are available, you should at least have a graphic designer in the conversation, so that an improved look stands a chance of improving the interaction. Again, this is in a worst-case scenario. Your company should always have in its employ someone who has done extensive research on how people actually use computers so he or she can make educated suggestions about how to improve the experience.
JIT design should not have to exist, as Interaction Design should always occur prior to building anything an end-user will touch, but since interaction design is currently ignored in entirely too many situations, JIT design is the best one can hope for, and the best attempt at a remedy before things get too out of hand and you end up with software loaded with features that make users feel stupid by neglecting their needs and wants.
A user who has his goals ignored is a user who will never be a true fan of your software, and true fans are the best thing a company can possibly acquire. If you cannot include quality interaction design as part of your process, you must, at the very minimum, allow JIT design to run interference between stakeholders and programmers. With modern computing quickly becoming as ubiquitous as sliced bread, it's a moral imperative.
"Remember the Milk" registration form goes right and wrong
Robert | @ 10:32 AM
Permalink | 0 Comments
Remember the Milk, a to-do list tool, has a very intersting registration form that gets some things right and other things equally wrong.
On the positive side, it provides immediate feedback in the form of little checkmark icons to let you know whether a field has been correctly completed as soon as it loses focus. This is very nice, because it means I won't see any error messages after clicking the Signup button, instead seeing positive feedback all along the way. On the downside, however, it also offers negative feedback as soon as an input field gains focus. As in, I tab to the email address field, and because it's empty at first, I see an error message telling me that the email address is invalid. (Thought bubble: "How can my email address be invalid if I haven't yet entered one?")
Again on the plus side, the form tells me immediately whether my preferred username is available for use via a message to the right of the input field. But then it asks me to confirm my password, which is something I never want to do. I entered it once already - please don't ask me to do it again.
For everything the form does well, it does another thing ... not so well. Remember the Milk is definitely on the right track, and I like the checkmark icons so much that I might steal the idea and use it myself, so I have great confidence that they could make a few adjustments and produce a really smooth registration process. But for now, the experience is askew just enough to make it an interesting topic for Inc Blots.
Permalink | 0 Comments
Remember the Milk, a to-do list tool, has a very intersting registration form that gets some things right and other things equally wrong.
On the positive side, it provides immediate feedback in the form of little checkmark icons to let you know whether a field has been correctly completed as soon as it loses focus. This is very nice, because it means I won't see any error messages after clicking the Signup button, instead seeing positive feedback all along the way. On the downside, however, it also offers negative feedback as soon as an input field gains focus. As in, I tab to the email address field, and because it's empty at first, I see an error message telling me that the email address is invalid. (Thought bubble: "How can my email address be invalid if I haven't yet entered one?")
Again on the plus side, the form tells me immediately whether my preferred username is available for use via a message to the right of the input field. But then it asks me to confirm my password, which is something I never want to do. I entered it once already - please don't ask me to do it again.
For everything the form does well, it does another thing ... not so well. Remember the Milk is definitely on the right track, and I like the checkmark icons so much that I might steal the idea and use it myself, so I have great confidence that they could make a few adjustments and produce a really smooth registration process. But for now, the experience is askew just enough to make it an interesting topic for Inc Blots.
Not gone - just busy
Robert | 12.20.2005 @ 11:47 AM
Permalink | 0 Comments
This is just a quick note to let you know we haven't disappeared. We've just been really busy. We'll pick things up on the blog, and Dashboard HQ, again soon.
Permalink | 0 Comments
This is just a quick note to let you know we haven't disappeared. We've just been really busy. We'll pick things up on the blog, and Dashboard HQ, again soon.
Wanted by the Police: A Good Interface
Robert | 12.09.2005 @ 12:44 PM
Permalink | 0 Comments
The NY Times reports that the police force in San Jose, CA, is in somewhat desparate need of some quality interaction design. According to the article:
"Since June, the police department has been using a new mobile dispatch system that includes a Windows-based touch-screen computer in every patrol car. But officers have said the system is so complex and difficult to use that it is jeopardizing their ability to do their jobs."
As a result:
"'Do you think if you're hunkered down and someone's shooting at you in your car, you're going to be able to sit there and look for Control or Alt or Function?' said Sgt. Don DeMers, president of the San Jose Police Officers' Association, the local union and the most vocal opponent of the new system. 'No, you're going to look for the red button.'"
If your boss ever wonders why interaction design is a necessary part of the software design process, show him or her this article.
Permalink | 0 Comments
The NY Times reports that the police force in San Jose, CA, is in somewhat desparate need of some quality interaction design. According to the article:
"Since June, the police department has been using a new mobile dispatch system that includes a Windows-based touch-screen computer in every patrol car. But officers have said the system is so complex and difficult to use that it is jeopardizing their ability to do their jobs."
As a result:
"'Do you think if you're hunkered down and someone's shooting at you in your car, you're going to be able to sit there and look for Control or Alt or Function?' said Sgt. Don DeMers, president of the San Jose Police Officers' Association, the local union and the most vocal opponent of the new system. 'No, you're going to look for the red button.'"
If your boss ever wonders why interaction design is a necessary part of the software design process, show him or her this article.
London Underground map based on time instead of distance
Robert | 12.07.2005 @ 12:09 PM
Permalink | 0 Comments
Oskar Karlin had a really great idea while attempting to redesign the map of the London Underground as a final project in college. Instead of focusing on distance in the map's redesign, he would focus on what's most important to travellers: time. The map illustrates how long it will take (on average) to get from point A to point B. The result is an excellent example of a little user-centered thought can send you in a completely new direction than where you started, and produce something that transcends the norm to become more personal, smart, and useful.
This map is focused entirely on the people using it. And that, of course, is exactly where a map should be focused.
Get the details on the map redesign here.
Permalink | 0 Comments
Oskar Karlin had a really great idea while attempting to redesign the map of the London Underground as a final project in college. Instead of focusing on distance in the map's redesign, he would focus on what's most important to travellers: time. The map illustrates how long it will take (on average) to get from point A to point B. The result is an excellent example of a little user-centered thought can send you in a completely new direction than where you started, and produce something that transcends the norm to become more personal, smart, and useful.
This map is focused entirely on the people using it. And that, of course, is exactly where a map should be focused.
Get the details on the map redesign here.
Flash User Experience Best Practices (Lynda.com)
Robert | 12.05.2005 @ 6:37 PM
Permalink | 0 Comments
In an attempt to put my reputation where my mouth is, my movie-based training course from Lynda.com, titled Flash User Experince Best Practices, is now available.
It covers things like how to get the Back button working, create effective forms, implement powerful Flash detection with useful alternate content, and many other great topics. And hopefully, it helps demonstrate that I do, in fact, know what I'm talking about. (Hopefully.)
On an unrelated note, I found out today that my book, Flash Out of the Box, is now available in French. So ... you know ... if you happen to speak French, you could ... you know ... pick up a copy.
Permalink | 0 Comments
In an attempt to put my reputation where my mouth is, my movie-based training course from Lynda.com, titled Flash User Experince Best Practices, is now available.
It covers things like how to get the Back button working, create effective forms, implement powerful Flash detection with useful alternate content, and many other great topics. And hopefully, it helps demonstrate that I do, in fact, know what I'm talking about. (Hopefully.)
On an unrelated note, I found out today that my book, Flash Out of the Box, is now available in French. So ... you know ... if you happen to speak French, you could ... you know ... pick up a copy.
The book I can't read
Robert | 12.03.2005 @ 10:46 PM
Permalink | 0 Comments
I bought an eBook the other day from Amazon, and since then, I've had nothing but trouble trying to read it. Acrobat Reader is the only application that will open it, but it needs to be activated in order to open the PDF eBook, and for about an hour last night, I couldn't activate it to save my life. I guess I got lucky the first time I opened it - it only took twenty minutes. Last night, however, Acrobat simply wouldn't activate, even though I thought I had done it already - afterall, I was able to open the eBook previously.
So why was it so difficult? Well, Adobe has a complicated sequence of steps in place to activate the software. Trying to open the eBook for the first time sends you to the Adobe web site, to a page about activating the application. This page downloads a small file, which apparently is supposed to make everything work. I ran the file. I think it's supposed to launch Acrobat and activate it, allowing me to read my eBook. But it didn't work. In fact, nothing I tried worked. Eventually, I realized, quite by accident, that Acrobat cannot be open when you run the file from Adobe's site. Why? because the file has to launch it in order for the process to begin.
Once the software is activated, you have to wait about five more minutes for the book to download (again, I had done this once before) and finally open. Then, of course, you have to find the page you were on before quitting the application the last time.
So why was it so difficult? Heck if I know.
I've left Acrobat open since last night. I'm afraid to quit the application, as I may never see the eBook again.
This is one case where technology failed miserably. If I had a printed book in my hands, I'd be able to open it at will and freely flip through it. With the eBook, which is supposed to free me from the supposed constraints of print, I wasted an hour just trying to open it. I have to read it on my computer screen, and I can't even print it.
I ordered the hardcopy from Amazon earlier this evening. It should be here on Tuesday. So much for the promise of digital media.
Permalink | 0 Comments
I bought an eBook the other day from Amazon, and since then, I've had nothing but trouble trying to read it. Acrobat Reader is the only application that will open it, but it needs to be activated in order to open the PDF eBook, and for about an hour last night, I couldn't activate it to save my life. I guess I got lucky the first time I opened it - it only took twenty minutes. Last night, however, Acrobat simply wouldn't activate, even though I thought I had done it already - afterall, I was able to open the eBook previously.
So why was it so difficult? Well, Adobe has a complicated sequence of steps in place to activate the software. Trying to open the eBook for the first time sends you to the Adobe web site, to a page about activating the application. This page downloads a small file, which apparently is supposed to make everything work. I ran the file. I think it's supposed to launch Acrobat and activate it, allowing me to read my eBook. But it didn't work. In fact, nothing I tried worked. Eventually, I realized, quite by accident, that Acrobat cannot be open when you run the file from Adobe's site. Why? because the file has to launch it in order for the process to begin.
Once the software is activated, you have to wait about five more minutes for the book to download (again, I had done this once before) and finally open. Then, of course, you have to find the page you were on before quitting the application the last time.
So why was it so difficult? Heck if I know.
I've left Acrobat open since last night. I'm afraid to quit the application, as I may never see the eBook again.
This is one case where technology failed miserably. If I had a printed book in my hands, I'd be able to open it at will and freely flip through it. With the eBook, which is supposed to free me from the supposed constraints of print, I wasted an hour just trying to open it. I have to read it on my computer screen, and I can't even print it.
I ordered the hardcopy from Amazon earlier this evening. It should be here on Tuesday. So much for the promise of digital media.
Odeo goes simple, and only insults us a little
Robert | 12.02.2005 @ 4:00 PM
Permalink | 0 Comments
Odeo has a new, simpler face, which is great, but they seem to think that when it comes to forms, big equals easy.
This is something I've noticed with quite a few Web 2.0 ventures recently. I'm all for cleaning up, stripping down, and otherwise simplifying the user-experience, but how does that translate to making things bigger? Nothing about this contact form is simpler than others like it. If anything, it makes me wish I was far-sighted.
It's kind of insulting. It's like when people talk louder to someone who doesn't speak the local native language, hoping that the increased volume will improve understanding. To the contrary, using this giant form just makes me feel stupid. Odea apparently thinks I'm an idiot, and making the registration form really big will help me wrap my little brain around how to use it.
I'm sure this isn't their intention. But this is how it looks.
Permalink | 0 Comments
Odeo has a new, simpler face, which is great, but they seem to think that when it comes to forms, big equals easy.
This is something I've noticed with quite a few Web 2.0 ventures recently. I'm all for cleaning up, stripping down, and otherwise simplifying the user-experience, but how does that translate to making things bigger? Nothing about this contact form is simpler than others like it. If anything, it makes me wish I was far-sighted.
It's kind of insulting. It's like when people talk louder to someone who doesn't speak the local native language, hoping that the increased volume will improve understanding. To the contrary, using this giant form just makes me feel stupid. Odea apparently thinks I'm an idiot, and making the registration form really big will help me wrap my little brain around how to use it.
I'm sure this isn't their intention. But this is how it looks.
PeopleSoft not so soft
Robert | @ 3:32 PM
Permalink | 0 Comments
My wife just sent me the following email to relay a conversation she had with some co-workers:
< Person A > was trying to check out the job postings on PeopleSoft, and after problems logging on, searching fruitlessly for the correct links, and eventually getting a timed out message, she complained, "It's not just that it isn't user-friendly, PeopleSoft is actually user-hostile".
< Person B > agreed, "Yeah, they should call it PeopleHard".
Point well made. Does anyone still wonder if interaction design is really important?
Permalink | 0 Comments
My wife just sent me the following email to relay a conversation she had with some co-workers:
< Person A > was trying to check out the job postings on PeopleSoft, and after problems logging on, searching fruitlessly for the correct links, and eventually getting a timed out message, she complained, "It's not just that it isn't user-friendly, PeopleSoft is actually user-hostile".
< Person B > agreed, "Yeah, they should call it PeopleHard".
Point well made. Does anyone still wonder if interaction design is really important?
Use the Tools
Manage bookmarks in lists- Create custom content
- Keep it all as your homepage