What do we need to design ?

AndyDearden's picture

Practical Design for Social Action should focus on procuring and managing technology rather than designing the technology itself.
Designing is the activity of identifying practices to generate value.

A common theme in social action recognises that market measures of economic value represent a restricted understanding of value. Social action is motivated by, and built around, commitments to wider sets of human values. These complex value judgements make designing for social
action more difficult than designing for the market.

Value in social action (as elsewhere) is delivered not by technology alone, but by networks of people working collectively (engaging in particular practices) supported by and communicating through technology. In social action, these networks involve employees, supporters, members, funders, and individuals with varying complex relationships and involvement in the action. These complex relationships affect the way people respond to the introduction of new technologies.

Designing for effective social action is about identifying practices for configuring these 'socio-technical' networks so that they deliver value. This is a complex balancing act. We need to consider:

  • How can we measure the value that social action generates?
  • How might choices of technology and practices enabled by the technology affect the value generated - for all the different participants in the network?
  • What factors affect the adoption of new technologies and practices by social action networks and organisations
  • What kinds of designing practices enable organisations and groups to make good choices?
  • How can we develop, equip and embed such designing capabilities into existing social action groups?

The answers to these questions are more about how groups and organisations think about, select, apply and organise around technology as they are about the form of the technology itself.

So what are we doing, as technology designers, to enable non-technical activists, to make better choices?

larryjhs's picture

We all know the problem, the issue, about engaging with people for social action. What I have started to find in my own work in Australia, is that our ideas about social action may be miles ahead of where lots of people are at: they are still coming to terms with managing the technology and if they are in advocacy organisation, with just getting good skills at managing the information they have--and they see advocacy not so much as social action, as client advocacy. social action is a much higher order thing.

 

On the other hand, I have an example in my own suburb in Melbourne where people are white hot about planning issues.  The killer applicaiton is email. People are very happy with that. Why should they use more?

It's making a lot of assumptions an inherent 'goodness' of Web 2.0 to think they should move to it--my experience is that Web 2.0 stuff is hard.  For example, Drupal is way beyond most of the people I know and work with, fantastic as it is......UNLESS there is a perfect support system, which there isn't....

 

 

Paula Graham's picture

The easy ones first eh?

I remember last year we talked about technophobia in the VCS. I'm told the negative attitude on the part of much of the sector towards IT is a legacy of IT being 'sold' as a one-click panacea for 'whatever ails ye' whilst what people actually *got* was late delivery of overpriced, badly-designed, buggy and inappropriate systems. This is a valid criticism of much ICT provision in the voluntary and public sectors over the past two decades and the VCS has often been a hapless victim of arrogant and rapacious commercial companies on the one hand and minimally skilled volunteers on the other. They've suffered from misleading information, ripoffs and put downs and - honestly compels me to admit - have a very real beef, historically.

Justified or not, however, the issue now is to tackle this antagonism towards ICT effectively because negative attidues within the voluntary sector are a very major hindrance in moving on to designing systems which will deliver real social value and enhance human experience rather than being a source of continual frustration.

One of the roots of the problem seems to be that most non-technical participants in VCS activities regard technology systems as outside the realm of ethics, politics or even humanity. They regard computer systems as an annoying form of toaster or dishwasher - it performs a limited function and when it goes wrong you throw it away or pay someone to fix it without discussion. It seems quite rare for VCS organisations to regard technical providers as collaborative partners.

Another issue seems to be that most VCS organisations are a good decade behind current practice at any given time and struggling to get their heads around typing a letter in MS Word. They feel that their current technology doesn't work - and, of course, their curent technology usually *doesn't*. The idea that they would try something new (and better thought out having benefitted from analysis of a couple of decades of mistakes) fills them with dread and they don't believe it will solve their problem. And, indeed, there's no question about it - it *is* impossible to deliver well-behaved toasters to organisations which (a) can't pick up the bill for high-grade commercial support and (b) are extremely reluctant to help themselves.

