Ask "What Would the User Do?" (You Are not the User) - Revision history

Kevlin at 15:24, 11 July 2009

2009-07-11T15:24:52Z

←Older revision		Revision as of 15:24, 11 July 2009
Line 3:		Line 3:
	This bias explains why programmers have such a hard time putting themselves in the users' position. Users don't think like programmers. For a start, they spend much less time using computers. They neither know nor care how a computer works. This means they can't draw on any of the battery of problem-solving techniques so familiar to programmers. They don't recognize the patterns and cues programmers use to work with, through, and around an interface.		This bias explains why programmers have such a hard time putting themselves in the users' position. Users don't think like programmers. For a start, they spend much less time using computers. They neither know nor care how a computer works. This means they can't draw on any of the battery of problem-solving techniques so familiar to programmers. They don't recognize the patterns and cues programmers use to work with, through, and around an interface.

-	The best way to find out how users think is to watch one. Ask a user to complete a task using a similar piece of software to what you're developing. Make sure the task is a real one: "Add up a column of numbers" is OK; "Calculate your expenses for the last month" is better. Avoid tasks that are too specific, such as "Can you select these spreadsheet cells and enter a ''SUM'' formula below?" — there's a big clue in that question. Get the user to talk through his or her progress. Don't interrupt. Don't try to help. Keep asking yourself "Why is he doing that?" and "Why is she not doing that?".	+	The best way to find out how users think is to watch one. Ask a user to complete a task using a similar piece of software to what you're developing. Make sure the task is a real one: "Add up a column of numbers" is OK; "Calculate your expenses for the last month" is better. Avoid tasks that are too specific, such as "Can you select these spreadsheet cells and enter a ''SUM'' formula below?" — there's a big clue in that question. Get the user to talk through his or her progress. Don't interrupt. Don't try to help. Keep asking yourself "Why is he doing that?" and "Why is she not doing that?"

	The first thing you'll notice is that users do a core of things similarly. They try to complete tasks in the same order — and they make the same mistakes in the same places. You should design around that core behavior. This is different from design meetings, where people tend to be listened to for saying "What if the user wants to...?" This leads to elaborate features and confusion over what users want. Watching users eliminates this confusion.		The first thing you'll notice is that users do a core of things similarly. They try to complete tasks in the same order — and they make the same mistakes in the same places. You should design around that core behavior. This is different from design meetings, where people tend to be listened to for saying "What if the user wants to...?" This leads to elaborate features and confusion over what users want. Watching users eliminates this confusion.

Kevlin at 15:24, 11 July 2009

2009-07-11T15:24:39Z

←Older revision		Revision as of 15:24, 11 July 2009
Line 3:		Line 3:
	This bias explains why programmers have such a hard time putting themselves in the users' position. Users don't think like programmers. For a start, they spend much less time using computers. They neither know nor care how a computer works. This means they can't draw on any of the battery of problem-solving techniques so familiar to programmers. They don't recognize the patterns and cues programmers use to work with, through, and around an interface.		This bias explains why programmers have such a hard time putting themselves in the users' position. Users don't think like programmers. For a start, they spend much less time using computers. They neither know nor care how a computer works. This means they can't draw on any of the battery of problem-solving techniques so familiar to programmers. They don't recognize the patterns and cues programmers use to work with, through, and around an interface.

-	The best way to find out how users think is to watch one. Ask a user to complete a task using a similar piece of software to what you're developing. Make sure the task is a real one: "Add up a column of numbers" is OK; "Calculate your expenses for the last month" is better. Avoid tasks that are too specific, such as "Can you select these spreadsheet cells and enter a ''SUM'' formula below?" — there's a big clue in that question. Get the user to talk through his or her progress. Don't interrupt. Don't try to help. Keep asking yourself "Why is ~~the user~~ doing that?" and "Why is he not doing that?".	+	The best way to find out how users think is to watch one. Ask a user to complete a task using a similar piece of software to what you're developing. Make sure the task is a real one: "Add up a column of numbers" is OK; "Calculate your expenses for the last month" is better. Avoid tasks that are too specific, such as "Can you select these spreadsheet cells and enter a ''SUM'' formula below?" — there's a big clue in that question. Get the user to talk through his or her progress. Don't interrupt. Don't try to help. Keep asking yourself "Why is he doing that?" and "Why is she not doing that?".

	The first thing you'll notice is that users do a core of things similarly. They try to complete tasks in the same order — and they make the same mistakes in the same places. You should design around that core behavior. This is different from design meetings, where people tend to be listened to for saying "What if the user wants to...?" This leads to elaborate features and confusion over what users want. Watching users eliminates this confusion.		The first thing you'll notice is that users do a core of things similarly. They try to complete tasks in the same order — and they make the same mistakes in the same places. You should design around that core behavior. This is different from design meetings, where people tend to be listened to for saying "What if the user wants to...?" This leads to elaborate features and confusion over what users want. Watching users eliminates this confusion.

