Things People Said That We Liked And Illustrated: #1
by Georges in Illustrations on 7th September 2010 at 08:02
Everybody’s different
by anant in Buddy on 3rd September 2010 at 13:57
An interesting point was brought up by one of the clinical psychologists involved in the project that we met with. The people in the trial will have really, really different views and interpretations of the same word, or in this case, ‘emotion’. It comes back to the age old philosophical argument – how do we know whether what I see as blue is the same as what you see as blue. These are just words attached to a colour and don’t represent it in any clear way – except mass agreement. In the same way, the emotionally charged word ‘loved’ will be experienced completely differently by two different participants.
Unfortunately, there is no real way (yet) for this to be measured. However, what we can do is look at the different conditions that our participants have to deal with, and how, rather what, Buddy could mean in these terms.
We didn’t think Buddy would be appropriate for patients with schizophrenia, at least not for this co-design stage (a radio transmitting their moods to different people and computers may cause undue stress, and possibly add to their hallucinations). The people in our trial suffer with – bi-polar disorder, depression and depersonalization.
Bi-polar disorder (or manic-depressive disorder) is a psychiatric diagnosis describing a category of mood disorders that are characterized by one or more episodes of elevated energy levels, cognition and mood, with or without one or more depressive episodes. The elevated mood stages are called ‘mania’, and the two stages are commonly referred to as highs and lows. There is also a possibility of psychotic symptoms in bi-polar, such as hallucinations and delusions.
Depression (major depressive disorder) is characterized by severe, highly persistent depression, and a loss of interest or pleasure in everyday activities, which is often manifested by lack of appetite, chronic fatigue, and disturbance to sleep. The patient may contemplate suicide, and indeed an increased risk of actual suicide is present. The person may also suffer loss of concentration, self worth/esteem and motor activity.
Depersonalization is a disassociative disorder in which the sufferer is persistently affected by feelings of derealization. It is diagnostically characterized by recurrent feelings of being detached from ones mental processes or body. The symptoms include a sense of automation, moving through life but not experiencing it, feeling as if one is in a movie or dream and/or feeling disconnected from ones body. Patients could go through out of body experiences, detachment from themselves, the environment and can have difficulty relating to reality. Sufferers are able to differentiate between reality and fantasy and do not have psychotic symptoms.
So how does this affect Buddy? Most obviously, it means that ratings by people with different disorders will mean different things. For example, if someone with depression started rating their moods more and more positively, we would see this as a good thing. Also, looking at the information Buddy provides in conjunction with daily events in peoples lives may help to identify mood ‘triggers’. For example, a conversation with a certain person could lead to someone feeling loved, while another could leave you feeling terrible. And knowing whats good, and bad, for you can be extremely useful.
For people with bi-polar disorder, however, we have to watch their moods very closely. This is because it may be a good thing if there mood is slightly elevated, but it may also be a cause for concern, as this could be an indication that they are going into a manic episode. For people with depression, elevated mood is a good sign. In terms of negative changes in either condition, Buddy will be able to provide ‘talking points’. For example, if a patients mood is elevated, and suddenly takes a negative turn, professionals can annotate the graph, make a phone call, basically start conversations with the person. At least, this is what we are hoping for.
Distributed Care
by Adil in Buddy, Project Development on 1st September 2010 at 17:45
One of the key aspects of Buddy Radio is the use of social media to make it easier for friends and family to be involved in the care of an individual. The service works by sharing a user’s moods with a wider network of people (than simply their care professional) – with the aim that by increasing the possibilities of social contact, we can also increase the possibilities for social care.
We’ve been thinking for a while for a useful analogy for this new approach. We toyed with the idea that we’re putting the social in social care – which has a nice ring to it, but seems a bit advertising slogan-y.
Decentralising care is another term we could use to describe how Buddy works. Traditional models of care tend to be quite centralised, in the sense that care flows from a ‘commissioned’ central provider, to the individual care recipient. Centralising care, theoretically offers control, monitoring and basic standards, but too often it means ‘one size fits all’ solutions, organisational inefficiencies, and a system-centric, as opposed to user-centric approach. With Buddy, we’re curious to see how by bringing patients, professionals, peers, family and friends all together in a single, collaborative system, we can decentralise care, and change the nature of the relationships and human interactions which impact human health.
Decentralising care however doesn’t seem to adequately capture Buddy. Decentralising could be seen as the centre liberating itself of its responsibility. It also seems like something you do, rather than something you offer. It’s semantics, but I feel we’re looking for something which speaks more to the benefits of Buddy.
We’ve been thinking on this and are wondering aloud whether the notion of distributed computing makes for a useful analogy. A quick look through wikipedia later and Distributed Care seems like a fairly apt phrase to describe what we’re doing i.e.
1) Distributed computing is a network of computers, made up of individual nodes, but with a common goal. Distributed care is a network of people, made up of individuals, with a common goal to care for someone.
2) Distributed computing is a system where the problem is divided into many tasks, each of which is solved by a single computer. Distributed care is a system where the macro needs and demands of an individual are divided by many people, and resolved by an individual.
3) The purpose of a distributed system is to co-ordinate the use of shared resources. The purpose of distributed care is the use of web technologies to co-ordinate the limited human resource available.
4) A distributed system is more reliable because there is no single point of failure. Distributed care – by facilitating networks of people around a user – means there is less reliance on either a centralised service, and / or on any one node.
5) Distributed computing is a more cost efficient way of obtaining the desired level of performance by using a cluster of several low-end computers to do what it would alternatively take one super-computer to do. Distributed care can be a cost effective way of delivering care, through the use of clustered, cheaper resource in the form of family, friends and Big Society.
It’s tentative still, but feels like there is something in it. If the NHS could move to a more distributed model of care, can we divide up tasks better? Coordinate resources better? Build in greater tolerance for failure? And provide this all, for much cheaper?
It seems like its worth exploring, but already questions come to mind. Each computer in a distributed model has only a limited, incomplete view of the system, so what does this mean – do tasks slip through the net? Who is ultimately responsible? What are the respective roles of the different players – are they all the same? How do the nodes interact with each other? Do they at all?
Hmmm. Questions, questions, questions, just when we thought we had some answers, answers, answers.
The making of Buddy shell
by tracyt in Buddy, Project Development on 27th August 2010 at 14:03
Not quite a full making-of documentary, but as we hold our breath counting down to the imminent release of our final Buddy prototype – I just wanted to share some glimpses into the development of the Buddy interior world which I’ve been working on for the last couple of weeks.
Although armed with a nice working paper prototype, we soon discovered that it wasn’t such a trivial task to take it to the next stage.
It was a combination of adjusting millimeters after seeing how the parts fit inside the acrylic box, and some creative fastenings to ensure our prototypes can last 3 weeks of usage between different users. One of our challenges was that the strips of lights on the circuit board lies slightly to far back from the front, therefore preventing an accurate reading of mood levels from other angles. This was in the end solved by clear rods which effectively act as a bulb for each led.
During this process, one end of our table transformed into a temporary workshop, and me into a temporary power tool terrorist (albeit one who wears floral dresses). It’s brought back fond memories of being a student and I’m certainly going to miss all the drilling and sawing when our tools retreat back into our store cupboard.
Streatham to Sidekick
by anant in Buddy on 26th August 2010 at 13:18
Hi. My names Anant, and I’m the assistant psychologist working on the Buddy project from SLaM.
I’m supposed to blog about what it’s like for someone from the NHS (me) to work with a 3rd sector social innovation studio (Sidekick). I thought I’d start with the interesting – the work space, and then move into the more mundane things, like work ethic, planning, and two very different ways of doing things.
Nick invited me to come and work down at the studio for at least one day a week so that I could be a little more involved and in the loop with the progression on Buddy. I had been to the studio before so I had a little bit of an idea of what to expect.
The CMHT in Streatham was my base line, exactly what you would expect from an NHS building. Spread over 3 floors, very much a concrete block right next to Streatham High Road station. All keypads and cameras, filled with lovely people. The atmosphere at 380 is very professional, the people very friendly but the levels of stress and workload are always high. So working at a design studio in what looks like a converted warehouse building in London Bridge (two stops from home) one day a week doesn’t seem too bad.
The Sidekick work space big and open, with a garden out the back. It still has old wooden beams and brick sections, juxtaposed with the very modern 27’’ iMacs, MacBooks and various pieces of tech. The space and the atmosphere are very creative (to be expected from a studio I guess). There’s music playing, walls covered in post-it notes, a garden out back. All conducive to the work done here, in the same way the CMHT setting is conducive to the work done there.
So these are the two worlds I move between now. Breaching the membrane between the public sector and a 3rd sector design firm allows me to see some of the differences between the two organizations and the way they work. These differences are going to be the topic of my first couple of posts.
The first insight I gained was to do with something I noticed about the NHS since I first started working there. There is a rigid structure and set of rules on how to deal with..well almost everything. For example with new interventions – we go from an idea, to a pilot, to a clinical trial and ideally finally to a publication. And this is a system that works – it meets the needs we present, and demonstrates the value and validity of the intervention or idea.
Working with Buddy is extremely different, as we were taking an idea for a product, and actually creating it. Adil approached us with the idea last November and since then we have submitted a successful bid, gotten funding, and I can now see the working prototype sitting right in front of me – and we are about to give it to people. The way we’ve moved through this is by using the AGILE project management style – sort of. Sort of because there is no documentation and everyone talks to each other about it rather than producing lots of paperwork – there is a lot of interaction. We’re not, however, using ‘sprints’, but we do work efficiently, in small teams and respond quickly to feedback. Its…vague. Which is something, coming from the NHS, I’m really not used to. But, it works, and I think I’m going to learn a lot (more) from working with the Sidekick team.
Informed co-design, hardware prototypes, agile service and software design and more – it’s a mega Buddy project update!
by nick in Buddy, Design, News, Project Development, Project News, Service Design on 24th August 2010 at 19:30
Its been action stations at Sidekick for the past few weeks as we get ready for our first co-design period with service users from SLaM’s community health team. With all hands on deck, we’ve been a bit neglectful of the Buddy development blog, so here’s a pretty in depth update of where we are in terms of the co-design process and the hardware, software and service design. We’re really baring all here, which I think is pretty awesome and rare for design studios to do, and we’d love to hear your feedback and questions in the comments below. Here goes!
Co-design process
As of next week (provided there’s no last minute technical issues) we’re going to give our first set of Buddy device prototypes to four different service-user co-designers to use in their homes for three weeks. We’ve already visited these people at their homes in order to get to know them better and lightly inform the first iteration of the software, hardware and service design.

