A Community Collaborative and Continuous Direct Engagement in the Design Development and Deployment Process
We need a methodology and framework that acknowledges the special nature of ICT projects and enables the stakeholders to participate actively at all stages of the development process. One that can be easily understood as an application of the Open Source model to social initiatives and project design and development.
One that provides a horizontal approach and combination of methodology, techniques and tools for making possible the direct engagement of a community in the process of building their own development solutions and initiatives.
Rather than a top-down or bottom-up approach, we need to show the many ways of implementing a horizontal approach to project development, management and growth, the tools that can be used and the techniques to deal with diverse skills, interests and communication and participation levels.
In particular we need to address the following issues:
Please, keep in mind that CODE3 is an open approach to the development of Information and Communication Technologies (ICT) projects and environments that serve a community of users. The assumption is made that, although the users may have different skill levels and experience dealing with technologies, they have indeed access to it.
The Need for a Special Approach in the Development of Information and Communication Technologies Projects
The following articles explain the need for a special approach in the development of information and communication technologies projects and serve as an introduction to CODE3: A Community Collaborative and Continuous Direct Engagement in the Design Development and Deployment Process methodology.
Information and Communication Technologies (ICT) projects are different from common manufactured or consumer products in that they are not built through an expensive production line that requires physical resources difficult to change and modify.
If properly designed, changes to software, databases, interfaces, documentation, workflows, features and functionality can be done rather quickly and inexpensively (in comparison to other products).
ICT projects also serve a broader audience, both in geographical and cultural terms, and are subject to more fierce competition and consumer mobility.
In addition, ICT projects tend to be part of social spaces where people coincide, interact and communicate, highly increasing the relevance of community or social pressure and trends well above the individual preferences.
More often than not, what determines the success of an Information Technologies project is not how well it addresses the needs of the its users, but how well it helps the end user to be perceived by others and how well the user can fit in within a larger group and thrive within it.
There are countless of well documented cases of excellent designs that do poorly among the consumers they are meant to serve and are perfectly design for.
Think about the Mac computer, which for all the well deserved praise, usability features, gorgeous design, ease of use, remains with less than a 5% of the market share.
Think about the Palm handheld devices, light, fast with lengthy battery life, innovative interface and all the insight of usability wizards and how they were quickly displaced by the clunky but highly compatible Windows based PDA’s.
The end user is not looking for the perfect application, neither the simplest one, nor the fastest.
Actually no one can tell what the community is looking for until the community is actively engaged, not just probed or sampled the application, and the behavior trends start to form.
The very introduction of a product or service can actually trigger trends among a community of target audience. Often, this behavior trends have nothing to do with usability or features, but just as it happens in financial markets, the end user decision and preferences come out of “noise”, word of mouth, even plain copy-others behavior and the definite impact of early adopters and influential members of the community.
That is the only explanation for the abundance of clunky products and solutions we all deal with on a daily basis, from constantly crashing Windows operating systems to insecure e-mail protocols, and a broad range of functionality impaired devices and systems that include insanely unsafe credit cards, difficult to program remote controllers, junk mail and telemarketers.
A diagnose, design or research group may not be representative of the public being served, introducing biases in the observations and conclusions. The bias can come in many different aspects, some often unnoticed...
We should note that it can be as intrusive when members of these research, observation and planning groups are alien to the subject researched as when they are experts, skilled or experienced on it, for the latter may bring and try to impose their own preconceptions on the observations.
A research group often deals with a limited sample of individuals in a controlled environment both of which are expected to represent the Universe to be served. Even when large scale and in-place observation is made, very seldom can the actual whole picture be documented. Several limitations are intrinsic to the intermediated observation approach:
The sample of individuals may not always be representative of the whole. Just as the observation groups may introduce bias according to their own profile, even groups of individuals carefully selected often end up not being representative of the majority.
Think about it, look around your immediate environment and ask yourself: who is representative of others? Who is normal? Who, when observed and documented, would effectively represent your own preferences and behaviors?
Even when dealing with so called “personas” and made-up profiles, a true representation of users is not achieved or worst, unnatural combinations of aspects are done for the sake of inclusiveness. One quick validation technique can be to present these profiles to people and ask them if they identify themselves with any of these profiles and what differences they can point out from their own personal profile.
An immense amount of issues that affect the users’ conditions is not registered when behavior patterns are isolated and observation is focused on users’ responses to events and specific situations. Users’ decisions and preferences usually are part of a larger chain of events happening prior, during and after the focus of our observation and conditions that may change at random or cyclically.
Common examples are: work, business, study and family related cycles, having a bad day, the time of the month, the pressures of end of quarter financial reports, end-of-year efficiency evaluations, summer vacations, the stress of holidays, running out of funds as the date for the next paycheck gets closer, and of course unexpected things that happen everyday.
If you plan to serve just 1,000 people, you can count on at least one unexpected situation that affects the user’s behavior each day. That’s 365,000 situations a year that the research or observation group will not document.
Users behave differently in an isolated environment or when facing situations individually. Isolated, partial observation fails to document the common peer pressure and social trends the community as whole deals with on a daily basis.
It is common knowledge that users also behave differently when they know they are being observed. But less well-known is the fact that when asked for opinion, comments or suggestions, people tend to put on a different hat and anoint themselves as consultant trying to provide elaborate or unnatural responses.
Much better results are achieved by focusing on the users’ real actions and activities rather than on requesting focused descriptions or suggestions from users. So, instead of asking users how they would improve a product or process, more relevant responses can be generated by asking what did you do last week, yesterday or today, or how did you do similar things recently (not asking or revealing the actual subject we are addressing). This way the user can provide a depiction of an actual behavior and process rather than his/her personal dramatization of an ideal situation.
It is also common for research groups to focus in the quality of the recommendations they make (for this is what they will be evaluated upon) and not in the end product or final results.
It’s not enough to put together a great team, but this team needs to be monitored and double-checked once their work begins.
Beware of team members trying to translate or impose their pre-existing values, ideas and conceptions to the project. The greatest value comes from fresh ideas and new concepts that rise from the core of the needs and phenomenon being observed.
Unless research groups remain in continuous contact, interaction and exchange communication with the rest of the stakeholders, their separation from the actual development and deployment process generates a dangerous discontinuity and an unnecessary gap between observation, design, deployment and redesign.
How is CODE3 different from a Conventional Development Process?
CODE3 differs from a conventional development in that we are taking the traditional approach…