Designing Edenbee

What do we do?

I checked with everyone in the office before I came up here: we’re deﬁnitely a user-
experience design consultancy. So that’s cleared that up.

So before I talk about edenbee, let me give you a bit of context.

So, my name is James.

So this is Clearleft HQ.

In the sunny seaside town of Brighton

Well actually this is Clearleft HQ.

All the other pictures were boring so I picked one with a horse in it.

And this is a horse going in to our next door office.

This happens on a regular basis and we’re still not sure what is happening

Or whether we should report it to the RSPCA

LE GEND

http://www.ﬂickr.com/photos/clagnut/2295246599/

And this is the legend that is Rolf Harris (outside the office).

This makes my wife cry.

We spent the majority of our time designing and creating web sites

We do some consultancy kung-fu

We also run an annual grassroots web conference called dConstruct.

Shameless plug: Friday 5th September this year

And we make (or are making) some guerilla usability testing software called Silverback.

This is Steve the gorilla here on the right.

But I’m deﬁnitely not here to talk about that. Although I do have badges. Come and see me
afterwards.

des ign ing

So back to the matters in hand

hitect s ta ke on
forma tio n Arc
a n In
des ign ing

Or more appropriately, an IA’s take on designing edenbee.

First off, a little bit of background.

http://www.flickr.com/photos/freefoto/639294974/

Here’s a picture of sheep.

I picked this to represent the kind of thing we want to shy away from when working on
projects.

But it was one of the primary reasons I wanted to work at Clearleft. To avoid any kind of herd
mentality when starting and running projects.

I’m exaggerating by saying we don’t have a formal process. But rather than a pre-defined
collection of steps, instead we’ll adapt to the specific needs of the project.

Kinda makes this presentation hard -- I can't give you recipes to go back and use in your job
from the Clearleft process. It changes to suit the needs of the particular job. That’s not to say
we don't make it up as we go along either -- but we certainly adopt an adaptive approach as
opposed to a prescribed set of steps.

Pete
D ave

Here’s Dave & Pete outside edenbee HQ. Conveniently above a pub.

edenbee is the product of three teams....edenbee + clearleft + new bamboo. crucially both
small.

Within Clearleft Rich and I adopt the IA mantle, but in truth all of our skillsets overlap heavily
-- we are a multi-disciplined team. We all sit in the same room. We learn collaboratively. Or
by osmosis as I prefer to call it.

This is an absolutely CRUCIAL element to the way we work.

Seriously, someone should try and work out how to quantify the gains that this approach
brings.

http://www.ﬂickr.com/photos/basil_gilbert/396270430/

Hopefully I’m not talking my way out of any future job for Clearleft but as well as no process,
we don’t really do deliverables either.

This is something common to the vocabulary of an Information Architect. The site map, the
personas, the user journeys, the wireframes. These commonly shape the project plan.

We use all these things too but NOT to shape a Gant chart.

For me, the very term 'deliverable' has all the wrong connotations. The goal is not to to
‘deliver’.

The process and act of creating “deliverables” is far more important than the documents
themselves.

The emphasis for us is a formative one.

http://www.ﬂickr.com/photos/jason_coleman/294790591/

But we are left with a problem....the very nature of our company, as an agency -- the fact
that we are a third party -- is that there is an endpoint.

Of course we try to avoid the throw it 'over the wall’ mentality, but at some point we stop
getting paid.

As we discovered, it's particularly relevant when designing for community. And this is
something I’ll deal with later in the talk.

GUILTY!!!
So the project began back in July of last year.

Ironically my colleague Richard Rutter and I ﬂew over to Dublin so we already had some guilt
points to work off.

Just to make things worse, it became one of the only times we were upgraded.

Needless to say this became one of my ﬁrst entries in my carbon logbook on edenbee.

We tend to call this part of the project -- the discovery phase.

Sounds posh, but basically this meant a bunch of us sitting around a table for two days.

There were a lot of macs -- that was a good start.

It was a great couple of days. It was immediately clear that we were working for a client who
were inviting design.

