7 ms·

In Praise of Theory in Design Research: How Levi-Strauss Redefined Workflow

81 points by kawera 9y ago

mehrdadn 9y ago
I'm still stuck on why they can't measure jeans: https://imgur.com/a/866aO https://imgur.com/a/866aO
- deerpig 9y ago
  In case you weren't being snarky, the article was talking about Claude Levi-Strauss who was a French Anthropologist, not not the maker of jeans... https://en.wikipedia.org/wiki/Claude_L%C3%A9vi-Strauss https://en.wikipedia.org/wiki/Claude_L%C3%A9vi-Strauss
lifeisstillgood 9y ago
Can anyone explain this? I kinda missed the point - "people doing a job only use the tools at hand, but engineers can not do the job and go off and build a better tool?"
- kbenson 9y ago
  People don't generally use optimized workflows for each thing they want to do. They use a subset of all well known and understood tools combined in obvious ways to construct their own workflows, and because they are built out of things they understand they are robust and flexible. A workflow designed by an engineer optimizes for some combination of time, resources, cost, etc. Most people don't want something that optimized as it is very brittle to change, so their own ad-hoc workflows are "better". At least for general users that don't have a very small selective set of tasks.
- Pamar 9y ago
  I suppose that the idea is that a bricoleur jury-riggs solution with whatever is at hand while an engineer specializes in “the design and manufacture of complex products.” McGyver is a bricoleur - same goes for the vehicle building parts of an A-Team episode. Tony Stark is an Engineer. Of course an Engineer can probably also work with make-shift conponents in an emergency, but it is not their preferred situation.
- js8 9y ago
  As I understand it, they point out that Levy-Strauss discovered two kinds of approach to solve problems, engineering and bricolage. The former is careful planning and solving the task by building an exact tool that resolves the problem, the latter is putting together whatever you have available in an approximate solution and moving on. In software, we would probably call them "software engineering" and "hacking" approaches. For example, in the Linux Kernel init discussion, systemd is an engineering solution, while traditional init system is a bricolage solution.
  - Pamar 9y ago
    Also, as someone else noted in a comment to the sane article months ago (yep, it’s a dupe) the Unix set of single-task CLI utilities (sed, grep etc.) encourage a bricoleur approach at solving problems without having to write a throwaway application (or extend an existing one) every time.
    - tebruno99 9y ago
      This is only if you hold them as individual items outside the context of the system. These utilities are an engineered solution as a whole. Look how they work together and interact with one another. If you break an engineered system down into its components and never consider all the ideas and fabric that link them together in an engineered system, you could reduce anything to bricoleur.
      - js8 9y ago
        > If you break an engineered system down into its components.. I disagree. Yes, Unix is deliberately engineered to allow for bricolage. But many (most) things aren't. Take for example classic PC and the iPhone. You cannot break down iPhone to it's components and remix them. You could do that with a PC, to some extent.