Giles.colborne at 15:04, 11 July 2009

2009-07-11T15:04:22Z

←Older revision		Revision as of 15:04, 11 July 2009
Line 3:		Line 3:
	This bias explains why programmers have such a hard time putting themselves in the users' position. Users don't think like programmers. For a start, they spend much less time using computers. They neither know nor care how a computer works. This means they can't draw on any of the battery of problem-solving techniques so familiar to programmers. They don't recognize the patterns and cues programmers use to work with, through, and around an interface.		This bias explains why programmers have such a hard time putting themselves in the users' position. Users don't think like programmers. For a start, they spend much less time using computers. They neither know nor care how a computer works. This means they can't draw on any of the battery of problem-solving techniques so familiar to programmers. They don't recognize the patterns and cues programmers use to work with, through, and around an interface.

-	The best way to find out how users think is to watch one. Ask a user to complete a task using a similar piece of software to what you're developing. Make sure the task is a real one: "Add up a column of numbers" is OK; "Calculate your expenses for the last month" is better. Avoid tasks that are too specific, such as "Can you select these spreadsheet cells and enter a ''SUM'' formula below?" — there's a big clue in that question. Get the user to talk through his or her progress. Don't interrupt. Don't try to help. ~~And keep~~ asking yourself "Why is he doing that?"	+	The best way to find out how users think is to watch one. Ask a user to complete a task using a similar piece of software to what you're developing. Make sure the task is a real one: "Add up a column of numbers" is OK; "Calculate your expenses for the last month" is better. Avoid tasks that are too specific, such as "Can you select these spreadsheet cells and enter a ''SUM'' formula below?" — there's a big clue in that question. Get the user to talk through his or her progress. Don't interrupt. Don't try to help. Keep asking yourself "Why is the user doing that?" and "Why is he not doing that?".

	The first thing you'll notice is that users do a core of things similarly. They try to complete tasks in the same order — and they make the same mistakes in the same places. You should design around that core behavior. This is different from design meetings, where people tend to be listened to for saying "What if the user wants to...?" This leads to elaborate features and confusion over what users want. Watching users eliminates this confusion.		The first thing you'll notice is that users do a core of things similarly. They try to complete tasks in the same order — and they make the same mistakes in the same places. You should design around that core behavior. This is different from design meetings, where people tend to be listened to for saying "What if the user wants to...?" This leads to elaborate features and confusion over what users want. Watching users eliminates this confusion.

Kevlin at 14:17, 11 July 2009

2009-07-11T14:17:08Z

←Older revision		Revision as of 14:17, 11 July 2009
Line 7:		Line 7:
	The first thing you'll notice is that users do a core of things similarly. They try to complete tasks in the same order — and they make the same mistakes in the same places. You should design around that core behavior. This is different from design meetings, where people tend to be listened to for saying "What if the user wants to...?" This leads to elaborate features and confusion over what users want. Watching users eliminates this confusion.		The first thing you'll notice is that users do a core of things similarly. They try to complete tasks in the same order — and they make the same mistakes in the same places. You should design around that core behavior. This is different from design meetings, where people tend to be listened to for saying "What if the user wants to...?" This leads to elaborate features and confusion over what users want. Watching users eliminates this confusion.

