Clare Stephenson-Faure B.A (Hons) Systems Analysis
Now at University of Life
Abstract: This paper is a delve into my life experiences which have informed my ways of working in the IT Corporate world over 23 years. Whilst at UWE I presented a paper at EthiComp98 at Erasmus University Rotterdam. What has changed since I wrote the original paper and what appetite is there for a diverse inclusive design framework fit for the 21st century?
Keywords: Information systems, radical feminism, people-centred, patterns, framework, user design.
Introduction
This paper will look at how things have changed (or not) from the conception of a paper in 1997 discussing user centred design to the evolution into an information systems framework suitable for the digital age. Along the way I will discuss my industry background and experiences, which have underpinned and confirmed my epistemological stance, that of a radical feminist. Today, more than ever, in an age of Code Biased AI, the rise of Neo-Liberalism and a Pandemic. Has silenced many women’s voices.
It is, therefore imperative we critically analyze and provide alternative methods to the standard patriarchal worldview.
Background – Me then and now
My main reason for entering the world of Computing was to provide a stable environment for my two daughters. It was also to show them that if you want something you need to work for it yourself and not rely on anyone else. My initial idea was to go into teacher training to study Design and Technology as this would suit my single parent lifestyle. On applying I was told as it was over ten years since taking my A levels I would need to undertake study in a technology subject. I looked around and found a part-time Computing A level which I studied at a local comprehensive school. In the first year I was pregnant with my second daughter, in the second year she was a regular attendee of lectures in her pram!
Off to University
My Computing A level studies ignited an on-going passion for all things computer design and encouraged by my tutor I looked at available computing degrees at the local university. It was then that I came across the B.A (Hons) Systems Analysis course at UWE. It was advertised as ideal for women looking to return to work.
In 1993 I enrolled on the four year course. The cohort that year had 10 women out of 64 students, the most women UWE ever had on a computing course. The majority of us were single parents looking for a way out of the benefit cycle and we were quickly drawn to each other, forming relationships that spanned many years. My life began to open up to the world of radical feminism through the likes of Francis Grundy, Cynthia Cockburn and Shoshana Zuboff.
Whilst we had some amazing inspirational lecturers, we also encountered sexism from a small minority. This usually manifested in our timetables not being as child-friendly as they were originally advertised and it was at that point that we were referred to as ‘Scary Bitches’ and so the ‘Flying Wytches’ were conceived.
Flying wytches
Whenever any groupwork was required the ‘Flying Wytches’ would work together in groups to the exclusion of the men. We started to realise how women problem solve differently to men when only in groups of women. The natural mode was for the women to acquiesce to the men in a group and women’s voices to be ignored or dismissed as too emotional. Men, in my expereince, deal in functional decomposition of problems, breaking problems down into their smallest parts and then building them back up again and for them knowledge is power.
We women on the other hand tend to separate problems into areas of investigation and will carry out many different areas of research at the same time, whilst reflecting and evaluating the outcomes. These would eventually pull together into a proposition agreed by all in the team. If you knew something that a colleague didn’t it was natural to share your knowledge and then build upon it together.
Course attitude!
The course covered many subjects; from programming and predicate mathematics to critical thinking and organisational behaviour. The British Computing Society when evaluating the category of degree award, defined it as an Arts not Science degree. They felt it veered too much towards Soft Systems and not enough emphasis was placed on programming and mathematics. A patriarchal view if ever there was one! I remember attending a talk by the then President of BCS who stated that women were better off at home than re-training in Computing.
This attitude spurred me on to develop my dissertation – ‘Women as designers, as important as men?’ In this I discussed how women were excluded from the design process due to; alienation of language, problem-solving methods used, exclusivity through gender and demographic, restrictive methods of knowledge elicitation and the limitations of working in mixed gender groups.
Again this is as important now as in 1997! When exploring the possibility of extending this into a PhD I was told it wasn’t a relevant subject as this was covered in Women’s Studies. Therefore there would not be any funding available for this topic.
Final year
During my final year me and a colleague (Julie Ward) were approached by our only female lecturer asking if we would like to put a paper together, exploring our ways of working and presenting an alternative approach to software design. So ‘People-centred information Systems Design’ or the taking the ‘PISD’ approach was born. This was a not so subtle dig at all those unnecessary patriarchal acronyms used to exclude women from the specialist subject that is computing.
We had carried out consultancy projects for two local charities by now and so analysed our working practices to create the PISD framework. The conclusion of the original paper was:
It is clear to us from the success of the two projects that both organisations gained:
- a more realistic view of IT
empowerment through being more effective and efficient in achieving their organisational aims
- an understanding of the importance of a cohesive IT and office procedures infrastructure to support organisational needs
- an understanding of the importance of communications and information systems – be they computerised or paper-based.
We did not set out to work in a style that was radically different from other developers, but merely worked in a way that reflected our life experiences as women. This metamorphosed into a unique working style, which has since been documented as our framework. Initially we were not aware that we were working in a style significantly different to other design teams, it was only on self-reflection and via comments from those around us that this became apparent. Could it be concluded that this is because we are an all-women design team? (Ward, J. & Stephenson, C., 1998)
It could be Rotterdam or anywhere
We were then privileged to be asked to present our paper at EthiComp98 at Erasmus University, Rotterdam by CCSR. Away from our children in a foreign country we felt we were experiencing ‘imposter syndrome’! Two single parents from council estates in Bristol, how could we possibly present our musings to such an esteemed audience? Would our opinion be of any interest to them or would they dismiss us as novices?
In fact it was an inspirational experience, and watching the other speakers at the conference inspired me. I wanted to research further how our work could be used in real-world scenarios to benefit not for profit organisations.
Back to school
After a few years working in the private sector I had the opportunity to return to UWE as a visiting lecturer for four and a half years, where I taught Information systems and Database management. I also became involved in the community computing research group and provided consultancy for National Council of Voluntary Organisations, VOSCUR, and Brandon Trust. Each year I supervised up to 4 groups of students who in turn would provide consultancy to local charities.
Career
For 23 years I worked for a variety of companies in very different domains. From software houses, through defence, transport, police authorities, financial services, social housing and insurance. Each had the same underlying malaise; top heavy middle-management, directives from on high, implemented by career hungry white Anglo Saxon males with a very particular worldview and way of working.
Now
I decided to turn left and I chose life. I gave up Corporate IT after nearly 23 years, bought a Classic Hymer, got rid of the majority of my possessions and waved farewell to friends and family. I have spent the pandemic on the Western Algarve, which for me has been an emotional rollercoaster, but ultimately restorative and life-changing.
Stuck with plenty of time to think and only Netflix for company, I was in despair at the technological determinism permeating through every aspect of society and was fearful of what the world will be like for my grandsons.
Watching the ‘Social Dilemma’ on Netflix, reignited my passion for what is happening in the field Information Systems in the 21st century. Even the term Information Systems has disappeared and been absorbed by the term Information Technology, which ignores the human element completely. It awoke the radical feminist in me to being angry that little if anything has changed since writing the paper. At that time, we wanted people to see we were mocking the very white male middleclass formal methodologies and frameworks being espoused. We wanted to create a framework that was honest, had integrity and inclusivity at its heart. It should be part of everything we do, not just in the design of systems.
I obtained a copy of the original paper from CCSR and re-read it with interest, how relevant would it be to the 21st Century in the post pandemic world, where disaster capitalism and neo-liberalism is rife.
Referring back to my previous work I realised this is now an opportunity to re-ignite the debate and update the old model with something more fit to this technological age.
Principles and the real world
In 1993-7 our working practices placed emphasis on qualitative rather than quantitative analysis. This we felt allowed for ethical considerations to become part of the solution space. We acted as agents of change, while using a “hands-on” approach within the organisations, because we recognised that mainstream formal methods alone are inadequate.
Many methods now available have been developed in line with larger more structured organisations and therefore the methods themselves are also of a highly structured nature; we see them as unsuitable for use in many organisations regardless of their size, structure or culture. What we propose as an alternative is our own people-centred framework, which draws on appropriate techniques from various methods as and when applicable. It allows for more flexibility and creativity in the design process and is therefore less restrictive. These principles are not to be taken as exhaustive, prescriptive or in any order of priority, but should be built upon and viewed as a guide.
(Ward, J. & Stephenson, C., 1998)
I decided to look back at my work experiences and compare with the original principles. How well did they map to my career?
Principle 1. The empowerment of people is more important than the efficiency of the organisation.
Only one organisation, Swindon Borough Council Housing Repairs and Maintenance, consisted of an all women project team, in a very male dominated domain. As women we had totally different ways of working and negotiating. There was less functional decomposition and more coordination and cooperation to work together for the greater good. It was a synergistic experience.
The difficulty was in gaining the trust and respect of the repairs and maintenance teams, who saw us as Corporate seagulls. These are so called experts who sell an overpirced system to an unsuspecting organisation. They walk away at implementation and charge a huge fee to come back and make any changes or further training. You have just been shit on from a great height!
Contractors are often brought in to oversee change with little or no understanding of their business domain. I worked through this issue by inviting the most vociferous opponents of the change program to be part of the user groups. I then involved them in the decision-making for the new technology they would be required to use.
At the end of the project all the admin staff had a clear idea of the end to end processes and their role within them. They took ownership of the systems and starting identifying future improvements. Empowerment leads to more effective and therefore efficient practices.
Principle 2. The provision of good information facilitates empowerment.
Poor quality imported data from an external source can cause mayhem to your systems and create utterly incomprehensible reporting. An example of this is a major defence company who had a bespoke requirements database. During regular design review meetings, reports were produced to show progress. I investigated these reports to reveal that the data being used was sometimes weeks if not months out of date. I produced accurate up to date reports and explained that people were not updating the cache from where the reports where drawn.
Principle 3. Communication, commitment, co-ordination, and co-operation should permeate any project. Control should not be the primary concern.
In the same project, there were multiple sites and therefore people, updating the same database with no co-ordination or oversight. Each site was quick to blame other sites for any mistakes. It was only through my persistence of requesting the database schema and a copy of the database to interrogate its structure and rules that I identified this major problem.
Following on from this I questioned backup procedures to discover the database had last been backed up three months ago. I requested a copy of the database to investigate the schema and days later the main database got corrupted. I had the most up to date version of the database available and the IT team had to use my CD to restore the database.
Principle 4. The organisational context of a problem situation needs to be as fully understood as possible before any systems design can take place.
I was not a solutionizer! I spent time understanding what was required of the sytem and would not push for immediate solutions. This caused many conflicts as I insisted on trying to understand the problem situation before making any recommendations – no quick wins to impress middle managers (well very few)! I often clashed with Senior Managers, because I would not be afraid to speak out if I disagreed with their approach. To understand the problem I would embed myself in the team and spend time almost as apprentice, observing and critiquing their current processes, whilst recording suggestions for how the processes could be improved or re-written.
When designing a Criminal Records system for the Isle of Man police authority, I would spend weeks at a time working with the civilian clerks to understand the issues they were facing when trying to use HOLMES, the preferred government system for crime and criminal recording. It was almost unusable due to the complexity of information required and the navigation between screens was unintuitive and at times nonsensical.
Principle 5. Analysts need to become a part of the organisation to fully understand the context.
AND
Principle 6. We aim to facilitate participative design, which should also be emancipatory by the inclusion of all groups in the organisation and the breaking up of power groups.
I carried a tool belt of techniques and methodologies from which I picked according to the problem situation. Naturalistic inquiry through observation and knowledge elicitation being my de-facto stance.
I was often the only women in the IT project team. During one meeting, comprising of 30 staff, of which I was one of the more senior and the only woman, one of my colleagues said “Clare, you can be trolley dolly and make the tea for us”. I replied that they would only ask me once as I intended to give them cups of coff-tea!
I often spent time in different departments that were to be affected by proposed changes and made myself available for any queries or criticism. I would participate in team events and at times even cover for people who were off sick, if the organisation was short-staffed.
Principle 7. The dynamics between people in the organisation need to be analysed and taken into account for any new system to work.
I identified people within the organisation who could take up the role of process owners / practitioners. The people on the ground of any organisation, are closest to the issues and bugs of any system. They have the business domain knowledge that is invaluable and provide the qualitative analysis of the pro’s and con’s of the systems they use on a day-to-day basis.
Principle 8. There is a need to take a bottom-up and top-down approach simultaneously. This could also be viewed as inside-out and outside-in development.
Being the voice of the client / customer when dealing with suppliers and technical teams. I never set myself up as the ‘expert’. I always remembered the person who would be using the system. All they want to do is print off a report without visiting umpteen screens to input data, and to trust in the data that is manipulated to produce the report. This is usually a woman who holds more knowledge than she is given credit for, and rarely gets asked what they think can be done to improve systems and processes.
Principle 9 As analysts we need to be sympathetic to the difficulties that occur when raising levels of IT awareness.
I developed the IT landscape model to be a logical representation of all the applications affected by and effecting any new system. This was achieved by displaying the interactions and data flows between systems and by showing what the inputs, outputs and triggers are. Often organisations have little understanding of how systems link together. When third party interfaces are involved it is particularly important for analysts and people to understand the constraints this can bring.
Working for a leading Transport company in the 00’s I discovered a Win95 machine hidden in the depths of a depot, which was never turned off or touched. Apparently it was running a finance program. Nobody in the depot knew what this program was for or whether it was interfaced to any other system. I highlighted this to the IT team who confirmed it was running a finance program that only ran on Win95. Fortunately this was updated as part of the project.
Principle 10. We need to continue to develop our abilities in alleviating people’s fears surrounding technology.
AND
Principle 11. The framework should evolve to suit the context of the problem space; it should be dynamic.
Organisations are often using only a minimal percentage of an application’s functionality due to lack of training. I discovered this leads to offline solutions being created in the form of spreadsheets and Access databases. It can result in excess data storage and duplication of data across multiple sources. Each piece of data should only be held once for each client. It is then down to manipulation and interrogation of the data to produce the required results. I would always analyze any application to better understand how much of a system was actively being used.
One finance organisation had key Personal Protection Insurance (PPI) customer data held on a number of Access databases, that kept crashing due to the large amount of data held. Someone, not from the IT team, then split this database into two separate databases in the hope that this would solve the problem, but then ended up creating a data protection nightmare. This was because they had not been provided with adequate access or training of the PPI system that head office had implemented, they created their own solution.
Principle 12. As analysts we should not walk away as soon as a system is in place.
I would always provide training sessions usually in the form of ‘Train the trainer’. This ensured sustainability of the system. I also developed User manuals which could be used for training, induction and help. These were designed according to the new processes and showed the end to end lifecycle. They were developed as ‘living documents’ which could be added to over time as the systems and processes evolved. This empowered people to pick up new processes more quickly and gave them ownership over their tasks.
Principle 13. A technical solution is not always the best answer.
Time and again I came across power groups who hijacked projects for their own agenda. Willy-waving was de-rigour and the chant was ‘My budget’s so much bigger than yours, you’re damn right it’s bigger than yours!’. They wanted bigger, better, sexier upgrades or systems. I analysed the current systems and determined they were fit for purpose. People were just lacking in the knowledge of how to make the best of the systems they already had.
This made me more determined to ensure all voices were heard and included in the design process. For me one of the most important things to achieve in any implementation is passing on knowledge and enabling people to develop and understand the end-to-end processes. By the end of the project these people need to have taken ownership of the new processes / systems and through training will be enabled to ensure continual business improvement.
Principle 14. The organisation should be left with a sustainable and maintainable system which empowers the people by providing the information they require.
In most, if not all of the business domains I worked in, people inhabited silo’s. They threw their work from one desk to another, to the next person in the process. There was no understanding of how the information got to them or where it came from. Nor did they know what happened to their part of the process once they passed information on to the next person. By providing continuous walkthroughs and reviews of the processes, people become involved in the design and development of the project and felt that they owned their processes. They were then more willing to participate in any change in the future.
Setting up and maintaining feedback loops in the form of user groups, steering committees, process walkthroughs, regular staff / customer newsletters and email updates, online surveys etc. is an important part of the communication of a project.
From Web model to People-centred patterns
The PISD paper introduces the concept of the Web Model (see figure 1) based on Harston and Hix’s Star Model (1989)
Taking this premise and integrating with experience gathered during the discussed case studies, we were always using a ‘hands-on’ approach within the organisation. From that we identified that mainstream formal methods alone were inadequate.
Figure Web model. Ward J, Stephenson C. (1998)
Web model evolution.
It was not until my final year that a female lecturer described software engineering as similar to a recipe or a piece of music. Things finally clicked into place within my understanding. This was revelatory to me. When studying my degree all metaphors used to teach Systems Analysis were masculine; football, car mechanics, gambling. These toxic masculine metaphors added additional layers of complexity. Not only did you have to understand the subject being taught, but also the analogy that was being used to teach the subject. These analogies were defined by men and aimed exclusively at men.
Recalling back to this time reminded me of a systems design lecture in which patterns were discussed and this metaphor seemed intuitive to me at the time.
Patterns are provided in standard layouts, these can be ubiquitous or customised according to individual needs. The metaphor of a pattern fits with an updated Web model. All key building blocks have the same properties, whether in the form of a pattern or the form of a spiders web. Referring back to the description in the original paper of the web model, I related how patterns work in the same way:
- It has a temporary nature however whilst in place is robust and powerful. Patterns are temporary but also critical to a design
- It is flexible and can fit into any space. Patterns can be created / modified to fit any size or shape
- It is portable and can be built anywhere. A pattern can be created in any environment and are used throughout nature and design
- It has autopoietic properties in that it has an effect upon the environment and is also affected by it through their interactions. A simple pattern can supplement the environment around it by providing a framework and external influences can lead to customisation and alteration
- It has main supporting threads on which the rest of the structure depends. A pattern consists of a core layout, which can then be added to as necessary. The core threads are, reflection, evaluation and monitoring.
The Framework
People are at the core of any design and are multi-faceted with many different worldviews. How can we incorporate this into any design process? I suggest the following framework as a starting point for further research and discussion.
Dr Frances Grundy’s (2020) talks about the everlasting failure of computer and closely allied professions to comprehend and rectify the paucity of women in the computing industry in her latest book, and I would like to think this framework will be a step in the right direction.
Figure people centred Patterns framework. Stephenson C. (2021)
As can be seen in figure 2, there are 7 core elements of a people centred pattern, from which hang other customisable patterns that can be picked and unpicked according to the problem situation.
- Gather
- Understand
- Build
- Develop
- Realise
Circling and joining these core elements are the key principles of:
6. Monitoring – is the project within its defined constraints and accessible to everyone?
7. Reflection & Evaluation – are we doing the right thing in the right way?
A project can start from any one of the elements and can move in any direction between patterns as long as when moving from pattern to pattern, the design goes through an reflection and evaluation phase and includes overall monitoring of the project.
Each of these patterns will be described in turn along with their associated sub-patterns.
1. GATHER
This pattern is about investigation of existing processes and practices. Naturalistic enquiry is a useful method for including multiple paradigms and worldviews to ensure inclusivity and diversity of knowledge is embedded in any system.
Naturalistic inquiry is an approach to understanding the social world in which the researcher observes, describes, and interprets the experiences and actions of specific people and groups in societal and cultural context. We need women researchers talking to women.
Hardiman (1987) describes ‘Naturalistic inquiry’ or ethnography as a way of gathering information and more importantly knowledge. It is the tacit knowledge that is hardest to elicit and inform any systems design. Hardiman researched the subject of knowledge elicitation, which are methods used to obtain information for systems. How gender biased are these methodologies? It could be said, they are still as gender biased as they were in the nineties.
The importance of knowledge elicitation should not be underestimated, but as always the issue is the demographics of the people who are involved. I would argue that the definition of experts needs defining here, is it the systems manager or the admin assistant who uses the system on a daily basis? All perspectives should be considered but importance of response is not hierarchally based. The decision should not be based upon job superiorty but upon value to the project.
1.1. Enrich
This is what any design should do – enrich our lives, not an addiction for likes and clickbait. Every application is organic and everchanging to peoples’ need and so it is vital to record any ‘nice-to-haves’ throughout a project. Cultural and legal changes require design to be adaptable and people can be demanding in their expectations. Low level clerical work is in the majority carried out by women, so shouldn’t the design for these systems be carried out predominantly by women?
Regular evaluation of each application is needed, using the questions element to raise any issues. There needs to be a feedback loop to ensure people feel part of the project and working practices, that their opinions are viable, valuable and matter.
1.2 Immerse
Immersion into an organisation enables a more diverse set of opinions to be heard in the design and development process. Most importantly do not set yourself up as the ‘expert’. You are there to learn their current ways of working and where the bottlenecks and gatekeepers are. Pursue lines of inquiry that allow the person to feel responsible for their work. Leave them with the knowledge of the current end to end processes and their part in it. Using this approach leads to the best suggestions for improvement.
If the above doesn’t reveal the necessary answers, it is time for evaluation of what you are trying to present. What is your reason for being and why would anyone want to use you and your services?
1.3 Questions
This also could be described as who, what, why, when, where and how! The best place to be able to ask the right questions is by observing what the person currently does. Follow their daily processes and discuss with them what the issues are: what goes well, what doesn’t, what information is missing, what reports are required and why. What is it they are trying to do that they currently can not? By immersing yourself in the organisation and developing the As-Is processes with the people involved, you can start the engagement process and build trust early on in a project. Conversations should be collaborative and cooperative. Different types of questioning and environments need to be considered to put people at ease and reveal their intuitive knowledge
2. UNDERSTAND
This is where the analyst should be using critical thinking to make sense of the organisational weltanschuung, as according to Peter Checkland’s Systems Thinking, Systems Practice (1981) Taking all the information and knowledge that has been gathered the analyst now needs to transform this in a logical manner through conceptual models such as As-Is and To-Be process mapping, developing an IT landscape and gap analysis.
To be successful this phase needs to be trans disciplined and multi-disciplinary (Grundy reference)
2.1 Now and future
As analysts, we need to understand the organisational context of the problem situation. From the information previously gathered further in-depth analysis should take place. Where does the organisation see itself in the future? What legislative restrictions are there? All businesses need a strategy to form possible futures.
2.2 Interfaces
Develop an IT Landscape of the current logical systems in use in the business, see example figure 3. This should show all interfaces between systems relevant to the project. Each interface should be recorded to understand what data is retrieved, manipulated or transformed and where it is stored. Each piece of data should only be stored once rather than duplicated across multiple sources.
Figure 3 Sample IT Landscape
2.3 People
Analysts need to understand the people involved in any system. This is tricky territory. We have a huge responsibility at this point to ensure there is a diverse range of people. All demographics should be included not just the people groups we are most familiar with or those people who are sent to us (often referred as useless user syndrome – explain) There should be no people bias, not just the white anglo saxon tech cul-d-sac weltanshuung. There is no ideal customer / client / person. We need to design systems which are accessible to all and represent all.
Stop engaging with the tech giant models of promoting hate, misogyny and mental illness and move towards a lighter gentler future. Use all the C’s (communication, commitment, co-ordination, and co-operation) of principle 3 and add compassion to the list!
3. BUILD
It is this element that should refer to Jakob Neilson 10 Usability Heuristics for User Interface Design (1994) principles for interaction design. These are heuristics in that they are broad rules of thumb and they not specific usability guidelines.
This is as opposed to locker room methodologies such as Agile. Using sprints and scrum meetings to reduce development time, but completely lose sight of the bigger picture.
Using task analysis, new ways of working can be developed. It may be at this point that critical path analysis and / or gap analysis is required to identify issues in the project and enable the analyst to be proactive to any situations arising in the design.
3.1 Material
Drawing on analysis from now and future states, it is time to draw all the material together to produce coherent end-to-end processes. The earlier in a project the test strategy is defined the better. What resources will be available? How will testing be carried out? By who?
The testing element always ends up being the only training in my experience! Consequently, very little time is dedicated to developing a test strategy and creating diverse data sets to test against. Little automation testing occurs in reality unless in large complex systems. Automated testing is only as good as the person who designed it and so we can encounter the same problems we are trying to resolve.
3.2 Situations
It will become clear by this point that certain types of groups of people will emerge. These groups will have very specific routes through the system according to their needs and knowledge. Others will just be scrabbling about in the dark in the hope they can produce something! Now is the time to visualize these routes in the form of journeys.
The methods used to elicitate the knowledge should acknowledge that users are people not customers or clients. There needs to be more naturalistic enquiry and tools for explaining back to the people what is being suggested or developed.
3.3 Mock-ups
This is dependant on the quality of the requirements that have been gathered up to this point. Mock-ups can be created at any time in the framework as they will be re-visited as more knowledge becomes available. The important thing here is the ‘Look and Feel ‘of the application. The human computer interface and flow of screens should match the end to end processes and be intuitive to the person using the system.
4. DEVELOP
“Significantly, some of this work has pushed forward political agendas for gender equality, in particular, by focusing on women’s agency and use of ICTs for emancipatory ends. Yet, in spite of these contributions, and the evidence provided, gender is often rendered invisible in macro-theorising about social and technological change and indeed in many empirical studies of ICT use.”
Eileen Green ‘Gendering the Digital’(2013) The Impact of Gender and Technology Perspectives on the Sociological Imagination
This is the part of the framework where everything is pulled together, the graphical user interface (GUI) is agreed, the reports defined and testing is underway. Now the project team need to hold the hands of the people, as they see the results of all the previous analysis and design. There needs to be agreement of the rollout process. Is it a soft launch, staged rollout or a big bang? What support is required and most important what is the business continuity plan if all or part fails?
Working for a council rolling out the use of hand held devices to repair staff, on Go Live day, the server had a catastrophic failure. Luckily we had the foresight to print out a weeks worth of job sheets the previous day. We were then able to hand these out to staff to get them working whilst we investigated out how to fix the problem.
4.1 Reporting
What information needs to be displayed? What outputs are required and in what format?
Defining reporting requirements at this point is crucial to ensure the system can manipulate the data in the required format. It should be clear that reports are produced on a regular basis for regulatory and legislative purposes. There are also queries which are daily ad-hoc requests for information and any effective system should allow people an intuitive front end for query handling.
4.2 Testing
Developers should ensure all priority requirements have been met. They test that the system does not create any fatal errors when running the program, in the sense the person cannot progress from this point.
Unit testing is carried out by developers, who will only prove the functionality works, not the process is followed and is effective. Developers have a tendency to test that their modules work as per the requirements they have been given. They do not try to break the system. However this is the main purpose of any testing – to test the unpredictable and ensure test cases cover all required scenarios.
Functional Testing is carried out by analysts to ensure navigation through the screens is as previously defined and that all validation and verification performs as expected.
User Acceptance testing needs to test the full end-to-end processes, required reports, user access levels etc. It should also use real life data the most complex of cases to really test the system. It is also important to make the number of scenarios and test cases manageable to the size of the organisation. This can be done by rationalising. Any error messages produced should be meaningful to the the person using the system at any point in time..
4.3 Ownership
Involve the people at every stage of the project, so by the end they feel in control of their processes and systems. Hold process walkthroughs and provide as much information to people as possible. Bulletins on noticeboards, e-newsletters, opinion polls, surveys etc. At this point in a project there should be a clearly identifiable set of stakeholders, from all walks of the the business. Some will be early adopters of the systems and their enthusiasm should be harnessed to bring others on-board.
5. REALISE
“We are a growing vanguard of young and old who share a sense of righteous indignation and a demand for action. “Let there be a digital future,” we say, “but let it be a human future first.”
The stage is set for the big work of 2021 and the decade ahead. If we are to bend the arc of the digital back toward the light, we need public education, democratic mobilization, and political leadership. We need the creativity and courage to revitalize our frameworks of human rights, laws, and regulations for a new epoch. This next decade is pivotal. It’s all hands on deck.” Shoshana Zuboff (2020) The Age of Surveillance Capitalism
This is where all the hard work comes together and the patterns are complete. For now! The applications have been built and signed off by the the project people. Social media accounts are created and a strategy for the maintenance of these platforms has been written. This is the time for reviewing the work to date, identifying future requirements and any lessons learnt, and to release the applications into the real world.
5.1 Training
Give people an overview of the end-to-end processes so they can understand where their role fits into the bigger picture.
Use real life cases to train people, with most complex scenarios to ensure all areas are covered. Train the trainers, so information can flow throughout organisation. Produce meaningful manuals that describe according to work processes and tasks. These should be living documents that can be added to over time. If produced well they can be an induction manual as well as help guide.
When putting screenshots into manuals make sure it is dummy data – never use client data!
5.2 Sign-off
This is the formal or in some cases informal handover of the updated systems to the business. Any major bugs are identified and resolved and the business is able to operate as required. Any outstanding features not implemented become the next phase of the project and feeds into the enrich pattern.
5.3 Review & upkeep
Regular reviews of the new systems should be held as some of the functionality will only become apparent periodically, monthly returns for example. Analysts must be available to help resolve any teething problems and to carry out additional training or bug fixing if necessary. Often it is not until a system is used in anger that some of the built in ‘features’ identify themselves as bugs requiring fixing. It is only be having a period of time after the sign-off pattern with analysts still providing onsite support.
Greenham Women Everywhere
Since starting this paper I had the pleasure of working on a project for Greenham Women Everywhere and their 40th Anniversary March celebrations. This is a predominantly all-women organisation whose aims are to archive the amazing radical feminist material from the original protests and actively support new activists in their struggles. I was able to use my framework as a reference and left the users with a more interactive, sustainable system, that they now own and can improve themselves in the future.
‘I just wanted to say a massive thank you for all the amazing work you’ve done on the website. It really is transformed and you’ve set us up so well to continue developing it.’
Vanessa Pini Greenham Women Everywhere Producer 2021
Suggested research from original paper, are the questions still relevant?
Possible continued research was suggested in original paper, can these questions be answered in 21st century? The following were suggestions in our original paper, all of which I feel are still relevant:
- how can this framework be developed further and is there a need to be recognised by the more formal scientistic fraternity to be given the opportunity to do so?
- should ethics be the principal factor considered in a problem situation?
- some feminists argue for the reclamation of the use of language in technology, how could this be achieved?
- how could ethnographic and knowledge elicitation principles be incorporated into the requirements process to enable multiple perspectives and expertise to emerge?
- what would the results be of systems designed by teams of women analysts/designers in a variety of organisational settings?
Conclusion
Being asked to write this paper to celebrate the 25th Anniversary of CCSR has been an honour and allowed me to evaluate what I have achieved in my career. I have always followed my framework consciously and sub-consciously and believe it may be of use to others to pick up and create their own patterns.
Although women in computing is still a valid area for research there are a new generation of feminist cyber warriors out there on the frontline of daily trolling. They, like me do not give up and continue sewing their own patterns believing there is a better way and are continually working towards this to inspire future generations.
References
These are internet references as I did not have any access to the Academic texts.
Button, G., Crabtree, A., Rouncefield, M., & Tolmie, P. (2015). Deconstructing ethnography. Towards a social methodology for ubiquitous computing and interactive systems design. Dodrecht: Springer.
Grundy, F., & Genestine-Charlton, G. (2020). Righting the Wrong: Closing the Gender Gap in Computing. Lulu.com.
Green, E., & Singleton, C. (2013). ‘Gendering the digital’: the impact of gender and technology perspectives on the sociological imagination. In Digital sociology (pp. 34-50). Palgrave Macmillan, London.
Guba, E. G., & Lincoln, Y. S. (1982). Epistemological and methodological bases of naturalistic inquiry. ECTJ, 30(4), 233-252.
Hardiman RJ (1987), A Naturalistic Methodology for Knowledge Engineering in Proceedings of the first European Workshop on Knowledge Acquisition for Knowledge-based Systems, Reading University.
Hartson, R. (2003). Cognitive, physical, sensory, and functional affordances in interaction design. Behaviour & information technology, 22(5), 315-338.
Hix, D., & Hartson, H. R. (1993). Developing user interfaces: ensuring usability through product & process. John Wiley & Sons, Inc..
Rex-Harston, H., & Hix, D. (1989). Human-computer interface development: concepts and systems. ACM Computing Surveys, 21(1), 5-93.
Ward, J. & Stephenson, C. (1998) People-centred information systems development. EthiComp 98
Zuboff, S. (2019). The age of surveillance capitalism: The fight for a human future at the new frontier of power: Barack Obama’s books of 2019. Profile books.
Funding: There has been no funding for this research, as I am not currently affiliated with any University. This paper has been written from a motorhome in Portugal, with limited access to information
Acknowledgements: I would like to thank Prof. Bernd Stahl for giving me the opportunity to write this paper. To Julie Thornton and Stephen Rockcliffe for their support and patience.
Copyright: Copyright remains with the authors. This is an open access article distributed under the terms of the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.
