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

https://www.epicpeople.org/theory-in-design-research/

by kawera • 8 years ago

81 33 8 years ago

mehrdadn• 8 years ago

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

deerpig• 8 years 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

lifeisstillgood• 8 years 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?"

js83• 8 years 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.

Pamar3• 8 years 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.

kbenson2• 8 years 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.

Pamar3• 8 years 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.

anvandare• 8 years 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/ ]). 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.

js83• 8 years 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".

Pamar3• 8 years ago

I would add OSX Automator to your list. Is there anything similar fir Windows, btw?

L0stLink• 8 years ago

'Task Scheduler' perhaps?

maxerickson• 8 years 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• 8 years 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• 8 years 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• 8 years 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• 8 years 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• 8 years 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-ur2• 8 years 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.

pacificleo113• 8 years 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.

DoreenMichele2• 8 years ago

If you haven't read it, you might enjoy the book Seeing like a state. Your article reminded me of the material in that book.

https://en.m.wikipedia.org/wiki/Seeing_Like_a_State

kbenson2• 8 years ago

The author seem to think that a kludge of things such as email, ms word, and screenshots is an inferior workflow

I'm not sure where you got that. I didn't get that at all from my reading.

When we went into analysis, a tension appeared between our findings and what we believed was being asked of us to report on. Our original charge was to find ways to improve and optimize users’ browser workflows following software and design-oriented assumptions. Instead, we saw that users were doing just fine with the tools they were already using.

...

Thinking back on this, it was evident to us that there was nothing to “improve” or “optimize” here as a standardized “workflow.” The participants’ solutions were already clever optimizations using the tools and paths that they understood.

To me that's a fairly clear admission that the bricolage approach has benefits in certain situations.

DoreenMichele2• 8 years ago

users who value stability and reliability over small efficiency gains

The efficiency gains are often theoretical, not real. This is the essence of why the qwerty keyboard remains the standard, though it was designed to be intentionally inefficient to slow people down. There is a very real cost involved in retraining yourself to do things differently.

It only makes sense to do so when any gains in efficiency will be quite substantial, obvious and will meaningfully pay off in a relatively short time frame. Most new tech fails to meet that standard for most people.

sorokod• 8 years ago

Indeed the users may perceive the approach they adapted as a local maximum and don't consider the price of climbing down in order to climb up to a higher point to be worth the effort.

reidacdc• 8 years 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• 8 years 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.

pacificleo113• 8 years 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

pasbesoin2• 8 years 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• 8 years ago

The author was referring to Claude Lévi-Strauss, a french anthropologist: https://en.wikipedia.org/wiki/Claude_L%C3%A9vi-Strauss.

pasbesoin2• 8 years ago

My bad. More coffee, less impulse. Apology.

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

Related Stories