These are crap pictures, but you get the idea...we were here to discover.

We were using disposable lo-ﬁ tools like whiteboards, post-its, cake, Red Bull.

Disposal, non-permanent stuff.

Sketching ideas.

We all recognised the inherent problems at the heart of tackling climate related issues.

One aspect we kept returning to the notion of carbon calculators.

These tended to have a top down mentality. With a few exceptions they tended to be
unremarkable.

But there was good stuff as well...they were personal, provocative, they digested and spat
out data!

Bad: They felt somehow isolated/siloed, companion-less, unsociable. People visited once
and then left.

We became fascinated by the notion of making carbon calculators sociable.

http://www.ﬂickr.com/photos/star_ph-uk/16461704/

They are undeniably intermingled with our everyday lifestyle choices.

The carbon footprint represents the results of these choices -- our stag or hen do
Amsterdam. Our modded Citroen Saxo. Or may be our choice to cycle or carshare to work as
opposed to drive.

These are fundamental choices within our lives today. They are our a facet of our identity.

Our challenge became to make a carbon calculator -- a sociable one - embedded within our
lifestyle

One that not only collects, but also reports, converses, empowers, compares, informs, even
advises.

This appealed to our design sensibilities. And by design I don't mean photoshop.

What do I mean by this? Well on several levels really, on a very rudimentary level: what ﬂickr is
to photos, what upcming is to events, what delicious is to bookmarks. We wanted edenbee to
lay claim to your ecological facet of everyone’s network proﬁle.

As far as we could tell this part of the ecosystem hadn't been claimed.

This represented opportunity, not only for a compelling service.

But also as a means for returning some of this value back in to the ecosystem.

Become a component of the ecosytem.

http://www.amee.cc/

As it turns out being a component of the ecosystem became very important to us.

A vital component of the carbon calculator is delivered not by anything developed by Clearleft
or New Bamboo but from these guys: AMEE.

In their own words: quot;AMEE is a technology platform, designed to be built uponquot;. An API. A
small piece to be loosely joined.

For edenbee this represented a means for extracting out CO2 from our everyday actions.
Huge simpliﬁcation, but essentially we give AMEE a reading and it gives us back the
corresponding CO2 emissions. This then powers the carbon footprint calculation for every
edenbee, as well as the collective community.

But what's so cool about it is...this is an open framework. All the data edenbee contributes
goes back in to enrich the aggregate whole

Can't talk more highly about these guys and about they represent how I see the future of the
web. Small pieces loosely joined.

As Tom Coates put it, it's about 'doing more than we could do apart'. quot;An aggregate web of
connected data sourcesquot;. AMEE exempliﬁes this ethos.

“The fallacy is to think that social
networks are just made up of people.
They're not; social networks consist
of people who are connected by a
shared object.”

Jyri Engeström
http://www.zengestrom.com/blog/2005/04/why_some_social.html

This is a quote from an article by Jyri Engeström from Jaiku called “Why some social network
services work and others don't — Or: the case for object-centered sociality “. Unbelievably
it’s from 2005 which makes me realise how smart this guy must be.

It’s something I constantly return to when designing social software like edenbee

We were really excited at the end of the ‘Discovery phase’ as we felt we identified our shared
object for edenbee: the ecological profile. The sociality of edenbee would extend from this
object.

Our ecological profile: not just our footprint, but also our goals for change. Refer to Juri's
post. This sense of object-centered sociality was crucial. Ironically we wanted to avoid over-
focusing on social value...strip away the sociality and we still have personal value for our
edenbees.

http://www.flickr.com/photos/booddin/116104385/

So I’m going to skip forward a bit and start talking about how we actually realised some of
this stuff now that we had a vision an object to build around.

The first thing to mention is that functional specs don't live around here.

At the heart of our design we developed a high-fidelity prototype.

By high-fidelity, I mean interactive, clickable.

There’s lots of ways of doing this, Flash, bespoke tools like Axure.

As a web standards focused company it makes sense for us to use the tools we feel most
comfortable and productive using. This means HTML, CSS and JS (heavily jQuery flavoured)