There are many other factors pressing on people - lack of time, lack of funding etc. Many of these issues are partially outside of individuals and organisations' control but it's rare that there's *nothing* positive people could do to improve their relationship with their ICT with the right support. But there's also a reluctance to gird one's loins and get stuck in and make a real effort to take control of the situation and manage their IT sensibly - people all-too-often want a magic bullet and there isn't one.

Added to this mix is a funding culture which encourages 'buzzword bingo', unobtainable goals and stressful audit culture and constantly exhorts people to 'innovate' whilst strenuously discouraging solutions which are not tested, benchmarked and audited.

Which brings me to my final comment on technophobia in relation to social networking and collaborative tools. From private conversations over the years I can only deduce that resistance to collaborative technologies can originate in a reluctance actually to *collaborate* in a human sense. The VCS has its share of control-freaks (it sometimes feels like rather more than its share). VCS culture positively encourages control-freakery - as the old adage goes, there's usually only 1 person in any organisation who actually *does* anything and often 3 people account for 90% of the activity in any given locality. These 'do-ers' will obviously be hopelessly over-worked and feel some justified resentment. The way they cope is to play their cards close to their chest to avoid wasting time on 'small-p' 'politics' with colleagues who are likely to make little concrete contribution. The problem here is not technology design, it's the culture of the VCS which needs some work.

The VCS technology sector has been making real efforts to develop design practices appropriate to VCS culture - the rest of the sector has to pick up its own end of the collaboration process and be prepared to change their expectations and practices in relation to it.

James Wallbank's picture

In response to Paula's observation that VCS organsiations are frequently quite technophobic, and perhaps also addressing one of Andy's original questions: "What factors affect the adoption of new technologies and practices by social action networks and organisations", I'd like to introduce the importance to Social Activists of autonomy, robustness and simplicity.

