Cartoon of a toddler driving a car

How system designers and social scientists can complement each other's work

It’s all too easy for a wall to rise between people and systems when designers fail to take account of motivation and behaviour, warns John Berry.

I recently started a company with my wife, Sue. She’s a social scientist and I’m an engineer. For her, life is about identities and behaviours. For me it’s inputs, outputs and transfer functions. To give me a foundation for people management consulting, I enrolled on a Masters in occupational psychology. Brave at my age, I know. Especially when some bright young lady on the course identified me as a ‘keeper of the meaning’, a term in careers theory describing later life stages.  I read research papers and comment on a forum. Simple. But over the past year it’s got me thinking how annoying it is that disciplines are so very similar, yet isolated. Involvement in a couple of large electronic system specifications hammered home how damaging this stove-piping can be to organisations.

But before I go on, my tutors would be aghast if I didn’t share some definitions. Customers buy capability and go on to exploit that to meet organisational aims. Capability comprises people and systems. People are characterised by individual competencies and behaviours. Systems comprise processes and policies. So, right at the start, we have a wall between people and systems.

We engineers rejoice with such a definition: systems don’t involve people. We can specify the system with assumptions about the competencies and behaviours of the people who will both drive and derive benefit from it. But context is everything - people give systems context.

System specifications I’ve been involved with have been for radio spectrum management and monitoring. They’re implemented as systems worldwide. Organisations that publish suggested standardised specifications without definition of those behaviours and competencies have it wrong. Such specifications are too easy to pick up and exhort as gospel. And too easy to apply out of context.

People exhibit behaviours. Behaviour results from motivation and personality. Users have hugely differing personalities: some are open to ideas, others are not; some are conscientious, others less so. Things get more complex if we add culture to the mix: some make decisions collectively, while in others individuals are happy to decide alone. With these differences, how can we assume that all people are the same and that one system will fit all?

People acquire competencies and it’s here that standardised specifications really fall down. Competency describes the organisation’s readiness for the implementation. With modern spectrum-management systems, competencies must be built from the foundations of electronic communications in many countries as regulators strive to bypass earlier technologies.

Not embracing user competency in system specification can be like giving a child the keys to a BMW: nice to show off with but no good to get around! To assume pre-requisite competencies when they don’t exist risks the user being denied ability to exploit the system. Systems have greater potential benefit than simple automation and cost reduction. Electronic systems can transfer knowledge.

Competencies describe user skills and knowledge, while pre-requisite competencies can be defined by the system supplier in preparation for system-specific training. System-specific training will fail if the foundations are not there. After BMW ‘system-specific’ training, the child will know how to honk the horn but won’t be able to drive. Systems designers also need to consider the motivation of the users.

So where does this marrying of engineering and occupational psychology lead us? We must recognise that users are unique. A system designed for one group may not fit the characteristics of another. Not all would-be users have the same competencies. Systems must be specified for the competencies existing or the existing competencies changed.

When regulators, standards bodies and suppliers write standards, they should consider the diversity of users and offer advice on how to customise the standards for differing user behaviour and competencies.

We engineers love coming to conclusions. Our psychologist colleagues prefer the debate, without necessarily reaching a decision. The real message is that the disciplines must work together to make sure that when ‘men meet machines’, there’s harmony and organisations get what they want from technology when it’s implemented in real environments.

John Berry is a director and consultant with TimelessTime ( A Fellow of the IET, he began his career as an engineer before moving into management, working with companies including Thales.

Recent articles

Info Message

Our sites use cookies to support some functionality, and to collect anonymous user data.

Learn more about IET cookies and how to control them