What's our goal here?

And why high-ﬁdelity? Why not just Visio or even paper prototypes?

Well on hte most basic level, this is a means for us to acknowledge
that we're designing experience so let's try and get as close to possible to creating this, even
participating in this ourselves.

Well allow me to generalise (a bit more) here but the traditional approaches to IA often follow
the patterns of science -- this is one of reductionism.

“Reductionism was the driving force
behind much of the twentieth
century’s scientific research. To
comprehend nature, it tell us, we
first must decipher its components.
The assumption is that once we
understand the parts, it will be easy
to grasp the whole.”
Albert-László Barabási
Linked

By looking at the problem in its smaller constituent parts we can then (re)build it correctly.

So to make a huge simplification, for an IA this might be something as simple as ‘we get to
know our users, we establish a user's goal, then build him or her or her a path to reach that
goal, maybe with a few sign posts to help them along the way.

Typical wireframes deal with this by capturing one representative user path through the
system.

But this is unrealistic when it comes to the demands of modern web development.

A web page can take many different forms depending on whether the user is say....logged in,
or whether they need some extra feedback after interacting with a widget.

Let's think about this from a micro level.

A traditional wireframe -- say something from Visio -- is less concerned with the behavioural
level of the interface. More about structure.

But this isn’t practical in a day when micro-interactions are so fundamental to our experience
of a website.

Behaviour is so important -- we wear it on a t-shirt!

Ajax is clearly responsible for a lot if this....as soon as you start updating web pages without
page refreshes, you lose the native feedback mechanisms of the technology.

And this means you need to design these yourself.

Remember we’re no longer just talking about a mouse click, we’re talking about ALL the
various events on a page, mouse over /blur / focus / drag & drop etc... Traditional tools such
as Visio just don’t have the capacity for capturing this stuff effectively.

This is a big reason for us using high ﬁdelity prototypes

Equally on a macro level: we can't afford to build a site purely from an examination of it's
component parts.

We need to understand the interaction that happens between them.

This is even more true of social software.

Building one representative user path through a website is no longer good enough.

There is no longer an idealised version.

Our UIs need to be be adaptive...to accommodate the behaviour that emerges through their
use.

This image is from the Facebook dev wiki where they’ve been demoing some of the changes
for their next big release. There’s huge amounts of customisation going on. Users now get
the chance to customise the tabs that make up their site. Basically giving the user the
opportunity to play with the information architecture of their site.

This level of customisation is more akin to a game than a website.

But capturing this level of diversity in the form of paper wireframes is kind of hard work.

Apart from anything else, the number of wireframes (and the effort that would need to go in
to that) makes them redundant as a tool for communicating design decisions.

A high fidelity prototype allows everyone to participate (devs, IAs, clients), It has universal
appeal.

And most crucially USERS.

One of the greatest benefits we’ve found to high fidelity interactive prototypes is the potential
for early-stage usability testing.

We’ve had phenomenal results with this, even to the point that we’ve been able to iterate
through versions of the site during testing itself.

If there was one reason for doing this stuff, that would be mine!

Get yourself some cheap usability testing software...anyone know any?

But  wa it!

There's a big BUT here. This isn't perfect.

I want to highlight some of the tensions here that are really important when designing social
software.

Let’s face it, it would be arrogant to think we could design a community. Orwellian.

Especially one which is founded upon a bottom-up mentality.

Communities design themselves.

“Riding reductionism, we run into the hard
wall of complexity. We have learned that
nature is not a well-designed puzzle with
only one way to put it together...Yet nature
assembles its pieces with grace and
precision...It does so by exploiting the all-
encompassing laws of self-organisation,
whose roots are largely a mystery to us.”

Albert-László Barabási
Linked

Let’s return to Barabasi.

This is the continuation of the reductionism piece I read earlier.

Barabsi is talking about the laws of nature, but the pattern applies to networks as well. In fact,
the book that this quote is taken from is all about networks and network theory.

The crucial word or words here is self-organisation

