basil.surge.sh

It’s specifically designed for a user living in an apartment, who wants a small, constant basil supply.

The production is designed to be done by the user, as opposed to making it and selling it as a product for 3 reasons.

1. By allowing the user to use local, available materials, cost is reduced.
2. As the user produces their system, they learn to how to upgrade / downgrade and repair their system.
3. The relationship between the product and the user improves through narrative.

The consumption of the product aims to just be the user eating their basil as they want, with minimal annoyances. Annoying things would be if it took up too much space, required lots of the user’s time, made the room damp or made too much noise. It’s job is to just produce basil for the user.

The destruction of the product is hopefully, a slow one. By having the user create it, if something in the system breaks, ideally they’d know how to fix it. Ultimately all the bucket will eventually start to flake off into the coir, at that point it can be recycled as best as possible.

Use scenarios

Lucy is going to the primary school science fair. Her basil has doubled in growth in the last 4 weeks of the experiment, and she is really hoping for a prize. As she brings her project inside she notices 3 other people had also grown basil. “Oh well, at least this will be great on bagels”, she thought.

Eliot is bored, and is browsing through his timeline. His friend shared a link to basil.surge.sh, interested he opened it. He does like basil. “Hmm, this looks good but it’s a lot of steps. I’d have to find some coco coir …. maybe a project for the holidays”, he thought. He never got around to it.

Christine was driving her old basil box to the dump. It has served faithfully for the last year and a half, but the other day she noticed some of the plastic was cracked, and flaking off into the soil. Rather than risk getting plastic in her basil, she decided to just chuck it all at the recycling centre.

Bryan was a small time drug dealer, and he was about to go show one of his operators how to start growing. Ever since large cash payments were outlawed, all large payments were being data mined. If you went and bought a whole heap of large scale growing equipment, it would cause some investigation. So, they had to find a DIY solution. Basil.surge.sh was perfect, small, discrete, and nobody would blink an eye at somebody buying a bucket. The key benefit however was decentralisation — rather than having all of the production in one place, they could spread it out over the city. Even though one of his members got raided last week, that was only 1 out of 30 units they had running — there was virtually no stop in supply.

The core way my design incorporates Chapman’s framework is through narrative. By getting the user to build it, using local materials, they share a unique personal history with the object. No basil box will be the same.

At first I wanted to argue a sense of detachment to the object — the fact that the user doesn’t actually care about the product itself, and only the basil. But I found after making my setup, I was very attached, I was checking the plants twice daily, like a nervous parent. I think when the system is first made, the user will be attached, but I do think that will fade. After a few month it will feel just like any other object which does stuff for you, your toaster, dishwasher, dryer etc. I think the user will be attached to the service it provides, but not attached to the actual physical system — as they know how to reproduce it.

I want my product to have a strong relationship with a user, and I think the best way to do that is through it providing a continuous need. For example, netflicks, your bed, coffee, and your dishwasher would be hard to cut out of our lives — because we always need entertainment, sleep, energy, and spare time. These products are not single-use, they are continuous-use.

I aim to foster an intentionally one sided relationship. The basil box is here to serve the user, not the other way around. In ‘The Best Interface is No Interface’ by Golden Krishna (2015), he laments the fact that software has created ‘digital chores’. Updates to install, emails to check, passwords to reset — stuff like that. These digital chores build up, until you find that software isn’t serving you — you’re serving it. His argument is that software should be more autonomous.

I think the same can be applied to real life chores, and my project. I don’t want to spend my time growing basil — I want to spend my time eating basil.

Designing relationally has it’s upsides and downsides.

It lets you design a product very very in detail, for a very specific user. If you want to make a product which fits naturally into a persons life, this is a great way to go about it. I think this is great at making a product which is really focused.

I think it’s limitations lie in this specificity. I’ve successfully relationally designed a product for myself, but it would be a huge challenge to design something for somebody else. You just really really have to know your user, and there’s only so much research you can do.

It would also be tricky to design a general product for a larger audience relationally. Say for example voting — everybody has so many different feelings about voting that there would be nowhere to start.

I’d argue relational design isn’t a design process, but a perspective. I think you could look at a design, and assess it for the strength of it’s relationship, in the same way you’d assess for usability, accessibility, or effectiveness.

Chapman’s framework is a great way to reinforce the positive aspects of a relationship, but I think it misses by not looking at ways to reduce the negative aspects of a relationship. I’ve got two suggestions for additions.

One key thing missed is autonomy. There are plenty of products we couldn’t live without, because they are autonomous, e.g. your washing machine. Say your washing machine worked exactly the same, but it was powered by hand crank, which took 45 mins for a full wash. The washing machine still provides the same service, and you would still have a sense of attachment, but god it would suck. You’d either hate your washing machine, or have smelly clothes. Autonomy would build a relationship not through enforcing positive aspects, but by simply taking less of the user’s time and attention.

Chapman also doesn’t consider how the relationship is viewed by other people. Relationships are often judged or praised in the real world, your friends, family, and society as a whole has an opinion on your relationships. The same could be said about designed objects. People will judge you for smoking a cigarette, or admire you for wearing running shoes — thats got nothing to do with the relationship between you and the cigarette, or the shoes. But it’s got something to do with you and these external people, and ultimately that will affect your relationship with a design. In my project just by trying to grow hydroponically, there’s the association with growing weed, understandably. However, that will affect my relationship with my basil setup. I don’t have a word for this addition, but it’s something the framework doesn’t consider.

So, after all of this, the question is — did my design succeed? Version one did not. It used an air-pump which was annoying loud for my bedroom, and the plants did not grow well. So I created a second version with no moving parts, and my basil has been growing well.

By Eliot Slevin