During the three week prototype we’re going to get each user to use three different interfaces (see the hardware section below to see one of them) for a week each. This means that the co-designers will get to experience different options, but none of them get to experience all the options.
We’re hoping that this leads to better conversation and reflection during the subsequent co-design workshops once the three weeks are up, as everyone is forced to compare and contrast their experiences, rather than picking a winner.
During this co-design period we’re going to go back to basics with the service users, and a range of professionals from SLaM, to revisit the Buddy concept, and re-design it from first principles. The thing that gets the design-process geek in me excited is that the people who’ll be helping us co-design this Buddy v2 solution will of course be much better informed about the possibilities that social technologies present them.
For us, this methodological innovation – what we’re calling ‘informed co-design’ – is as important as the technical innovation behind the Buddy concept.

A lot of co-design work that I’ve seen (and done) led by service design agencies and other groups working with design-led methods in the public sector is really just a very creative way of asking people what they want (which, admittedly, is quite a step forward from how most public sector services are designed.)
Regardless, co-design 1.0, or asking people what the want, still has serious limitations, the most important being that people can only tell you what they want from their own experience of what’s possible. And most people aren’t aware of the potential of internet technologies to do amazing things.
What we’re doing with the Buddy ‘informed co-design’ process is taking the best and most sensible bits of the co-design method (collaborative working, deep user involvement) and plugging it into some enforced eye-opening prior to asking people what they want. Hopefully its going to lead to some surprising results.
Hardware design