And this is what we need to be mindful of when we’re designing FOR a community.

IAs tend to argue incessantly about their job titles. It annoys the shit out of me. Personally I
think I’d prefer to be a web designer.

Interestingly this is where my role or at least my job title has a direct comparison with
traditional architecture.

We create the spaces and objects within which people interact, but the actual interactions
themselves are reserved for the inhabitants of this space.

It is from here that community emerges.

If I can use an analogy here. I'll need to borrow a lovely term from Will Wright: the possibility
space.

I've always been a massive fan of Will Wright’s games and what characterises them for me is
that feeling of open-endedness, that you can do ANYTHING, there are no boundaries.

It's the place that Wright refers to as the possibility space.

The algorithms that sit below the game’s surface are designed to encourage exploration of
the possibility space.

Rules that foster emergent behaviour.

http://www.flickr.com/photos/philgyford/20553280/
http://www.flickr.com/photos/yersinia/230046745/

I love these pictures of desire paths.

Defined in Nick Crane’s book 'Two degrees west' as the imprints of 'foot anarchists',
individuals who had trodden their own routes into the landscape, regardless of the intentions
of best-laid plans. There’s Flickr groups set of for this kind of stuff.


I like this one but it begs the question why would anyone would want to take a shortcut to
Lidl?

Must be the people coming out rather than going in.

http://www.ﬂickr.com/photos/kake_pugh/1307255998/

But I show them here as representations of emergence.

An this is where I want to return brieﬂy to the point I made earlier about the problems that
agencies have when they reach an endpoint.

To design FOR a community we need to design WITH the community.

Allow the community to emerge like these desire lines do. But this is a challenge for us when
at some point we throw our work over the wall.

I don’t really have answer for this yet. At the moment we mitigate this by working long after
the launch with our clients, helping them build a team to manage these things themselves.

Image credit: From Sinai Hotels, by Sabine Haubitz and Stefanie Zoche of Haubitz+Zoche.

I was recently involved in the beta test of a new piece of social software that had
EVERYTHING. Features everywhere. Groups, forums, walls, internal messaging, poking,
nudging.

The aggregate effect was poor though...all it did was dilute the community rather than enable
it.

As well as dilute any sense of object-centered sociality. It was to such an extent that I didn’t
really know what the site was about.

It would be unfair for me to show the site in question so I thought I’d show you some
pictures which reminded me of it.

Or at least it’s future.


These are pictures of abandoned hotels on Egypt's Sinai Peninsula.

Rather perversely, I ﬁnd the pictures kinda mesmerising


The pictures were captured by Sabine Haubitz and Stefanie Zoche and then subsequently
documented by Geoff Manaugh from BLDGBLOG


Manaugh describes these as “monuments to failed investment”.

“The hotels now look more like quot;architectonic sculpturesquot; in the desert...or derelict
abstractions, as if some ageing and half-crazed billionaire had constructed an eccentric
sculpture park for himself amongst the dunes.”


It reminded me of the dangers of not focusing on your central object.

that edenbee needs to do one thing REALLY well and if the demand for social tools to
facilitate this emerges, than look to satisfy those needs.

Design FOR your community.

Fu ture?

Edenbee is not yet embedded in our lifestyle. Entering carbon data isn't much fun. Perhaps we
need to make this more playful? Needs to aim towards ubicomp type values. In the course of
ordinary activities, and may not necessarily even be aware that they are doing so. Watson.
Toyota Prius. iPod jogging? quot;technology dissolved in the cityquot; (Chris Heathcote's blog)....It
doesn't do this yet

There is no API. Well not officially...

WE could beneﬁt from more 'play'

lis ten ing
k y ou  for
T han

doesn't do this yet


WE could beneﬁt from more 'play'

Com e and see me at:
http://edenbee.com/

Fantastic potential

We’re hoping to work with edenbee again.

doesn't do this yet


Designing Edenbee

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (11)

Destacado

Destacado (6)

Similar a Designing Edenbee

Similar a Designing Edenbee (20)

Último

Último (20)

Designing Edenbee