This week was the end-of-term exhibition at the TU/e (for a good view of the poster and card set, I recommend this post). Normally, the exhibition marks the end of a project as well, but since this is my graduation project, I get to carry on for one more semester after this. Yey! Continue reading
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 change to discuss my methods cardset. Continue reading
I just stumbled across this great piece from 1994 by usability guru Jacob Nielsen: Guerrilla HCI: Using Discount Usability Engineering to Penetrate the Intimidation Barrier. Bar some words that have gone out of fashion, the piece is still incredibly relevant today. A great insight was this list of the awareness-levels of software development companies about user experience.
- Usability does not matter. The main focus is to wring every last bit of performance from the iron. This is the attitude leading to the world-famous error message, “beep.”
- Usability is important, but good interfaces can surely be designed by the regular development staff as part of their general system design. This attitude is symbolized by the famous statement made by King Frederik VI of Denmark on February 26, 1835: “We alone know what serves the true welfare and benefit of the State and People.” At this stage, no attempt is made at user testing or at acquiring staff with usability expertise.
- The desire to have the interface blessed by the magic wand of a usability engineer. Developers recognize that they may not know everything about usability, so they call in a usability specialist to look over their design and comment on it. The involvement of the usability specialist is often too late to do much good in the project, and the usability specialist often has to provide advice on the interface without the benefit of access to real users. Continue reading
A living collection of user research methods that are sound like fun and make you want to get up and organise them. Later I will analyze them and and learn from them, to design my own collection of methods to go into the new Inclusive Design Toolbox.
Technology Tea Party
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.
Reblogged from Applying Agile Principles to Design | Webdesignledger.com
Chances are, you’ve heard about the myriad ways in which the agile development method is changing the face of software development. If you’ve worked in the design world, you may even have given agile a try yourself, or at least found yourself the victim of an overeager manager who wanted to “shake things up” and “think outside the Waterfall box.”
The agile method is, indeed, an effective and schema-breaking approach, one that’s far more relevant in today’s cash-strapped, fast-paced work environment than more traditional, slow-moving, risk averse, top down production strategies, which often fall behind the market. But, while related, software development isn’t web design, and the agile method isn’t necessarily a solid template that should be applied to the design process. Instead, it’s better to take the wider agile philosophy to heart and apply the method’s core principles strategically.
Let’s take a look at just what agile is, why it might be good for designers, and how to adapt it accordingly.
Route [root, rout] noun, verb, rout·ed, rout·ing.
1. a course, way, or road for passage or travel: What’s the shortest route to Boston?
2. a customary or regular line
of passage or travel: a ship on the North Atlantic route.
3. a specific itinerary, round, or number of stops regularly visited by a person in the performance of his or her work or duty: a newspaper route; a mail carrier’s route.
verb (used with object)
4. to fix the route of: to route a tour.
5. to send or forward by a particular route: to route mail to its proper destination.
In this post, I make a start with exploring the first visualisations of the toolbox. The aim is to create something that gives a quick and clear overview, but also gives the user the opportunity to easily make a selection based on their project needs. More detailed information can be added through augmented reality such as Layar