Our amazing I-do-everything intern Tracy has been hacking away at radios and creating various boxes to stick them in, whilst our equally amazing electronics genius Charles has been etching, soldering and fiddling with a range of technologies to create the mood monitoring components on the end of the radio.
As you can see from the photo above, we’ve very deliberately tried not to ‘design’ the hardware at this stage. Instead, we’ve tried to create a device that looks like a functional prototype (er, mainly because that’s what it is), and that our co-design team will feel they can really help to re-design. Having said that, I actually really love this lo-tech aesthetic. We’ll see. Developing a proper design language and a specific Buddy form factor (if it remains a radio after the co-design work) will be a big part of the next iteration.
During the prototype we’re going to explore four different mood monitoring concepts that will give us insight into different interactions and behaviours around the physical user interface. Essentially we’re exploring two questions – firstly, do users prefer a single scale of generic mood, or a three part scale of specific moods with words attached, and secondly, is it better for users to actively submit their mood (via a button) or should the UI be more ambient (and update automatically)?
This submit vs ambient update interfaces will create quite different user experiences, as the active submit interface means that the user is always returning to an interface set to zero, whereas the ambient submit interface means the user returns to the last mood reading they gave. This is the difference between asking ‘how do you feel now’ vs ‘how do feel now compared to last time you told me how you feel’. It will be interesting to see what the users think about this, and the health professionals.
Software design

