InnovationAfrica

Shaping the Future Today


Living in Cocoons: Understanding User Centered Research and Design

We as technology creators are often faulted of sitting in our own within the iHub or in our  need and customer base. So, before you decide to make that next ‘amazing’ app that does wonders, please consider the following!

We all agree that one of the most solid validation points of a product must be its acceptance in the . We can classify a product or service as being either for a selected niche or for mass . Regardless, it is extremely important to be able to address an intended ’s specific problems or needs in order to acquire buy-in for the product or service, from these users.

We as technology creators are often faulted of sitting in our own cocoons within the iHub or in our bedrooms and developing for an imagined need and customer base.

On twitter part of this haphazard developing has been coined by an interesting name- mVitus – m(obile)-something in Swahili- after the fact that there is a new m-app for just about everything. And yet, we are the first to complain about the lack of adoption of local solutions by the market or the great barriers to entry in these markets. What we forget is that we create our own barriers by not concerning ourselves with the end-user of our product and many times our ‘solutions’ end up entirely off the mark- by being useless!

We are not short of development and creative talent here, that is a given, but a reason for constant failure is a lack of understanding of the market. This is a most unfortunate situation, considering the amount of resources and time committed to these projects.

Innovation is a change in the thought process for doing something or new stuff that is made useful. The goal of innovation is positive change, to make someone or something better. -iHub

The most obvious way of identifying actual needs and innovative solutions to address them is by just interacting with the intended or perceived end user of your product or service to gain more insight into their problems, their wants and their wishes. More formally, this is known as conducting user-centred research and design: a developer simply puts the end user of their product at a pedestal and bears in mind that image of the end user throughout the process of development.

The Design Thinking Process

Why is this so necessary though?

We often hear of Apple’s story: how Steve Jobs decided that the market did not know what they wanted and with his very innovative products, would teach people what they really wanted

 “The consumer doesn’t know what he or she wants until we make it.” Steve Jobs

He is a lucky chap, this worked for him.

For the rest of us, not quite…! What compounds this further is the fact that the African ICT market has a mind of its own, having completely discarded traditional ways of adopting technology; we almost completely skipped the PC age. So how do you keep in touch with such an unpredictable market base?

By the adoption of user centred design methods.

There are a number of structured ways and published schools of thought on how to go about this, most of which seem common sense but not adhered to. We at propose the method of Design Thinking which is precisely a process of user-centred design in problem solving.

As an approach, design thinking taps into capacities we all have but that are overlooked by more conventional problem-solving practices. Not only does it focus on creating products and services that are human centered, but the process itself is also deeply human.
Design thinking relies on our ability to be intuitive, to recognize patterns, to construct ideas that have emotional meaning as well as being functional……The design thinking process is best thought of as a system of overlapping spaces …inspiration, ideation, and implementation. - Tim Brown & Jocelyn Wyatt (Stanford)

This approach is so important, it may have been outspoken but there has never been a better opportunity to apply this in the African Market than now.

So how do we go about it?

  • We need to get to the core of the market through empathy, to answer the questions: “What?”, “Why?”, “How?” so as to gain deeper insights into the eventual users of our product or service. These insights are supposed to assist in coming up with innovative solutions.
  • We can then identify the need we find most promising to design a solution for and look back to the users we empathized with previously to determine the context in which they relate to this problem/need.
  • We follow up on this by generating ideas for the solution we would like to provide and here, we are encouraged to think radically -far and wide- so as to build a good basis for prototyping. We then conceptualize innovative solutions and their possible outcomes coming up with various alternatives.
  • A rough prototype (or a Minimal Viable Product) is then developed (with very few resources) and will become more comprehensive as we empathize more with your users and reiterate the above steps to form newer and better ideas. Prototypes are a good way to test the functionality of a proposed product before going into the market full blown.

All this need not be an expensive process; in fact, research in general does not necessarily have to cost you a cent.

iHub Research’s objective is to bring information on technology and its uses to the technology community, enabling entrepreneurs and developers to make better decisions on what to build and how to build it.  We plan to work closely with the UX lab to instil this culture of user centred design in our local tech community and will hold regular sessions on how to effectively develop and design for your user.

Code4Kenya is one of the best examples locally using a design thinking approach to ensure that the applications formed at the end of this experiment on Open Data have mass usage. Why? Simply because the end user will be involved from step one!

 

 

Go to Source

Tags: , , ,

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>