Social Action Organsiations frequently face resistance: either passive (eg: inertia of established systems) or active (eg: hostile responses from vested interests). Social Activists, through their personal motivations, instincts and the circumstance of resistance or opposition they find themselves in, become acutely (some might say excessively) aware of the need for autonomous, independent systems. (I take Paula's point that sometimes social action organisations are made less effective by control-freakery, but in circumstances of opposition this instinct may be wise caution, not unjustified stubbornness.)

The design of many technological systems take as a given that users will opt for the radical advantages of interdependent systems (conveniece, usability) over the inconvenicence of truly autonomous systems. Frequently, I suggest, VCS Social Activists will opt for an inconvenient autonomous system over a convenient, easy-to-use system that requires a dependency, and that in many cases their decision may be strategic.

VCS organisations with strategic goals also value robustness and technological simplicity: the necessity for many (preferably all) of their members to be able to fix a system when (note: when, not if - this is technology we're talking about!) it breaks. Address lists kept on paper can be photocopied, backed up, amended, re-ordered and searched by every activist - and if they get coffee spilt on them, all activists are able to take steps to dry out the sheets and make replacements for the hopelessly stained ones.

Meanwhile only a few activists in a group may be able to restore a backup or recover digital data, unless it's truly low tech. (As an example, this suggests that social activists might favour plain text data which all of them keep on their own USB keys, and synchronise with the master list on an ad-hoc basis, over proprietary databases even if they have a wonderful, simple web interface and are lodged on a sympathetic, professionally run, secure, backed-up server elsewhere.)

I suggest that only systems that successfully fulfil these criteria: robustness, technological simplicity and autonomy, will achieve wide take-up by social activists.

It's probably worth noting that almost all commercial software design (and much open source software design) includes elements that encourage dependency: either on a software supplier, an application service provider or a technical support service. It's also probably worth noting that frequently technological systems design applies the word "simplicity" purely to mean "ease of use", and doesn't count internal technological simplicity to be a significant design criterion.

larryjhs's picture

IMHO, there isn't antagonism...it's just basic issues, like a lack of time to learn new things....and how to work it through in organisations...

 

Larry

AndyDearden's picture

 

I do agree with Larry that there is a problem about
the time required to learn new skills (whether it is adoption of a new
technology, or learning to manage the technology procurement process). All of
us as individuals, or in our respective organisations need to trade-off between
acting in the present (getting the job done) and preparing for the future
(updating our skills / building capacity). When deciding how much to invest in
learning a new skill, there is a significant element of risk. "Is this
course / activity / learning going to provide enough benefit to justify the
investment?" Negative experiences with ICT initiatives in the past (such
as Paula describes) are going to result in scepticism in the future. Consequently,
organisations will want to see compelling reasons for adopting a technology
before they are likely to proceed. Paula’s point about the demand for ‘magic
bullets’ perhaps reflects this tendency – magic bullets are about high pay-off
for low risk and low initial investment (of time and energy).

 

But, I would argue, even if a group or organisation recognises
the potential benefits in adopting a technology, the issue then is whether they
can manage the activity in a way that really supports their objectives, or
whether they get fleeced again. The answer to this problem may not lie with trustworthy
technology providers and designers – they can only compete or attention with
providers who may be less interested in the success of the sector. Also, even
where technology designers are well-meaning, they may be blind to possible
conflicts of interest between themselves and their customer organisations. The
best way to address the problem is by building up the capacity of social action
groups in purchasing, appropriating and managing technology. This way they may
be able to make smarter choices, based on their awareness of what is possible
and responding to their key priorities.

To improve technology in social action, we should be
focus on the demand side, more than the supply side.

An interesting demand side project in Sweden is the UsersAward Network

http://www.usersaward.se/
- or

http://www.usersaward.se/home/ua/home.nsf/unidView/99C31A8550305DD6C1256E280035FC6E
if your Swedish is not so good.

 

Perhaps we could borrow these ideas.

 

--
Andy

Leonie Ramondt's picture

So why do you think user-centred design isn't integrated into standard practice yet Andy? Surely it isn't possible to design effective ict systems without it? ( It still takes a doctor within an nhs hospital, a month to send the average letter.)

There are still plenty of pre-digital people who don't look for the "enter"key. Yet computer literacy is becoming a basic requirement to live in the eu. This literacy can't be based around specific software / hardware, but needs to be around an understanding of generic and transferable principles and processes eg how to find stuff, understanding the different genres of tools (eg word, figures, data, media editing), exploring menus to find out how tools work. People only need to understand enough to be able to figure out a new tool and to debug their mistakes .

And is project management also a potential new literacy? Learning how to action plan and self-evaluate. The action research cycle is arguably the foundation for lifelong learning and participative community membership.

( i just checked wikipedia to make sure i was using literacy correctly and i like the def "Literacy is the ability to identify, understand, interpret, create,
communicate and compute, using printed and written materials associated
with varying contexts. Literacy involves a continuum of learning to
enable an individual to achieve his or her goals, to develop his or her
knowledge and potential, and to participate fully in the wider society.")

 

 

 

AndyDearden's picture

I think the answer to your question about why user-centred design is
not integrated into standard practice, is because the people who are
commissioning and buying these systems do not understand what is
involved in achieving user-centred design.

Most software
designers and developers believe and say that they are doing good
user-centred design already. Thus when evaluating tenders, all the
tenders will claim to be able to deliver systems that are 'easy to use'.

A very important part of user-centred design is iterative
exploration of ideas, and a willingness to change the design direction
in response to feedback.

Because the purchasers can't
critically evaluate the processes and techniques that the software
designers are offering them, software vendors who are applying good
practice can look more expensive, and more vague than vendors who are
less user-centred. Consequently, the purchasers end up awarding
contracts to vendors who are not following user-centred principles.

For
'off-the-shelf' software, the situation is similar, because it is
difficult to get a solid evaluation of the usability of software
before you take it out of the packet.

The situation is different in e-commerce, because bad web
design results directly in loss of sales. Consequently, the design of
e-commcerce sites has improved immensely in the last 10 years.

Training
young software engineers to be user-centred will have little effect on
what actually happens in practice, if the commercial drivers don't
prioritise use-centred practice. Therefore, to make a real difference,
we should start with better software procurement practice, better
software design practice will then follow.

 

Leonie Ramondt's picture

in response to your suggestion that procurement practice is key, how does a small voluntary org know what to buy? changes in technology are so rapid, (changes in practice so slow ;o) just this week i've found half a dozen tools that are really interesting, and struggled to implement a few of them in our specific context.

i just came across Sarah Robbin's piece on digital makeovers. "I get to talk to tons of people who know that there is something big afoot in the digital world and just wish they had someone next to them at the computer or in the office who could explain it all and help them develop strategies to make the best use of what is available. Non-profits seem to be a good target to start with because I think they could benefit the most dramatically from utilizing free online tools to maximize their budgets and mobilize volunteers." http://ubernoggin.com/archives/131

there must be effective ways to facilitate the adoption of technologies, (according to preferred learning styles) including through the use of them eg a pictorial narrated case study.

John Bonner's picture

There has always been an uncertain communication flow and uneven distribution of understanding between what consumers want from technologies, and what technology manufacturers think they should provide. Things such as lag times and aversion to risk form this divide. 

For consumers this takes the form of too much choice, reluctance to invest time or weighing up the cost benefit of learning new skills which makes understanding or predicting adoption of new technologies difficult. There is much posturing by manufacturers about being innovative, user-centred in approach but fundamentally and culturally they are inherently risk averse.  Risk is reduced by following small incremental steps in development which often includes huge amounts of implicit and unaviodable historical legacy built in to new products and systems. 

Texting is a good example – Nokia provided this as a way of reprogramming your SIM card and the number of characters was limited to 160 because the Finnish telecommunications systems carried an extra charge above 160 characters.  But once appropriated its primary purpose and use changed completely.  The inception of true texting was inaccurate, lucky but low risk and the lag time to success was relatively long. How could you predict that adoption process?  Along this ‘acceptance’ journey is a huge amount of fallout which previous postings have alluded to such as: ‘technophobia’, ‘inertia of established systems’, ‘purchasers can't critically evaluate the processes and techniques that the software designers are offering them’ etc. 

So my view would be in order to find effective ways to facilitate the adoption of technologies, we need to understand this gap by taking a deeper look at this uncertain communication flow.  One emergent trend seems to be making this flow less uncertain through stronger web-enabled collaborations between users (not consumers) and providers but I’m not convinced it’s the only way forward.

AndyDearden's picture

John - your point about risk aversion is very interesting. Though I began to think about the risk profile of voluntary organisations rather than the manufacturers. It makes me question whether voluntary organisations might tend to be risk averse, and if so, why that might be.

Thinking about the literature about Diffusion of Innovations (Everrett Rogers, 1962) and the later work 'Crossing the Chasm' by Geoffrey Moore  (1991)  there are two major motivations that seem to drive early adopters. Some people just like playing with new stuff and so adopt each technology as it comes along, whether or not it brings major benefits. But the more important group of adopters will take the risk of adopting new techniques because they hope to achieve a competitive advantage over rivals. Moore suggests that these people are often early in their career or in start-up organisations and are prepared to take risks in the hope of a big payoff.

In the voluntary sector, an organisation has to consider the opportunity cost of trying new techniques (e.g. possibly being drawn away from providing the key services that the organisation is committed to), and what advantages they think will be possible with the new technology. The problem is that competitive advantage may not be a big driver for the voluntary sector. Do voluntary organisations working in the same field feel that they are in competition with each other? On the other hand, the resources that need to be staked to learn a new technique may have to be drawn away from 'front-line' activities, which most organisations will feel is undesirable. There are similar debates about a possible lack of emphasis on investment in management in the NGO sector (see Lewis & Madon, 2004 Information Systems and Nongovernmental Organisations: Advocacy, Organisational Learning and Accountability. The Information Society, 20 117 - 126)

These two factors together may be a problem. 

I agree that better information flow between producers and users of technology may help. However, I contend that the point where we may have most impact is in improving the management capability of voluntary sector organisations, and finding ways to support exploratory risk taking that does not feel like it is drawing resources away from 'front-line' concerns. I would hope that the new Third Sector Research Centre that the government is proposing would be a place where this can be investigated.

 

John Bonner's picture

Completely agree Andy - innovation and risk are strongly linked but in very unpredictable ways.  The innovator's dilemma (Christensen 1997) illustrates this very well and argues that even if organisations understand and want to be innovative there are many cultural factors stopping them from doing so and, as you say, it tends to be the start-ups that succeed or at least cope with innovation.  I do think there is light on horizon for the voluntary sector by looking at some of the customer relationship models that are beggining to emerge primarily from the commercial sector.  There is a good DEMOS report on this - The Pro-Am revolution (Leadbeater and Miller 2004) which discusses how gardeners and DIY enthusiatists are beginning to shape commercial thinking.  So I'd put my money on improving information flow first then management capability.

Paula Graham's picture

I'm not sure whether assigning a low priority to ICT is the same as being risk averse. Small orgs live from hand-to-mouth and frequently invest gargantuan amounts of time into risky fundraising bids etc where, if you're lucky, maybe 30% of bids which can take up to a month to write will be successful. People will invest enormous amounts of time not only in financially unsupported and experimental 'frontline' activities but also in infrastructural maintenance tasks such as fundraising, networking, campaigning etc, often with only small hope of success. 

I think competition is a factor - the 'third sector' is often driven by internecine politics over turf and funding as much as anything else - but, despite the efforts of the Office of the Third Sector, orgs don't crunch numbers the way businesses do. I've yet to meet an SMO which has a serious clue what web stats mean etc - assuming that they have access to the back end of their stuff anyway. Funders will have set some kind of fanciful benchmarks and targets (frequently more to do with politics and ideology than efficiency) which everyone knows from the start can't be achieved and everyone fakes it as best they can. All the BS about 'marketising' the sector has just exacerbated the situation. People do manage to get stuff done, but under outrageous stress usually. 

The average SMO probably flushes anything up to 50% of its productivity down the tubes using inappropriate technical solutions, waiting for ridiculously slow kit to load, trying to fix stuff they don't have the training to deal with, trying to find emails etc, using the wrong sort of software or locked into obscure obsolete stuff that won't work with their newer stuff, not being able to print or email for days on end cos it's gone down and no-one can fix it till they find a brother of a friend of a cousin to volunteer temporarily etc etc etc. The reason for this is simple - they don't have the revenue income to pay for a decent commercial standard of IT support and they don't have adequate training for what they're trying to do. 

I agree, what small orgs need is the simplest possible solution - and, as far as possible, standard solutions. Standardisation would also simplify training and support infrastructures. Solutions need to be simple not only in terms of their user interfaces but also their technological design - they should be easy to support and fix too. Well-established, x-platform, community-supported, non-proprietary solutions which they can own and don't lock them in. 

 

Pamela McLean's picture

Hi Andy and everyone.

Sorry I was not able to visit this discussion earlier. I certainly agree with Andy's points at the start about 'socio-technical' networks; and the importance of the people; and making the most of the technology that is available. I also agree with the posting above about the problems of ICT support and training, and the need to make use of what is simple.

The use of ICT in the collaborative work I do is unusual in some
respects as it is in no way an "optional extra". I work with people in
other coutries and, without ICT, we simply would not be working
together. We rely heavily on email, yahoo groups, and chat/conferences. We use other things too, including Moodle (which we use in our own idiosyncratic way) but email, yahoo groups and chat are our "lifeblood".