Alongside the development of the Buddy radio hardware, Nathan, Matthew and Mat have been working away on the meat of the Buddy system – the software platform that collects and presents the data back to health professionals, and allows users and their various communities of carers to view, analyse, comment and share their mood data.
Our various patents (pending) around Buddy mainly relate to the software, so we can’t go into too much detail at this stage. We’re using a relatively loose agile development process to produce the software and hardware touchpoints, which means we’re already into a major redesign of the initial software iteration following feedback from the professionals in our co-design team.
(As an aside its really interesting, for a design process geek, to see agile principles rubbing up against our informed co-design methods, but that’s another blog post.)
For now, the design and art direction, much like the hardware aesthetics, have been driven by the functional requirements. The software is in early prototype stage, and that’s reflected in the user interface. Again, as with the hardware, developing an integrated design language and brand will be an important part of the next iteration, once we’ve worked through the co-design activity with the users and have a clearer view of the overall service design. Which leads us onto…
Service design

For now, we’re very much prototyping the service design through the co-design trial activity. In the future, Buddy users will assessed for suitability, be introduced to the service through their care coordinators, be signed up to the system, receive a device or input mechanism of some sorts, use it for a while and then eventually give it back. Which is sort of what is happening with our three week prototype.
However, there’s clearly a lot more detail and depth to add to the final service design, in terms of the overall user experience of joining, using and leaving the service, but also in terms of the ‘back of house’ system integration aspect of the service design. We’re coming round to the point of view that it is Buddy’s close integration with existing care pathways and professional care services that will make it most valuable, and we’ve got some good ideas about how to integrate it into existing clinical procedures that we want to explore with the service users and professionals.
Evaluation and outcomes
Beyond the design-led challenges of creating a good user experience across the hardware, software and wider service, there’s two issues that we’re thinking about, that we haven’t discussed here yet and that all this work is being done for – how will Buddy deliver a cheaper, better health service for people with long term conditions?
Firstly, what is the clinical value of Buddy to the service users? Will it make them better, quicker? Which conditions (e.g schizophrenia, severe depression, bipolar disorders) will it work best for? How will use vary across these conditions? At this point, we don’t have answers to these questions, but of course that’s why we’re doing the prototype and co-design.
Secondly, what is the business case for Buddy in terms of financial savings for the NHS? This is a big question, and there are a range of assumptions and ideas we have at the moment that we will need much more than a three week co-design prototype to find answers to.
There are two obvious places to look for demonstrations of potential savings. If we can help people get better quicker, and stay better for longer we’ll be saving money, and if we can demonstrate that Buddy actually prevents people from using acute care services (i.e being admitted to hospital) we’ll be saving a lot of money. Demonstrating either of these is going to be difficult, and will take a long time.
However, these are challenges that can wait for the second iteration of all the touchpoints – for now, we’ve got a hectic prototyping/co-design process to manage over the next three weeks. We’ll keep you updated with how we get on, and we’d love to get your comments and questions below! What have we missed out? What should we be watching out for? Let us know…
Just Enough Technology
by Adil in Buddy, Project Development on 19th August 2010 at 09:42
Someone described us as tech company in a meeting the other day. I was kind of flattered. A Technology Company. That makes us like Cisco, right? But it also made me uneasy. You see tech companies are the ones that put extra dials on a microwave like this one, when the analogue system was kind of better.
They make remote controls completely unfathomable.
They design interfaces that are shocking.
They make ugly things. With even uglier product names like this LaserJet CM1312nfi.
The problem with tech companies is that they are well, tech companies. And we don’t want to be that. If Buddy was designed by a tech company then it would do so much more than it does currently. It would let the community of carers send digital messages back. But because they are sending messages back, there’d need to be a bigger screen which tells you where the message is from. It’d probably have some way of letting people talk to each other in person too. Maybe it’d incorporate a telephone. Which will need some buttons so you can phone out from it. In fact, it’d be better to have video, that’s easy enough nowadays. So let’s have an even bigger screen, with a camera, and we’ll need some buttons to make the camera work. And given we’ve got all these buttons, maybe we should add a keyboard. We could integrate that on an alpha numerical keypad. That will save buttons.
Now we’ve got all this tech, we’re going to need a better internet connection. So let’s put an ethernet port on there, so people can connect it to their wired connection. Actually, lots of people have a wifi connection nowadays, so we probably need a wifi card. Hmmm. This stuff is quite difficult to set up especially for people with health conditions. What we need is another button that people can press and that summons the IT man who lives next door. Job done. It could look something like this…
…or maybe we should just use a computer. Except you need to buy expensive kit, figure out how to turn it on, know what a desktop is, know what software is, know what these funny symbols around the keyboard mean, know how to get an internet connection….you get the picture.
For Buddy, we adopted the principle of just enough technology – which is a phrase someone said to me in conversation the other day that I loved and stole. See, we could incorporate audio and video into Buddy. We could let people message back. We could forget plug ‘n’ play and pay-as-you-go SIM cards and instead hook into the internet mainline.
But all of this seems to desperately miss the point. The solution isn’t tech. Or more tech. The solution to tackling social isolation is human contact. Genuine, real human contact. By incorporating all this tech, the threat is that we just create a digital conversation, which in some ways becomes even more isolating. And we make things more expensive, less accessible, and less good, all at the same time.
For us, the principle of just enough technology means a message is sent from the Buddy radio to someone in your care community, but then it is their responsibility to either phone back, or dare we suggest it, pop round. Not only is this easier to design, cheaper to buy, simpler to use, but it helps us keep us focused on our goal which is more human contact.
The reason why I balk at the idea of being a tech company is because tech companies see tech as the answer to all the problems. We love tech, but just enough technology please.
The Innards of Buddy Radio
by Adil in Buddy, Project Development on 17th August 2010 at 09:36
We are super delighted to share a look under the bonnet of Buddy Radio. We’re in the final throes of preparing for our first iterative trial with service users. The plan is to put Buddy units in the homes of 4 service users with long term mental health problems, at the end of August. We’re fully expecting things to break, collapse and generally not work as well as we’d hope, but that’s the point of the iterative trial.
The word ‘trial’ is probably the wrong word too. We’re calling it ‘action prototyping’ (at least until we come up with another term). The point of the trial is not to see whether it has any impact but to gather feedback which you can only get by putting the invention in people’s hands, in the real world, and using that learning to help us develop a better design. The tendency, especially it seems in the NHS, is to take a concept and turn it into a pilot scheme, whereby everything is measured, controlled, and scientifically evaluated, before there’s even a chance for the innovation to breathe. At some point, we think we’ll need to do that Buddy, but the purpose of this action prototype is just more learning.
The other benefit is that we’ll recruit the service users we are working with into our co-design team, which will mean that when they come to feedback and help us re-design the system, they’re have lived with it for four weeks and will be in a much better place to provide useful insight. We think this is especially important in technology innovation, when so much of the use of a service is only found once it finds its way into the hands of real people, in real contexts.
All of which preamble brings us to these two mega geek-out electronic videos. Enjoy.
Buddy Production Version from Solexious on Vimeo.
Buddy Front Encoder PCB from Solexious on Vimeo.
Featured Posts
- Who’s it for anyway? Engagement in the Co-Design Process
- Models for financing social innovation #2 – Community Development Trusts
- Sidekick Ventures – From Idea to Impact
- Massive 12ft Table with Random Pop Out Drawers
- Cock-Up Cocktails
- Introducing The Social Library
- Peak State and the Valley of Nobody Knows
- Buddy – The Story Of An Identity
- It's Not About Digital, Stupid
Recent Posts
- Things People Said That We Liked And Illustrated: #1
- Methods for financing social innovation #3 – Social Impact Bonds
- Everybody’s different
- Swapping notes with Young Rewired State
- Distributed Care
- The making of Buddy shell
- Streatham to Sidekick
- Informed co-design, hardware prototypes, agile service and software design and more – it’s a mega Buddy project update!
Categories
- Buddy (37)
- Business Design (7)
- Cock Up Cocktails (2)
- Design (4)
- Illustrations (1)
- Internet Finds (15)
- Marginals (3)
- News (7)
- Project Development (39)
- Project News (10)
- public services (2)
- Service Design (5)
- Sidekick Stuff (6)
- Social Innovation (19)
- Studio (25)
- Talking Aloud (7)
- The Social Library (6)
People
Archives
- September 2010 (5)
- August 2010 (9)
- July 2010 (20)
- June 2010 (14)
- May 2010 (19)
- April 2010 (9)
- March 2010 (4)
- February 2010 (16)
- January 2010 (9)
- December 2009 (3)
- November 2009 (2)
- October 2009 (6)
- September 2009 (9)
- August 2009 (5)



















