Once upon a time, there was a group of people, who lived in a small town in an industrialised part of the Netherlands. They were all older than 60 years, some of them even in their 80’s. They told a story about how they were going to sports clubs and classes, and how the people there became their close friends, sometimes as close as family. They spoke about the difficulty they could sometimes have in getting to the class, or how they would forget. Then these people told us about this magic box, that would alert the sports club of members who wanted to come but could not, and that friends would then call them or pick them up. That the magic box would arrange for carpools and shopping to be done by their sports friends, all at times when these friends were going anyway. And how they were happy with the possibility to do the same thing for someone else another time. Continue reading
If only today’s technology were simpler! It’s the universal lament, but it’s wrong. We don’t want simplicity. Simple tools are not up to the task. The world is complex; our tools need to match that complexity – From: Living with Complexity by Donald A. Norman
If a design oversimplifies the interaction, it gets restricted and can lose functionality, or worse, lose the interest of the user. Earlier in the design of the toolbox, working with a company with little previous user research experience, I made the mistake of presenting an iteration of the toolbox, that was too simple, and it was perceived as condescending. Continue reading
Requesting a custom method via the above link would help me develop the Inclusive Design Toolbox. You will be asked some questions about your project so I can pick the best research method for you, and your target users. Each method will be hand made, so I can learn what aspects are universal and how this process can be automated.
Please share this post with others!
This week I present an early iteration of the Inclusive Design toolbox that I have been working on. It will be a toolbox that can help companies in IT with awareness about Inclusive Design. This iteration of the toolbox is still quite basic, but in principle already useful. Continue reading
A while ago, I had an interview with an IT-company. A few weeks later I went back with my new methods cardset and some improved ideas, as I was wondering what the director of that company would think.
Just before that, I attended the latest Co-Design Café session at Capital D, a monthly meeting where designers and design-researchers exchange knowledge and experiences with co-design, where I also had the chance to discuss my methods cardset. Continue reading
A living collection of user research methods that sound like fun and make you want to get up and do them.
A Technology Tea Party is conducted in settings appropriate to the participant group, for example in community centres for elderly. Emphasis is placed on making the setting informal and relaxed with locations being selected based on participants’ ability and willingness to travel. Tea parties begin with a discussion, followed by interaction with technology probes and a final discussion over tea and cakes. The provision of tea and cake helps to create the desired informality, and seems to encourage participants to express their real opinions, rather than providing socially acceptable responses.
Tea parties are audio recorded, transcribed and analysed using template analysis to identify themes. Demographic information is collected using questionnaires.
These requirements can be see as scaffolding, defining the design space, showing where the end product will be and giving an idea of the scope.
Director of a technology-driven IT company with 10-20 employees
This is an IT company that often works with non-profit and governmental organizations, next to more commercial clients. Their products are internet-based and are built up from a self-developed framework. Interesting bits from the interview:
- Their products are tested on usability by a test panel
- Often clients come with a complete plan including routing and style sheets, and the company only brings in user tests during the development when they feel the proposed plan needs to be changed or improved
- Some clients have their own front-end specialists, who will do their own user research before building the specifications
- References Apple’s Human Interface Guidelines
- A user research toolbox would be helpful as a mark of excellence towards clients
- Within their company there are two programmers that also work on the front-end, they would be the actual users of the toolbox
- Empathy with the end users is important when programming software, a toolbox can be a good way to support this
- The toolbox should contain really practical methods such as guidelines and checklists, and should not bother the programmer too much with information that is not useful at that moment. Continue reading
As I discussed in an earlier post, the typical user-centered design cycle described in Wallach and Scholz’ paper  comprises the following five categories: Scope, Analyse, Design, Validate and Deliver. In each iteration, in principle all five categories are used, but especially Analyse, Design and Validate.
In particular user involvement in the Analyse phase, I find interesting. Often user tests or evaluations are only done after the design process, missing an important opportunity to get inspired by and empathize with the users, before starting the design process.
“Deviating from common practice in usability textbooks – where methods of usability evaluation are subsumed under the umbrella of the validation phase – we are also addressing these already in our description of activities in the Analyse phase.”
But even before that, in the Scope phase, a common ground should be established between stakeholders, including users. The major goals and constraints of the project need to be identified and discussed at a qualitative level to set the agenda for the Analysis stage.
“Art lives from constraints and dies from freedom” – da Vinci
Without establishing clear borders of the design space, there is a risk of overdesigning aspects that later become unnecessary. Technological and user-contextual constraints need to be analysed and understood early to provide common ground for the different stakeholders.
In experience design, setting goals is asking ‘Why’ questions . Why would a user want a certain benefit or feature? For example, you might want to design a chair. The chair itself is a feature. Being able to sit, is a benefit of a chair. But why would you want to sit? Perhaps it is to give you a moment of relaxation after walking all day. Perhaps it provides you with a comfortable position to have dinner with your friend. These are experiences. I personally think that experiences are the very best goals to set, being a designer.
Instead of talking about User Centered Design as an opposite or competitor of Experience design, I think Experience design provides great stories as starting points and original ideas, that can become great products if thoroughly developed through User Centered Design. It all starts with Experience design, but it needs to be followed up with User Centered design. Continue reading