-	You'll see users getting stuck. When you get stuck, you look around. When users get stuck, they narrow their focus. It becomes harder for them to see solutions elsewhere on the screen. It's one reason why help text is a poor solution to poor user interface design.	+	You'll see users getting stuck. When you get stuck, you look around. When users get stuck, they narrow their focus. It becomes harder for them to see solutions elsewhere on the screen. It's one reason why help text is a poor solution to poor user interface design. If you must have instructions or help text, make sure to locate it right next to your problem areas. A user's narrow focus of attention is why tool tips are more useful than help menus.
-		+
-	If you must have instructions or help text, make sure to locate it right next to your problem areas. A user's narrow focus of attention is why tool tips are more useful than help menus.	+

	Users tend to muddle through. They'll find a way that works and stick with it no matter how convoluted. It's better to provide one really obvious way of doing things than two or three short-cuts.		Users tend to muddle through. They'll find a way that works and stick with it no matter how convoluted. It's better to provide one really obvious way of doing things than two or three short-cuts.

Kevlin at 14:15, 11 July 2009

2009-07-11T14:15:43Z

←Older revision		Revision as of 14:15, 11 July 2009
Line 3:		Line 3:
	This bias explains why programmers have such a hard time putting themselves in the users' position. Users don't think like programmers. For a start, they spend much less time using computers. They neither know nor care how a computer works. This means they can't draw on any of the battery of problem-solving techniques so familiar to programmers. They don't recognize the patterns and cues programmers use to work with, through, and around an interface.		This bias explains why programmers have such a hard time putting themselves in the users' position. Users don't think like programmers. For a start, they spend much less time using computers. They neither know nor care how a computer works. This means they can't draw on any of the battery of problem-solving techniques so familiar to programmers. They don't recognize the patterns and cues programmers use to work with, through, and around an interface.

-	The best way to find out how users think is to watch one. Ask ~~him or her~~ to complete a task using a similar piece of software to what you're developing. Make sure the task is a real one: "Add up a column of numbers" is OK; "Calculate your expenses for the last month" is better. Avoid tasks that are too specific, such as "Can you select these spreadsheet cells and enter a ''SUM'' formula below?" — there's a big clue in that question. Get the user to talk through his or her progress. Don't interrupt. Don't try to help. And keep asking yourself "Why is he doing that?"	+	The best way to find out how users think is to watch one. Ask a user to complete a task using a similar piece of software to what you're developing. Make sure the task is a real one: "Add up a column of numbers" is OK; "Calculate your expenses for the last month" is better. Avoid tasks that are too specific, such as "Can you select these spreadsheet cells and enter a ''SUM'' formula below?" — there's a big clue in that question. Get the user to talk through his or her progress. Don't interrupt. Don't try to help. And keep asking yourself "Why is he doing that?"

	The first thing you'll notice is that users do a core of things similarly. They try to complete tasks in the same order — and they make the same mistakes in the same places. You should design around that core behavior. This is different from design meetings, where people tend to be listened to for saying "What if the user wants to...?" This leads to elaborate features and confusion over what users want. Watching users eliminates this confusion.		The first thing you'll notice is that users do a core of things similarly. They try to complete tasks in the same order — and they make the same mistakes in the same places. You should design around that core behavior. This is different from design meetings, where people tend to be listened to for saying "What if the user wants to...?" This leads to elaborate features and confusion over what users want. Watching users eliminates this confusion.

Kevlin: Ask 'what would the user do?' (You are not the user.) moved to Ask "What Would the User Do?" (You Are not the User)

2009-07-11T14:07:09Z

Ask 'what would the user do?' (You are not the user.) moved to Ask "What Would the User Do?" (You Are not the User)

←Older revision

Revision as of 14:07, 11 July 2009

Kevlin at 14:06, 11 July 2009

2009-07-11T14:06:37Z

←Older revision		Revision as of 14:06, 11 July 2009
Line 1:		Line 1:
-	We all tend to assume that ~~all~~ other people think like us (psychologists call this the ~~‘false consensus’~~ bias). If people think or act differently to us, ~~we’re~~ more likely to label them as defective in some way.	+	We all tend to assume that other people think like us (psychologists call this the ''false consensus bias''). If people think or act differently to us, we're more likely to label them as defective in some way.