- anvandare 9y ago
  When faced with a problem, we use the tools we already have and know to deal with it, this is Bricolage. Engineering then (when seen as anything not-bricolage) is the creation (or modification) of new tools to solve a problem. Bricoler is improvisation, adaptation, and creativity with a constricted set of materials and methods. Engineering is changing the set itself. When you're on your back in the data-center in a tight spot trying to unscrew something but you don't happen to have a screwdriver, bricolage would be to use a knife-tip instead because that's just what you happen to have and can make do with. Engineering would be to crawl back out, head out to the store, find the proper screwdriver, buy it, come back, and crawl back down to unscrew it. In a software sense: most people solve their problem of the moment (extracting data from a bunch of files) using bash, cat, grep, sed, and some quick regex editing in their favorite editor, copy-pasting as they go, etc. They're going to write a specific program for just this one particular problem. (This is related to whether it's worth the time [https://xkcd.com/1205/ https://xkcd.com/1205/ ]). Or the stereotypical Grandma who sends a favorite picture by downloading it, inserting it into a Word document, printing that, scanning it, and then clicking on the "send via e-mail" button in the program, and looking up your e-mail address in her (physical) notebook.
js8 9y ago
Very interesting insight. I wish we made more allowance for bricolage in software. There are some great systems that enable bricolage, like Lisp or Unix or Emacs or Forth or Excel. They are toolboxes that you can use to cobble together some solution, perhaps not the best engineering solution, but it's quick and solves the problem. Today, it seems, bricolage is out of fashion. All applications (and all devices in fact) must be made to be "perfect" and "easy to use", not to be combined and remixed as pieces of some "erector set".
- Pamar 9y ago
  I would add OSX Automator to your list. Is there anything similar fir Windows, btw?
  - L0stLink 9y ago
    'Task Scheduler' perhaps?
  - maxerickson 9y ago
    There's third party tools that are at least similar. AutoIt and AutoHotkey are two that are popular. To a significant extent they expose built in apis to a basic style language. There's various programming language libraries that do similar for other languages.
  - nikofeyn 9y ago
    automator is really cool. i haven't used it for years, as i don't really use a mac for anything other than browsing the web these days. on windows, it seems someone could build an automator-like app pretty easily using the powershell api.
- SuperPaintMan 9y ago
  The Share pane in iOS actually does a decent job of this in a roundabout way. Forever and a year ago I had to edit some photos and lay text on them. From the Camera Roll I was able to share it to another app and each of these apps did one little thing like change levels, apply filters, overlay text, cropping/aspect warping. But because each of these apps allowed me to use the share pane they could be chained together without storing it on the device in some intermediate form. The first time I used it it clicked. It was just like pipes but for data types.
thisisit 9y ago
The interesting question will be how do users arrive at individual piece of the bricolage? If we look at the "save mobile content for later" example, I am sure once upon a time people felt it to be easier to simply copy the link, open the email client and then email -- instead of using the "share" button. That said I am also kind of lost on the conclusion here. > Using theory to support our research findings allowed the team to gain a greater sense of self-awareness into their assumptions and how others without those assumptions might think and behave differently. While insights are fine, without concrete examples, this is just a hypothetical whether this really helped the engineering team.
rapnie 9y ago
this is a very insightful article! i have worked quite a bit with bpms'es, apache camel and such and experienced the inflexibility, brittleness myself.. so any larger application can become very easily 'overengineered' and of less value to the bricoleur. there are some good examples of bricolage systems mentioned here, like unix shell commands etc. but in a more application design-specific context targeted to 'normal' (non-technical) users i was wondering if flow-based programming (e.g. noflojs.org) could offer a better balance between well-engineered small (maybe even tiny) building blocks and bricolaging them based on personal preferences (e.g. visually) to bigger, useful apps. flow-based programming had a good uptake initially, but i'm not hearing much about it of late.. any opinions or experiences?
timdellinger 9y ago
"It was clear that our research participants were not using and not seeking out specialized tools tailored to accomplish their specific goals. Why?" While the Levi-Strauss explanation is attractive, there are other factors as well. The author seem to think that a kludge of things such as email, ms word, and screenshots is an inferior workflow, but it has virtues as well. Those tools are stable and reliable and have been around for 20 years, and can be expected to be around for 20 more. Nothing about them is going to fundamentally change, and the user can expect that everything about them is controllable by the user, and they they'll appear on any new platform that might emerge (smart phone, tablet) essentially unchanged. Contrast this with something that the author sees as a better solution, say, Instapaper. It began as a paid app, then it was free but with a Pro version, then it was subscription-based... the whole situation just seems volatile - it could disappear tomorrow, and it stores the data god-only-knows-where. If you happened to go with Readability or Evernote Clearly then now you're back to square one and have to figure this stupid crap out all over again. There are a lots of users who value stability and reliability over small efficiency gains, and who don't enjoy spending time navigating ever-changing marketplaces.
- moz-ur 9y ago
  Author here. Perhaps we could be clearer in the piece about this, but there is no value judgement attached to our participants' workflows. On the contrary, we often marveled at how resourceful and clever many of our participants were in solving their tasks with technology.
  - pacificleo11 9y ago
    Good to be talking to you. Thanks for intresting post. I am wondering if you have studied "juggad" philosophy in india. We practice bricoleurs in every sphere of life.
    - moz-ur 9y ago
      I have read about juggad! But I haven't studied it closely so my knowledge of the details is limited.
reidacdc 9y ago
I think this is pretty insightful. I have some recent experience deploying web-based administrative tools in my organization, which are meant to replace and supersede legacy, often informal, workflows. Adoption rates are low and frustration among users is high, and my efforts at understanding this has focused on missing elements in the new workflows -- it seemed likely that, in formalizing the workflow in order to implement it computationally, we missed something, or got the order wrong. The unexamined assumption here is that there exists a correct, usable formal workflow, and that our task is just to find it and code it up, and then users will engage and frustration will recede. But, as the article suggests, this may not be the case. If users are frustrated by the inability to use familiar tools, and to comprehend and execute the sub-parts of the workflow, then no "all-up" integrated workflow will ever feel right to them. Somewhat embarrassingly, the "bricolage" approach also reflects the Unix philosophy, of which I am very fond -- users should be given a suite of powerful, comprehensible tools with narrow and very clear operational scopes, out of which they should build their own solutions.
- scottLobster 9y ago
  I can't speak for your work, but in my experience most web-based administrative tools are often poorly implemented by the company using them, no matter how good the design. Quite often they're designed for corporate efficiency and not worker usability (ex: This framework has a shitty interface but generates nice looking reports! We're going with that one!), leading to frustration to those on the ground. A good example is my company's Mantis ticket usage. There's nothing wrong with Mantis, but if I file a ticket odds are it will never get looked at for hours or days, whereas if I walk over to our DevOps team and make the request person-to-person it will often get addressed immediately. It's also worth noting that it's less effort to just have a conversation with someone vs filling out a Mantis ticket which then has to be filed/processed/marked as done, etc. The ticketing system actually adds unnecessary overhead in our context. If all formal workflows were as reliable as, say, Amazon shopping and customer service, I think we'd see mass adoption after some initial resistance. I have no knowledge of the organization you work for, but I'd look for problems in execution before seriously questioning the design. Most corporate leadership types consider (wrongly IMO) infrastructure to be a cost center, and that attitude tends to trickle down no matter how good the design.
pacificleo11 9y ago
In India we call bricoleurs as "juggad" and people have overused this idea and made it excuse for not thinking through. Championing this idea is a slippery slope
pasbesoin 9y ago
Edit: My bad. More coffee, less impulse. Apology. This (the OP) may be insightful, but my first reaction is within the context of my ceasing to purchase Levi-Strauss products, because: First and primarily, they started wearing out very quickly -- I'm hardly the only one to have noticed this; and secondly, their unit size variations went way out of control -- e.g. taking 10 or more identical units into a dressing room, to find 3 or 4 that actually fit well, or at all. Their office processes may have developed to some super-natural level. But I'm still not buying their actual products. I mention this, because I run across it repeatedly, these days. All sort of internal "efficiencies and improvements", but no corresponding improvement in the actual product. Towards the more dark pattern end, materials scientists and engineers closing in a particular lifespan to maximize revenue. It may be a very sophisticated process, but as the consumer, it's not doing me any good -- as I see it.
- kawera 9y ago
  The author was referring to Claude Lévi-Strauss, a french anthropologist: https://en.wikipedia.org/wiki/Claude_L%C3%A9vi-Strauss https://en.wikipedia.org/wiki/Claude_L%C3%A9vi-Strauss.
  - pasbesoin 9y ago
    My bad. More coffee, less impulse. Apology.

81 points by kawera 9y ago

mehrdadn 9y ago

I'm still stuck on why they can't measure jeans: https://imgur.com/a/866aO https://imgur.com/a/866aO

deerpig 9y ago
In case you weren't being snarky, the article was talking about Claude Levi-Strauss who was a French Anthropologist, not not the maker of jeans... https://en.wikipedia.org/wiki/Claude_L%C3%A9vi-Strauss https://en.wikipedia.org/wiki/Claude_L%C3%A9vi-Strauss

lifeisstillgood 9y ago

Can anyone explain this? I kinda missed the point - "people doing a job only use the tools at hand, but engineers can not do the job and go off and build a better tool?"

kbenson 9y ago
People don't generally use optimized workflows for each thing they want to do. They use a subset of all well known and understood tools combined in obvious ways to construct their own workflows, and because they are built out of things they understand they are robust and flexible. A workflow designed by an engineer optimizes for some combination of time, resources, cost, etc. Most people don't want something that optimized as it is very brittle to change, so their own ad-hoc workflows are "better". At least for general users that don't have a very small selective set of tasks.
Pamar 9y ago
I suppose that the idea is that a bricoleur jury-riggs solution with whatever is at hand while an engineer specializes in “the design and manufacture of complex products.” McGyver is a bricoleur - same goes for the vehicle building parts of an A-Team episode. Tony Stark is an Engineer. Of course an Engineer can probably also work with make-shift conponents in an emergency, but it is not their preferred situation.
js8 9y ago
As I understand it, they point out that Levy-Strauss discovered two kinds of approach to solve problems, engineering and bricolage. The former is careful planning and solving the task by building an exact tool that resolves the problem, the latter is putting together whatever you have available in an approximate solution and moving on. In software, we would probably call them "software engineering" and "hacking" approaches. For example, in the Linux Kernel init discussion, systemd is an engineering solution, while traditional init system is a bricolage solution.
- Pamar 9y ago
  Also, as someone else noted in a comment to the sane article months ago (yep, it’s a dupe) the Unix set of single-task CLI utilities (sed, grep etc.) encourage a bricoleur approach at solving problems without having to write a throwaway application (or extend an existing one) every time.
  - tebruno99 9y ago
    This is only if you hold them as individual items outside the context of the system. These utilities are an engineered solution as a whole. Look how they work together and interact with one another. If you break an engineered system down into its components and never consider all the ideas and fabric that link them together in an engineered system, you could reduce anything to bricoleur.
    - js8 9y ago
      > If you break an engineered system down into its components.. I disagree. Yes, Unix is deliberately engineered to allow for bricolage. But many (most) things aren't. Take for example classic PC and the iPhone. You cannot break down iPhone to it's components and remix them. You could do that with a PC, to some extent.
anvandare 9y ago
When faced with a problem, we use the tools we already have and know to deal with it, this is Bricolage. Engineering then (when seen as anything not-bricolage) is the creation (or modification) of new tools to solve a problem. Bricoler is improvisation, adaptation, and creativity with a constricted set of materials and methods. Engineering is changing the set itself. When you're on your back in the data-center in a tight spot trying to unscrew something but you don't happen to have a screwdriver, bricolage would be to use a knife-tip instead because that's just what you happen to have and can make do with. Engineering would be to crawl back out, head out to the store, find the proper screwdriver, buy it, come back, and crawl back down to unscrew it. In a software sense: most people solve their problem of the moment (extracting data from a bunch of files) using bash, cat, grep, sed, and some quick regex editing in their favorite editor, copy-pasting as they go, etc. They're going to write a specific program for just this one particular problem. (This is related to whether it's worth the time [https://xkcd.com/1205/ https://xkcd.com/1205/ ]). Or the stereotypical Grandma who sends a favorite picture by downloading it, inserting it into a Word document, printing that, scanning it, and then clicking on the "send via e-mail" button in the program, and looking up your e-mail address in her (physical) notebook.

js8 9y ago

Very interesting insight. I wish we made more allowance for bricolage in software. There are some great systems that enable bricolage, like Lisp or Unix or Emacs or Forth or Excel. They are toolboxes that you can use to cobble together some solution, perhaps not the best engineering solution, but it's quick and solves the problem. Today, it seems, bricolage is out of fashion. All applications (and all devices in fact) must be made to be "perfect" and "easy to use", not to be combined and remixed as pieces of some "erector set".

Pamar 9y ago
I would add OSX Automator to your list. Is there anything similar fir Windows, btw?
- L0stLink 9y ago
  'Task Scheduler' perhaps?
- maxerickson 9y ago
  There's third party tools that are at least similar. AutoIt and AutoHotkey are two that are popular. To a significant extent they expose built in apis to a basic style language. There's various programming language libraries that do similar for other languages.
- nikofeyn 9y ago
  automator is really cool. i haven't used it for years, as i don't really use a mac for anything other than browsing the web these days. on windows, it seems someone could build an automator-like app pretty easily using the powershell api.
SuperPaintMan 9y ago
The Share pane in iOS actually does a decent job of this in a roundabout way. Forever and a year ago I had to edit some photos and lay text on them. From the Camera Roll I was able to share it to another app and each of these apps did one little thing like change levels, apply filters, overlay text, cropping/aspect warping. But because each of these apps allowed me to use the share pane they could be chained together without storing it on the device in some intermediate form. The first time I used it it clicked. It was just like pipes but for data types.

thisisit 9y ago

The interesting question will be how do users arrive at individual piece of the bricolage? If we look at the "save mobile content for later" example, I am sure once upon a time people felt it to be easier to simply copy the link, open the email client and then email -- instead of using the "share" button. That said I am also kind of lost on the conclusion here. > Using theory to support our research findings allowed the team to gain a greater sense of self-awareness into their assumptions and how others without those assumptions might think and behave differently. While insights are fine, without concrete examples, this is just a hypothetical whether this really helped the engineering team.

rapnie 9y ago

this is a very insightful article! i have worked quite a bit with bpms'es, apache camel and such and experienced the inflexibility, brittleness myself.. so any larger application can become very easily 'overengineered' and of less value to the bricoleur. there are some good examples of bricolage systems mentioned here, like unix shell commands etc. but in a more application design-specific context targeted to 'normal' (non-technical) users i was wondering if flow-based programming (e.g. noflojs.org) could offer a better balance between well-engineered small (maybe even tiny) building blocks and bricolaging them based on personal preferences (e.g. visually) to bigger, useful apps. flow-based programming had a good uptake initially, but i'm not hearing much about it of late.. any opinions or experiences?

timdellinger 9y ago

"It was clear that our research participants were not using and not seeking out specialized tools tailored to accomplish their specific goals. Why?" While the Levi-Strauss explanation is attractive, there are other factors as well. The author seem to think that a kludge of things such as email, ms word, and screenshots is an inferior workflow, but it has virtues as well. Those tools are stable and reliable and have been around for 20 years, and can be expected to be around for 20 more. Nothing about them is going to fundamentally change, and the user can expect that everything about them is controllable by the user, and they they'll appear on any new platform that might emerge (smart phone, tablet) essentially unchanged. Contrast this with something that the author sees as a better solution, say, Instapaper. It began as a paid app, then it was free but with a Pro version, then it was subscription-based... the whole situation just seems volatile - it could disappear tomorrow, and it stores the data god-only-knows-where. If you happened to go with Readability or Evernote Clearly then now you're back to square one and have to figure this stupid crap out all over again. There are a lots of users who value stability and reliability over small efficiency gains, and who don't enjoy spending time navigating ever-changing marketplaces.

moz-ur 9y ago
Author here. Perhaps we could be clearer in the piece about this, but there is no value judgement attached to our participants' workflows. On the contrary, we often marveled at how resourceful and clever many of our participants were in solving their tasks with technology.
- pacificleo11 9y ago
  Good to be talking to you. Thanks for intresting post. I am wondering if you have studied "juggad" philosophy in india. We practice bricoleurs in every sphere of life.
  - moz-ur 9y ago
    I have read about juggad! But I haven't studied it closely so my knowledge of the details is limited.

reidacdc 9y ago

I think this is pretty insightful. I have some recent experience deploying web-based administrative tools in my organization, which are meant to replace and supersede legacy, often informal, workflows. Adoption rates are low and frustration among users is high, and my efforts at understanding this has focused on missing elements in the new workflows -- it seemed likely that, in formalizing the workflow in order to implement it computationally, we missed something, or got the order wrong. The unexamined assumption here is that there exists a correct, usable formal workflow, and that our task is just to find it and code it up, and then users will engage and frustration will recede. But, as the article suggests, this may not be the case. If users are frustrated by the inability to use familiar tools, and to comprehend and execute the sub-parts of the workflow, then no "all-up" integrated workflow will ever feel right to them. Somewhat embarrassingly, the "bricolage" approach also reflects the Unix philosophy, of which I am very fond -- users should be given a suite of powerful, comprehensible tools with narrow and very clear operational scopes, out of which they should build their own solutions.

scottLobster 9y ago
I can't speak for your work, but in my experience most web-based administrative tools are often poorly implemented by the company using them, no matter how good the design. Quite often they're designed for corporate efficiency and not worker usability (ex: This framework has a shitty interface but generates nice looking reports! We're going with that one!), leading to frustration to those on the ground. A good example is my company's Mantis ticket usage. There's nothing wrong with Mantis, but if I file a ticket odds are it will never get looked at for hours or days, whereas if I walk over to our DevOps team and make the request person-to-person it will often get addressed immediately. It's also worth noting that it's less effort to just have a conversation with someone vs filling out a Mantis ticket which then has to be filed/processed/marked as done, etc. The ticketing system actually adds unnecessary overhead in our context. If all formal workflows were as reliable as, say, Amazon shopping and customer service, I think we'd see mass adoption after some initial resistance. I have no knowledge of the organization you work for, but I'd look for problems in execution before seriously questioning the design. Most corporate leadership types consider (wrongly IMO) infrastructure to be a cost center, and that attitude tends to trickle down no matter how good the design.

pacificleo11 9y ago

In India we call bricoleurs as "juggad" and people have overused this idea and made it excuse for not thinking through. Championing this idea is a slippery slope

pasbesoin 9y ago

Edit: My bad. More coffee, less impulse. Apology. This (the OP) may be insightful, but my first reaction is within the context of my ceasing to purchase Levi-Strauss products, because: First and primarily, they started wearing out very quickly -- I'm hardly the only one to have noticed this; and secondly, their unit size variations went way out of control -- e.g. taking 10 or more identical units into a dressing room, to find 3 or 4 that actually fit well, or at all. Their office processes may have developed to some super-natural level. But I'm still not buying their actual products. I mention this, because I run across it repeatedly, these days. All sort of internal "efficiencies and improvements", but no corresponding improvement in the actual product. Towards the more dark pattern end, materials scientists and engineers closing in a particular lifespan to maximize revenue. It may be a very sophisticated process, but as the consumer, it's not doing me any good -- as I see it.

kawera 9y ago
The author was referring to Claude Lévi-Strauss, a french anthropologist: https://en.wikipedia.org/wiki/Claude_L%C3%A9vi-Strauss https://en.wikipedia.org/wiki/Claude_L%C3%A9vi-Strauss.
- pasbesoin 9y ago
  My bad. More coffee, less impulse. Apology.