
In Praise of Theory in Design Research: How Levi-Strauss Redefined Workflow - kawera
https://www.epicpeople.org/theory-in-design-research/
======
timdellinger
"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
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
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
I have read about juggad! But I haven't studied it closely so my knowledge of
the details is limited.

~~~
pacificleo11
thanks for reply . you might want to read this
[https://gagandeep.org/2016/06/02/bricolage-jugaad-and-
indian...](https://gagandeep.org/2016/06/02/bricolage-jugaad-and-indianness-
part-1/)

------
reidacdc
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
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.

------
js8
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
I would add OSX Automator to your list. Is there anything similar fir Windows,
btw?

~~~
maxerickson
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.

------
pacificleo11
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
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
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
My bad. More coffee, less impulse. Apology.

------
thisisit
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.

------
lifeisstillgood
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?"

~~~
js8
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
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
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
> 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.

------
rapnie
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?

------
mehrdadn
I'm still stuck on why they can't measure jeans:
[https://imgur.com/a/866aO](https://imgur.com/a/866aO)

~~~
deerpig
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)