-	This explains why programmers have such a hard time putting themselves in the ~~users’~~ position. Users ~~don’t~~ think like programmers. For a start they spend much less time using computers. They ~~don’t~~ know or care ~~about~~ how a computer works. This means they ~~don’t have~~ any of the problem solving techniques ~~that~~ programmers ~~know~~. They ~~don’t~~ recognize the patterns and cues ~~that~~ programmers use to ~~get~~ through an interface.	+	This bias explains why programmers have such a hard time putting themselves in the users' position. Users don't think like programmers. For a start, they spend much less time using computers. They neither know nor care how a computer works. This means they can't draw on any of the battery of problem-solving techniques so familiar to programmers. They don't recognize the patterns and cues programmers use to work with, through, and around an interface.

-	The best way to find out how users think is to watch one. Ask him or her to complete a task using a similar piece of software to what ~~you’re~~ developing. Make sure the task is a real one: ~~‘add~~ up a column of ~~numbers’~~ is ~~okay, ‘calculate~~ your expenses for the last ~~month’~~ is better. Avoid tasks that are too specific such as ~~‘can~~ you select these spreadsheet cells and enter a SUM formula below?~~’ - there’s~~ a big clue in that question. Get the user to talk through his or her progress. ~~Don’t~~ interrupt~~, don’t~~ try to help ~~and~~ keep asking yourself ~~‘why~~ is he doing that?’.	+	The best way to find out how users think is to watch one. Ask him or her to complete a task using a similar piece of software to what you're developing. Make sure the task is a real one: "Add up a column of numbers" is OK; "Calculate your expenses for the last month" is better. Avoid tasks that are too specific, such as "Can you select these spreadsheet cells and enter a ''SUM'' formula below?" — there's a big clue in that question. Get the user to talk through his or her progress. Don't interrupt. Don't try to help. And keep asking yourself "Why is he doing that?"

-	The first thing ~~you’ll~~ notice is that users do a core of things similarly. They try to complete tasks in the same order - and make the same mistakes in the same places. You should design around that core behavior.	+	The first thing you'll notice is that users do a core of things similarly. They try to complete tasks in the same order — and they make the same mistakes in the same places. You should design around that core behavior. This is different from design meetings, where people tend to be listened to for saying "What if the user wants to...?" This leads to elaborate features and confusion over what users want. Watching users eliminates this confusion.

-	~~This is different from design meetings~~, ~~where people tend to be listened to~~ for ~~saying ‘what if~~ the ~~user wants to…?’~~. ~~This leads~~ to ~~elaborate features and confusion over what users want. Watching users eliminates this confusion~~.	+	You'll see users getting stuck. When you get stuck, you look around. When users get stuck, they narrow their focus. It becomes harder for them to see solutions elsewhere on the screen. It's one reason why help text is a poor solution to poor user interface design.

-	~~You’ll see users getting stuck. When~~ you ~~get stuck~~, ~~you look around~~. ~~When users get stuck they~~ narrow ~~their~~ focus~~. It becomes harder, for them to see solutions elsewhere on the screen. It’s one reason~~ why help ~~text is a poor solution to bad user interface design~~.	+	If you must have instructions or help text, make sure to locate it right next to your problem areas. A user's narrow focus of attention is why tool tips are more useful than help menus.

-	~~If you must have instructions or help text, make sure~~ to ~~locate~~ it ~~right next to your problem areas~~. ~~User’s narrow focus~~ of ~~attention is why tool tips are more useful~~ than ~~help menus~~.	+	Users tend to muddle through. They'll find a way that works and stick with it no matter how convoluted. It's better to provide one really obvious way of doing things than two or three short-cuts.

-	~~Users tend to muddle through. They’ll~~ find ~~a way~~ that ~~works~~ and ~~stick with it no matter how convoluted~~. ~~It’s better to provide one really obvious~~ way of ~~doing things~~ than ~~two or three short-cuts~~.	+	You'll also find that there's a gap between what users say they want and what they actually do. That's worrying as the normal way of gathering user requirements is to ask them. It's why the best way to capture requirements is to watch users. Spending an hour watching users is more informative than spending a day guessing what users want.

