Posts Tagged ‘design research’

Design research as a method for discovering & understanding the world around us

Variously known as User Centered Design (UCD) or Human Centered Design (HCD), the fundamental philosophy underlying the designer’s approach to problem solving is that of discovery – “figuring out how to make something that will work in this context”.

Innovation, invention and novelty rarely have pre-scripted processes due to the as yet unknown, and often, uncertain nature of the outcome. The design process acknowledges this by embedding various techniques for discovery of the problem space as well as the possible solutions.

These include:

  1. Exploration –  1. the action of exploring an unfamiliar area. 2. the thorough examination of a subject.;
  2. Prototyping –  an early sample, model, or release built to test a concept or process or to act as a thing to be replicated or learned from;
  3. Iteration –  the act of repeating a process with the aim of approaching a desired goal, target or result (2);
  4. Experimentation – a procedure carried out to verify, refute, or establish the validity of a hypothesis. May vary greatly in goal and scale, but always rely on repeatable procedure and logical analysis of the results.

This post was inspired by a twitter conversation with Dr Dan Lockton. It is the first of a series of explorations on our adaptation and evolution of the methods available for design research as tools for discovery and understanding where data may be inadequate or non-existent such as the informal economy in emerging African economies.

Please use the category UCSD to discover more on this subject.

Understanding at the bottom of the design pyramid

source

Before we can give form – and it does not have to be a tangible product but could even be a service, a business model or a strategy – to what we wish to do, its not enough to step back to just the function level, one must step even further back to envision the whole before one can even begin to pinpoint what the requirements are.

And before we can envision the potential solution space within which the requirements can be framed for the ultimate manifestation in the form of design, we must understand not only the what and how but also the why, when and where.The most powerful concept in this diagram, imho, is the fundamental importance given to ‘understanding’.

Without understanding – which in this sense could be seen as ‘grasping or grappling with the big picture’ – one cannot begin to envision or see what the possible directions or paths that ‘form’ or ‘function’ can take. Without the big picture view, the perspective into which all the disparate bits fall into – if not falling into place, then at least within understanding or at least coming to terms with – we cannot see far enough ahead in order to shape or manifest tangibly any plan of action or even, next steps.

I have said before that I believe that design is inherently a philosophy or a system of values first, and it’s implementation, in whatever form, second. Understanding the ecosystem in which your actions will take form comes first, which then leads to vision – only then can you begin to get down to the brasstacks of framing requirements and finally the design. We very often jump straight to the design – or the action – and this hierarchy of the steps required prior to any design is a useful reminder of the other 90% of the iceberg.

This approach has been the basis of my work in the little known geographies and the uncertain conditions of the emerging consumer markets of the developing world.

User driven innovation planning and strategy in development

It was with feeling of satisfaction that I read Eric Smallberg’s recent post titled “Thankfully, ICT4D is Now About Strategy and Implementations, Not Technovelty” where brings up the lessons from failure and the shift in emphasis of technology based development projects and social enterprises.

He says:

Richard Heeks wrote about the early history of these changes in a paper entitled The ICT4D 2.0 Manifesto. Mr. Heeks explained the difference in earlier attitude between the first programs, and the projects in the field today. Early programs relied upon “technovelty” and focused more on spreading access as quickly as possible instead of on thoughtful implementation. He generalizes the outcome of those early projects into a few words: “failure…and anecdote[s].” Often programs would return with great stories about how technology had changed one individual’s life, without analysis to the larger effects. Past the promotional materials, positive impact became difficult to assess, which in turn led to many projects today being framed by sustainability, scalability, and evaluation.

Reading through, I can honestly say that this applies to all technological innovations aimed at the rural African, the base of that pyramid or for social impact. For most of 2012, I’ve been involved in assessing the current status of a social enterprise in East Africa, and these points from the article resonate:

As speakers talked about their projects, and the effect they had, they all listed off their lessons learned, including:

  1. “Building trust and credibility is crucial”
  2. “Research tech context before strategizing”
  3. “Technology should serve the goal, not be the goal”
  4. “Try to find out if there is an alternative to technology”
  5. “Use the technology that is already in place to limit training needs”

Sounds amazingly like basic advice for user driven innovation, minus the jargon, from the frugal engineer’s point of view (#5 Why reinvent the wheel when first prototypes abound?)

I hope this shift in thinking, as observed among the ICT4D practice, finds a way to influence the startups and social enterprises in more basic services such as cooking, lighting, defecating et al.