Latest Updates: User eXperience RSS

  • User Experience design: inviting the users

    May 30th, 2015

    (Adapted from my master’s thesis, Chapter 8.1.).

     

    Spool: Vision, feedback, culture

    Some promote approaches to usability practice alternative to User Centered Design. Spool (2008, 2009) calls the attention of the usability community to the risk of accepting methodologies blindly, of following them as dogma. Instead of measuring the results, he says, usability practitioners tend to focus on convincing people: “We are following the right methodology, so the product must be good”.

    Instead of UCD, which he argues never worked, but leads to people following the process blindly, he encourages what he calls informed design. This is a reward system for any design activity such that the effectiveness of the activity can be measured.

    Spool states having researched successful and unsuccessful interaction design projects. He claims having found three quality attributes successful projects had in common: a long-term user experience vision, a working feedback loop, and a culture of encouraging design failure.

    “Vision : Can everyone on the team describe what the experience of using your design will be like five years from now?” (Spool, 2008, 2009)

    The point here is that you have a larger goal, and when you take daily baby steps in your design, you can tell whether those steps are towards what you’re aiming, or not. This seems to also facilitate consistency, as everyone in the team are supposedly aiming for the same, shared goal.

    “Feedback : In the last six weeks, have you spent more than two hours watching someone use yours or a competitor’s design?” (Spool, 2008, 2009)

    The usefulness of feedback from actual users is rather obvious. Spool seems to stress the importance that everyone in the team have the experience of seeing real users use your design – supposedly, in order to remember just how differently real users perceived your design than you did.

    The reason Spool argues for six weeks as the maximum amount of time one should be allowed to not sympathize with users, is that according to him, after that time memories fade. In an online, distributed development environment, we want to regularly expose developers to perceptions about how users experience their designs.

    “Culture : In the last six weeks, have you rewarded a team member for creating a major design failure?” (Spool, 2008, 2009)

    Here, Spool argues that encouraging failure results in a culture of learning from that failure, instead of making contributors ashamed or afraid of mistakes. This also seems to facilitate creativity and trying also experimental design ideas.

    Regardless of the validity of Spool’s criticism against UCD, his propositions for things to include when designing for our actual users look useful, because they can be adopted seemingly without burdening the team with a heavyweight process.

    Open source, for example, has been considered loosely a form of distributed participatory design (Barcellini et al., 2008; Terry et al., 2010) . Participatory design is concerned about democracy at work and about democracy in design. In its roots then, its approach to design is quite similar to the ideals of open source (Nichols & Twidale, 2003), where transparency of the development process is a key value.

     

    Participatory design

    Contrasting participatory design with UCD where the focus is on researching the users so that designers can make better design decisions, participatory design seeks to empower users as decision makers in the design process itself.

    Researcher-designers are thus expected to facilitate user-designer cooperation instead of representing the users (Iivari, 2009) . Ehn (1993) approaches the question of communicating understanding about the intricacies of work, between designers and users, in terms of wittgensteinian language-games:

    “If designers and users share the same form of life, it should be possible to overcome the gap between the different language-games [of users and designers]. It should, at least in principle, be possible to develop the practice of design to the point where there is enough family resemblance between a specific language-game of the users and the language-games in which the designers of the computer application are intervening. A mediation should be possible.” (Ehn, 1993, p. 70)

    Within the domain of participatory design there are techniques, supposedly helping both users and designers see “other person as partner” instead of “other person as problem”, recognizing the differences in perspective of different stakeholders (Allen et al., 1993). Also in the context of an open source project, users and developers have different language-games. Participatory design explores the conception that making mediation possible between those language-games facilitates design and user participation through enhanced communication.

    Erickson (1996) discusses telling stories, considered perhaps an initial, less formal alternative to scenarios , as a similar “equalizer” of different participants of discussion, since storytelling requires no special skills. This comes very close to the challenge of involving users in development that seems to have a culmination point in open source development.

    An open source community indeed engages users at a level of discussion. Observation of users in their real working environment is difficult – and sharing those observations in a way that engages the community (such as a video narrative illustrating users’ environments) raises privacy issues – and again, is very time-consuming. Thus, the notion of a solution encouraging users to further participate in the design instead of being observed is a very tempting one.

    However, Iivari (2009) states that in the OSS project she studied, users do not have actual decision making power regarding the OSS but are left in a consultative role. This seems to be true of most OSS projects. Ultimate decision making is left to developers only, to whom a very limited amount of understanding about the users of the software is available in the forums of the community (Iivari, 2009).

    In OSS projects, user involvement is thin from the perspectives of both UCD (no usability practitioners to represent users) and participatory design (the few users who do participate have no true power over the eventual software). Warsta & Abrahamsson (2003) have studied the similarities of agile methodologies and open source development. Sy (2007) builds a case for agile as an efficient framework in which to employ user-centered design.

    Further research could reveal whether these approaches might also be applicable to open source development. So central questions, yet ones without clear answers, seem to include:

    • Is there a way UCD understanding could enrich the natural way OSS projects learn about their users?
    • Could usability practitioners plug in to the community’s existing means of communication, finding fruitful points of contact with the community while using methods favoured by UCD, such as ethnographies, to fuel design?
    • Or should we perhaps concentrate on what seems to come naturally to an OSS community, and only refine user research methods to be based on the open source community’s feedback?

     

    References

    Allen, C. D., Ballman, D., Begg, V., Miller-Jacobs, H. H., Muller, M., Nielsen, J., &

    Spool, J. (1993). User involvement in the design process: why, when & how? In Proceedings of the INTERACT’93 and CHI’93 Conference on Human Factors in Computing Systems (p. 254). ACM Press.

    Barcellini, F., Détienne, F., & Burkhardt, J. (2008). User and developer mediation in an Open Source Software community: Boundary spanning through cross participation in online discussions. International Journal of Human-Computer Studies, 66(7), 558-570.

    Ehn, P. (1993). Scandinavian Design: On participation and skill. In D. Schuler & A.Namioka (Eds.), Participatory Design. Routledge.

    Erickson, T. (1996). Design as storytelling. interactions, 3(4), 30-35. doi:10.1145/234813.234817

    Iivari, N. (2009). User Participation in ‘Configuring the User’ in OSS Development. International Conference on Information Systems (ICIS) 2009 Proceedings, Paper 199. Retrieved March 19, 2009, from http://aisel.aisnet.org/icis2009/199

    Nichols, D. M., & Twidale, M. B. (2003). The Usability of Open Source Software.
    First Monday, 8(1). Retrieved from http://firstmonday.org/article/view/1018/939
    Spool, J. (2008, April 12). Journey to the center of design (Slideshow with audio).
    Spool, J. (2009, March 19). Journey to the center of design. Presented at the SXSWi
    Terry, M., Kay, M., & Lafreniere, B. (2010). Perceptions and practices of usability in
    the free/open source software (FoSS) community. In Proceedings of the 28th International Conference on Human Factors in Computing Systems CHI ’10 (pp. 999-1008). ACM Press. doi:10.1145/1753326.1753476
    Warsta, J., & Abrahamsson, P. (2003). Is open source software development essentially
    an agile method? In Proceedings of the 3rd Workshop on Open Source Software Engineering (pp. 143–147). Presented at the 25th International Conference on Software Engineering.
     
  • The temptation to avoid usability work

    November 19th, 2010

    I am currently working on a private software project in a startup. I am involved not only in the design of the overall user experience, but also in implementation, since we are not many. The temptation to skip usability work is great for our team of two, and I too have to keep convincing myself why usability work is absolutely crucial to product success. Trying to find a succint enough way to express the basic needs for the work…

    Software engineers often question the value of usability work. It may be that a good designer could design a UI that does not create major confusion for most – if those designers already have lots of experience from usability testing in other projects. However, in any application that is done without explicit user research and usability testing targeted for the specific UI, you tend to have dozens of small confusing moments that make up the overall user experience and lead to a general ‘yuk’ reaction. Not to mention that if you don’t intimately know your users’ goals, you are likely to be designing the wrong overall application.

     
  • Master's thesis about Moodle and open source usability work

    September 30th, 2010

    A couple of weeks ago, my master’s thesis was approved, titled User experience design in open source development: Approaches to usability work in the Moodle community (PDF). The work documents usability work that happened for Moodle 2.0, so it was published just in time before that will finally get out. :)

    Summary of reactions: >60 Twitter tweets total including all links, grade Eximia Cum Laude Approbatur, honorary mention in the thesis competition (link in Finnish) of ACM SIGCHI Finland. The work continues!

    Update (Nov. 18 2011): This thesis won an honorary mention in the thesis competition (links in Finnish) of the Finnish chapter of SIGCHI ! Yay! Their statement of the thesis: “The jury thought this as a new type of thesis work, which successfully captures the phases and challenges in a multi-phased process of redesigning a Moodle community application. Open source communities have been little investigated from the HCI point of view, and the author successfully opens interesting new viewpoints with the thesis. The constructive Pro Gradu thesis has also resulted a tangible contribution.”

    Statement on Olli Savolainen’s thesis for M.Sc. in Interactive Technology titled User experience design in open source development: Approaches to usability work in the Moodle community, 82 pages, 5 appendices

    Free/Libre Open Source Software (FLOSS) development has become an important way of producing software in the modern society. In principle, the source code produced as OSS is openly designed, developed and distributed, and developers take part in the process voluntarily. The resulting code is freely or with little cost available to end-users. Often the software developers and users are from all over the globe, with the OSS community applying virtual forums for questions and user feedback and support.

    Taking part in OSS projects often poses challenges and obstacles to the usability practitioner whose main interest is to design the user interface so that it better fits the user needs. This is the topic Olli Savolainen deals with in his thesis. He reports on his personal motivation and continuous interest in improving the quality and, in particular, usability of Moodle Quiz. He also refers to his efforts and perseverance in gaining acceptance in the community before the changes he suggested after several iterations finally got accepted into the code base of Moodle 2.0. The description of the project is given on two levels. While reporting on the actual user centered design work done in the various phases of the project, another, more personal account of the challenges encountered on the way and reactions to them is unfolded. This kind of reflection is very valuable for understanding the norms, values and ways of working in FLOSS communities. These are important for gaining acceptance and recognition as an active FLOSS participant.

    The thesis is a well balanced and reflective document of things learned and practiced in the Quiz UI project as well as thinking about them in the larger framework of OSS development projects as described in literature. The background literature cited is extensive, ranging from books and journal & conference papers to blog and discussion forum entries and documentation. Furthermore, it is well utilized throughout the thesis.

    The vocabulary in the thesis is versatile and the language in general grammatically correct, though professional proof reading and language checking might still improve it. A minor drawback in the thesis is the structure that promotes the feeling of repetition, since some issues are first introduced in Chapter 2, but discussed in more detail in Chapters 7 and 8 with many cross-references between the sections. However, this is only a mark of thoroughness and consistency in reporting.

    Olli Savolainen has been involved with Moodle and the Quiz UI for more than three years, and his skills and expertise are apparent in the thesis. The main findings are based on personal work experience, and they smooth the usability practitioners’ path into OSS communities. The thesis work is relevant to future OSS development practitioners. It unites the fields of software engineering and usability engineering, bridging the gap still observed in computer science education.

    The work carried out by Olli Savolainen clearly fulfills the standards set for a thesis in Interactive Technology. We propose that the thesis is accepted with the grade eximia cum laude approbatur.

    At the department of Computer Sciences, September 9, 2010
    Saila Ovaska
    Eleni Berki

     

    (More …)

     
  • What is a course & the tools for having a great one (Part 1)

    May 11th, 2010

    See also: Part 2 – a design proposition for Moodle course front page

    (Update July 5th: Working on the follow-up article is taking longer than I expected. Bear with me, it is on its way! :)

    Inspired by Tomaz’ blog post, I did an informal interview with a business and marketing teacher I know. There are two separate points I want to make about the interview, so this article starts a series of two articles.

    I wanted to go thinking on a very general level of what are the tools that can be used for helping individuals learn on a given theme. I will here call the place to do such learning, a course.

    The questions I presented:

    What constitutes a course?
    What are the defining factors; what do you do on a course, how, and why? In other words, we playfully tried to generate a definition of a course.

    What kinds of tools can be used in order to facilitate learning of individuals on a course?
    Then I asked the interviewee to list the tools that can be used for learning in each aspect of the course’s definition. “Tools” are defined very widely here, as anything that can facilitate learning on the theme. They may sometimes have natural hierarchy, but here I want to perceive them such that each we can each still see the relations differently.

    The definition here is of necessity more narrow than that discussed by Tomaz – I believe that restriction helps when thinking about the design of a platform for courses.

    (More …)

     
  • Usability and Users' experiences in Moodleland @ iMoot 2010

    February 7th, 2010

    Preparing for presenting in iMoot, an online conference about online learning and Moodle, was an intensive process for me, but it paid off –  both in terms of learning while designing it, and because many of the presentations were really inspiring.

    Martin’s keynote also inspired me to create a small bug report in the tracker, my first one in months.

    #imoot2010 Twitter channel

    If you are interested, you can still register now for access to ALL the conference presentations, and today you can still join the discussions for a couple of hours.

    Usability and Users’ Experiences in Moodleland

    Quotations in the presentation:

     
  • Modelling concepts

    September 8th, 2009

    I am currently starting out on a course of conceptual modelling. One interesting phrase from the lecturer’s mouth caught my attention, while he was presenting an old diagram of  the concepts of a particular target domain to us. The idea was roughly this:

    Once the concepts have been defined like this, the rest is implementation.

    Software engineers are indeed aware of the fact that we must understand what are the concepts of the target domain, and their relationships. (They may express this understanding in different terms, though.) When we do, we can turn them into programming constructs, be they classes and objects, or procedural code (in Moodle, PHP pages and functions).

    What is missing from this image? The people using the system: the actual dynamics of what happens, the characteristics and the goals of the users (?), and the circumstances of the users. All of these are more abstract than implementation details and can not be described using programming code, yet taking or not taking them into account can dramatically affect whether software meets the actual needs of the people it is supposed to serve.

     
  • The power of simply having data

    July 6th, 2009

    From Contextual Design by Hugh Beyer and Karen Holtzblatt:

    […] Any change is a struggle. Engineers used to making what they are interested in feel constrained by having to think about what is useful and can sell. We all have to hold back the voice that tells us that producing code is progress – even if we cancel the project, even if it is the wrong code, even if we don’t know what would be useful to code. How does understanding work produce code? It is a struggle of personalities as we try to work in cross-functional teams to produce a shared direction. It is hard to remember that one smart guy working alone probably doesn’t have the whole answer. We simply have to realize that design is about people working together, and that’s what makes it hard.

    I remember the first design team I worked with. I barely knew what a computer was, but I jumped in to help a team designing a very large and expensive computer. They were stuck, not on the guts of the engine, but on the control panel! So I listened to six engineers arguing about how to lay out the switches: “Won’t we crash the system by accident if the remote selection is on the same switch as off?” “Oh, they’ll only do that once.” And whether or not there should be a key on the switch: “Security is important.” “No, it isn’t.” “Yes, it is.”

    As I listened, I realized that the team simply had no ground for their decisions. There was no way that reasoning and argument would get them to an answer. So I collected some data on how the panel was used: “Are you kidding? We won’t touch the remote. Someone might crash it.” “We turn the knob very, very slowly.” “Someone crashed it once, and the whole business stopped. No one touches that knob now.” And on security: “The computer is in a locked room; we don’t need it locked.” “Locking is a pain. We keep losing the key.” “We keep the key taped to the computer so we can find it.” “I catch my clothes on that lock; it sticks out.” The design was done in a day. We had a new switch for on and of and stopped agonizing about the key. I recently ran into a member of that team. He said he still talks about what happened 10 years later. The power of simply having data.

    Emphases and paragraph division (partially) mine.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
esc
cancel