-	~~You’ll also find that there’s~~ a ~~gap between what users say they want and what they actually do~~. ~~That’s worrying as the normal way of gathering user requirements is to ask them~~. ~~It’s why the best way~~ to ~~capture requirements is to watch users. Spending an hour watching users is more informative than spending a day guessing what users want.~~	+	by [[Giles Colborne]]
		+
		+	This work is licensed under a
		+	[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
		+
		+
		+	Back to [[97 Things Every Programmer Should Know]] home page

Giles.colborne at 09:41, 11 July 2009

2009-07-11T09:41:23Z

←Older revision		Revision as of 09:41, 11 July 2009
Line 1:		Line 1:
-	~~You probably love technology - you're always interested in a new piece of kit, you explore software~~ to ~~find hidden functionality, you read~~ the ~~manual~~.	+	We all tend to assume that all other people think like us (psychologists call this the ‘false consensus’ bias). If people think or act differently to us, we’re more likely to label them as defective in some way.

-	~~Most people don't do~~ any of ~~these things~~. ~~So just because something makes sense to you, doesn't mean it will make sense~~ to ~~your user~~.	+	This explains why programmers have such a hard time putting themselves in the users’ position. Users don’t think like programmers. For a start they spend much less time using computers. They don’t know or care about how a computer works. This means they don’t have any of the problem solving techniques that programmers know. They don’t recognize the patterns and cues that programmers use to get through an interface.

-	~~How~~ to think ~~like~~ a ~~user~~	+	The best way to find out how users think is to watch one. Ask him or her to complete a task using a similar piece of software to what you’re developing. Make sure the task is a real one: ‘add up a column of numbers’ is okay, ‘calculate your expenses for the last month’ is better. Avoid tasks that are too specific such as ‘can you select these spreadsheet cells and enter a SUM formula below?’ - there’s a big clue in that question. Get the user to talk through his or her progress. Don’t interrupt, don’t try to help and keep asking yourself ‘why is he doing that?’.
-	~~- Watch~~ a ~~user~~	+
-	~~- Focus on goals, not '~~what ~~if's'~~	+
-	.~~.. explanation~~ of these to ~~be added~~	+

-	~~What~~ users do	+	The first thing you’ll notice is that users do a core of things similarly. They try to complete tasks in the same order - and make the same mistakes in the same places. You should design around that core behavior.
-	- ~~People understand lists~~, ~~not databases~~	+
-	~~- Label actions unambiguously (never use 'OK')~~	+	This is different from design meetings, where people tend to be listened to for saying ‘what if the user wants to…?’. This leads to elaborate features and confusion over what users want. Watching users eliminates this confusion.
-	... ~~list~~ to ~~be added~~	+
		+	You’ll see users getting stuck. When you get stuck, you look around. When users get stuck they narrow their focus. It becomes harder, for them to see solutions elsewhere on the screen. It’s one reason why help text is a poor solution to bad user interface design.
		+
		+	If you must have instructions or help text, make sure to locate it right next to your problem areas. User’s narrow focus of attention is why tool tips are more useful than help menus.
		+
		+	Users tend to muddle through. They’ll find a way that works and stick with it no matter how convoluted. It’s better to provide one really obvious way of doing things than two or three short-cuts.
		+
		+	You’ll also find that there’s a gap between what users say they want and what they actually do. That’s worrying as the normal way of gathering user requirements is to ask them. It’s why the best way to capture requirements is to watch users. Spending an hour watching users is more informative than spending a day guessing what users want.

Giles.colborne: New page: You probably love technology - you're always interested in a new piece of kit, you explore software to find hidden functionality, you read the manual. Most people don't do any of these th...

2008-11-26T13:42:18Z

New page: You probably love technology - you're always interested in a new piece of kit, you explore software to find hidden functionality, you read the manual. Most people don't do any of these th...

New page

You probably love technology - you're always interested in a new piece of kit, you explore software to find hidden functionality, you read the manual.

Most people don't do any of these things. So just because something makes sense to you, doesn't mean it will make sense to your user.

How to think like a user
- Watch a user
- Focus on goals, not 'what if's'
... explanation of these to be added

What users do
- People understand lists, not databases
- Label actions unambiguously (never use 'OK')
... list to be added