Design principles: Difference between revisions
Jump to navigation
Jump to search
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| (11 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{a| | {{a|design|}}In {{Author|Don Norman}}’s terms<ref>{{Br|The Design of Everyday Things}}</ref> design is comprised of [[affordance]]s, [[signifier]]s, [[mapping]] and [[feedback]], a taxonomy of which the design of legal products seems utterly ignorant. | ||
*[[Know your purpose]] | *[[Know your purpose]] | ||
*[[Assume there will be accidents]]: The role of the risk manager is to know where the risks are concentrated, not to be satisfied there are no risks. If your [[RAG status]] has been uniformly green at every [[opco]] for the last ten years you should [[get your coat]]. Because either there ''is no'' [[risk]], so what are you even doing chairing an [[opco]], or you are flat-out delusional, so someone ''else'' is needed. | |||
*[[Design for average people]]: be realistic about your people’s capability: they will be, on average, ''average''. | |||
*[[Iterate]] | |||
*[[Open source]]: don’t seek [[rent]]; especially not on utility material. ''Legal boilerplate is not special sauce''. | |||
*[[Amplify signal, minimise noise]] | *[[Amplify signal, minimise noise]] | ||
*[[Know your client]] ↔ [[Be personal]] | *[[Know your client]] ↔ [[Be personal]] | ||
*[[Have excellent data]] | *[[Have excellent data]] | ||
*[[Automation eliminates value but not risk]] | *[[Automation eliminates value but not risk]] | ||
*[[Solve simple problems]]. Leave the hard stuff to the experts. | *[[Solve simple problems]]. Like [[Blind spot assistance]]. Leave the hard stuff to the experts. | ||
===Antifragile=== | ===[[Pace layering]]=== | ||
*'''Be patient''': Fundamental change comes slowly. Do not make the mistake of trying to change a fundamental/biological level behaviour with the fashionable layer. Biological behaviours are very persistent. | |||
*'''five degrees, not fifty''': A radical, sudden change is much more likely to break, be unsustainable, and create unexpected and unwanted knock-ons and consequences for other parts of your machine. Make gradual changes, and build on them, gradually. | |||
*'''Use your experts''': You have a great, real-world source of knowledge and intelligence about the problems and opportunities in front of you: The people who have those problems and are missing those opportunities. Your current staff. They need to be in the centre of the design process. You can’t leave it to [[management consultant]]s who have no subject matter expertise at all. | |||
*'''[[Change adoption]] is hard''': The real challenge is getting your subject matters to engage. They are more likely to engage: | |||
**Where the changes are immediately, personally, beneficial to them. No-one had a moment’s trouble adapting to the [[Change adoption|BlackBerry]]. | |||
**That require none, or minimal, behavioural change. Everyone knows what they know, and does what they do. | |||
===[[Antifragile]]=== | |||
*[[Be sceptical of models]] ↔ [[Don’t tick boxes]] ↔ watch out for proxies. Don't confuse simplistic models with simplicity. | *[[Be sceptical of models]] ↔ [[Don’t tick boxes]] ↔ watch out for proxies. Don't confuse simplistic models with simplicity. | ||
*[[Decomplicate]] ↔ [[reduce complexity]]: do few things well, rather than everything fairly. | *[[Decomplicate]] ↔ [[reduce complexity]]: do few things well, rather than everything fairly. | ||
*[[Be antifragile]] | *[[Be antifragile]] | ||
{{sa}} | |||
*{{br|The Design of Everyday Things}} | |||
*[[Blind spot assistance]] | |||
{{Ref}} | |||
Latest revision as of 11:14, 13 March 2023
|
The design of organisations and products
|
In Don Norman’s terms[1] design is comprised of affordances, signifiers, mapping and feedback, a taxonomy of which the design of legal products seems utterly ignorant.
- Know your purpose
- Assume there will be accidents: The role of the risk manager is to know where the risks are concentrated, not to be satisfied there are no risks. If your RAG status has been uniformly green at every opco for the last ten years you should get your coat. Because either there is no risk, so what are you even doing chairing an opco, or you are flat-out delusional, so someone else is needed.
- Design for average people: be realistic about your people’s capability: they will be, on average, average.
- Iterate
- Open source: don’t seek rent; especially not on utility material. Legal boilerplate is not special sauce.
- Amplify signal, minimise noise
- Know your client ↔ Be personal
- Have excellent data
- Automation eliminates value but not risk
- Solve simple problems. Like Blind spot assistance. Leave the hard stuff to the experts.
Pace layering
- Be patient: Fundamental change comes slowly. Do not make the mistake of trying to change a fundamental/biological level behaviour with the fashionable layer. Biological behaviours are very persistent.
- five degrees, not fifty: A radical, sudden change is much more likely to break, be unsustainable, and create unexpected and unwanted knock-ons and consequences for other parts of your machine. Make gradual changes, and build on them, gradually.
- Use your experts: You have a great, real-world source of knowledge and intelligence about the problems and opportunities in front of you: The people who have those problems and are missing those opportunities. Your current staff. They need to be in the centre of the design process. You can’t leave it to management consultants who have no subject matter expertise at all.
- Change adoption is hard: The real challenge is getting your subject matters to engage. They are more likely to engage:
- Where the changes are immediately, personally, beneficial to them. No-one had a moment’s trouble adapting to the BlackBerry.
- That require none, or minimal, behavioural change. Everyone knows what they know, and does what they do.
Antifragile
- Be sceptical of models ↔ Don’t tick boxes ↔ watch out for proxies. Don't confuse simplistic models with simplicity.
- Decomplicate ↔ reduce complexity: do few things well, rather than everything fairly.
- Be antifragile