Header image of misty mountains, communicating layers of complexity

Tag: design

  • Designing for Real Users

    Designing for Real Users

    Recently, I spoke with a colleague who was serving on a design committee for a new company intranet site. He kept coming back to the problem of determining the placement of the CEO’s vision message, as the interface was starting to look rather cluttered. A senior marketing consultant was the lone holdout against this obvious vanity item, to which the design team felt compelled to give pride of place, at the top of the landing page. It occurred to me that few people were likely to be interested in this item, or to understand its significance in terms of company strategy. Yet it was being allocated valuable real estate and other items – which intranet users would need to access frequently – were being buried in a complex menu as a result. The design group did not even consider allowing users to configure the landing-page layout, so they could place frequently-accessed information pages at the top.

    Design is not a one-size-fits-all activity. We are all the product of our experiences ~ no two people have the same perspectives. It is a common anti-pattern to design for people-like-us. 

    After all, aren’t web designers the most interesting, creative, and representative people in the world? 

    Yet most people are less interested in the mechanics and visual impact of web design than the average web designer. Yes – emotional design is important. But not as important as enabling the user to achieve the purpose of their visit by making content easy to find – and interesting.

    Good design focuses on customer visit objectives, to hit the sweet spot in the push vs. pull tradeoff. Content design and navigation tend to be driven by the firm’s business model – what designers want to push to the users of our website. This results in unnecessary frustration, as the user tries to achieve the purpose of their visit. UXD sweet spot design balances the firm’s push factors with customer pull factors: what they need from the site, why they need it (their visit objectives), and how they expect to locate it (comparative design exemplars). You can only discover these things from user research, rather than lazy-UXD.

    Figure 1. Hitting the sweet spot between push vs. pull in site navigation

    It’s easy to design a site that directs your users to the products, areas, and sales possibilities that your company wants to push.
    Not only is this less effort than worrying about what your users came here to find, but your manager will be pleased, as you are focusing on what matters to the company.
    Your users? Not so much …
    …In fact, they may try to avoid your website altogether, visiting only when they really have to …

    In conclusion, we tend to design systems and websites with a one-size-fits-all interface, where the priority and placement of various information is determined by designers. There are two problems with this approach:
    1. These decisions are often political, or driven by those who shout loudest.
    2. The worst anti-pattern in design is to design for people-like-us. Most people do not think like web-designers. They have different priorities and interests, based on the work that they do.
    We should let users decide what order they want to see which items, in interface design. Give them a configurable interface, so they can arrange things to suit their own way of working – and priorities.

  • Why is design improvisational?

    Why is design improvisational?

    We talk about design as if it were fixed: as if there were one best way to design everything. We celebrate designers who produce especially elegant or usable artifacts as if they were possessed of supernatural powers. Yet design should be easy. It is the application of “best practice” principles to a specific situation. We can observe how the users of a designed artifact or system work, then design the artifact or system accordingly. Why does that approach fail so often?

    The key issue is the problem of “the problem.” Designers are taught a repertoire of designs-that-works: patterns that fit specific circumstances and uses. Experienced designers are capable of building up a deep understanding over time, of which problem-elements each of these patterns resolves. So they can assess a situation, recognize familiar problem-elements, then fit these with design patterns that will work in these circumstances. The problem comes when a designer is faced with a novel or unusual situation that they have not encountered before. Novice designers encounter this situation a great deal, but even experienced designers must deal with emergent design in a novel context. In these circumstances, designers iterate their design, as shown in Figure 1. They identify (often partial) problems, ideate/conceive relevant solutions, give those solutions form with a prototype, then evaluate the prototype in context. This often reveals emergent user needs or problems, that are explored in the next iteration.

    Figure 1. Iterative Design

    An important aspect of iterative design is that iterations can occur within cycles. As designers succeed or fail at successive designs, they accumulate experiential knowledge, that allows them to assess new situations quickly and

    to understand which design elements will work or fail in that situation, looping back to remediate the design as they spot logical flaws and gaps in the design. The problem with this is that (as the Princess said) you have to kiss an awful lot of frogs to get a Prince. An awful lot of people end up with really bad designs, because their designer did not recognize elements of the situation well enough to understand which pattern-elements to implement. If you are   really unlucky, you will also end up with one of those designers who feel it is their mission in life to prevent the end- user “mucking about with” their design. If you are lucky, your designer will recognize that it is your design, not theirs. They design artifacts and systems in ways that allow people to adapt and improvise how they are used.

    Which means that design-goals are constantly changing between iterations, as shown in Figure 2. The designer starts by designing for the subset of goals they understand. As they explore and test the design with users, they become aware of new requirements and so modify the subset of goals they are designing for. As part of this process, they also discard any requirements that are no longer associated with perceived user needs.

    Figure 2. Goal-emergence in design

    Improvisation takes a multitude of forms. It might be that a user wishes to customize the color of their screen (because the designer thought that a good interface should look like a play-school). This may not do much for the function of your work-system, but it does mean that your disposition towards work is a heck of a lot sunnier as you use it. Or it might be that the information system which you use expects you to enter data on one step of your work before another. You might be able to enter data into a separate screen for each step, reordering the steps as you wish. More usually, you have to enter fake data into the first step, then go back later to change this, once you have the real data. This is because IT systems designers treat software design as a well-structured problem. A well- structured problem is one that contains the solution within its definition. Defining the problem as a tic-tac-toe game application means that you have a set of rules for how the game is played which absolutely define how it should work. This is fine if everything goes to plan, but a huge pain for users when it does not. The only discretion left to the user is how to format the results in a printed report, which is not much comfort if your whole transaction failed because you were prevented from going back to change one of the inputs. This is not rocket science – developers need to design systems that let users work autonomously.

    Business applications tend to present wicked problems . A wicked problem cannot be defined objectively, for all the reasons identified in Figure 3. Solving a wicked problem needs business users and stakeholders to agree on what problems that they face, their priorities in resolving these, and what their change-goals are.

    Figure 3. Constraints on Design Posed by Wicked Problems (Rittel & Webber, 1973)

    A wicked problem can be understood as a web of interrelated problems. It is not always clear what the consequences will be, of solving any part of this mess. Some of the problems may have “obvious” solutions. But implementing  these solutions may make other, related problems worse or better. This is why iterative design is central                      to resolving wicked problems. In general, stakeholders don’t understand what they need until they see it. So solutions must be designed flexibly, for changes to be implemented as the consequences are realized and to permit adaptation-in-use by stakeholders and users. People are infinitely improvisational. They develop work-arounds and strategies to manage poor design. But, as Norman observes, why should users have to develop work-arounds for poor design? What is it, about the design process, that leads us to such constraining IT systems, interfaces, and work procedures that are based on the system design, rather than system designs that are based on flexible work- procedures?This website reflects findings from my research studies and reflections from my own experience in design, to discuss some key underlying principles of design, to explore how the design process works in practice (rather than how we manage it now, which is based on unsupported theoretical models), and to present a way of managing design differently. … Improvisationally.

    References

    Norman, D. A. (2013). The Design of Everyday Things: Revised and Expanded Edition. Basic Books, New York.

    Rittel, H. W. J., & Webber, M. M. (1973). Dilemmas in a General Theory of Planning. Policy Sciences, 4, 155-169.

  • Coordination, Cooperation, and Collaboration

    Coordination, Cooperation, and Collaboration

    I was musing about the differences between these three concepts. They are not explained clearly in any resource I could find (although many people take a stab at this), so I thought I’d try bending my brain around the problem. The three types of collectivity appear goal-oriented (as in, sharing a common purpose), but there are big differences between the ways in which group members interact – and the reasons for these types of interaction.

    Cooperation is when people share ideas about how to work, or share effort to complete the work towards a shared goal, which is understood in common. People work together to complete a task that would be much more difficult to complete individually. Cooperation often involves deciding how to divide the work between individuals in a group for an optimal outcome – for example, in software or organizational change projects. Work may be divided laterally (each person takes a separate slice of the work towards a deliverable), vertically (each person takes a separate deliverable), or performed collectively, where people share the effort required to achieve a goal (for example, analyzing a business process that is too diverse – involving too many stakeholders – for one person to explore in a reasonable amount of time).

    Coordination is the organization of work-tasks across individuals to achieve a complex goal that requires analysis (breakdown into subtasks) before it can be addressed. People work together towards a common goal within an agreed timeframe, even if they don’t understand all the tasks required at the start. They organize their activities around a schema, which provides a model of the parts of the work to be done. They divide their labor on the basis of this schema, with individuals or sub-groups completing each part, which is assembled into a whole once all relevant parts have been completed. They may collaborate to perform shared subtasks.

    CCC2

    A Work Breakdown Schema (WBS) Used For Coordination of Work

    Coordination may be organized around interim deliverables, which are completed individually from subsets of the work-schema, then assembled once all the parts are complete. The underpinning concept to coordinated work activity is that of a plan – a plan of work, or a plan of how the parts of the whole are organized. This is used to guide the coordination of work, across individuals and across groups. For example, in traditional software project management, work is coordinated around a work breakdown structure (WBS).

    Collaboration is the pooling of effort, to achieve a joint goal, which everyone in the group of coordinated workers may not understand in the same way (so this is not a shared goal – subgoals may emerge through the processes of discussion and experimentation over how to perform the work). People work together, taking different parts of a task, to achieve a goal that, if not understood in common at the start of the process, will probably be understood in the same way by the end. Collaboration requires trust (that other people will work towards a common goal), but it is more adaptive than coordinated work – instead of agreeing a model of the task in advance, collaborators develop a shared model of the task deliverables as they collaborate on the task. Working together increases the amount of shared understanding between people, which allows them to improvise and adapt the plan of work to contingencies that arise. So both goals and work-practices evolve as shared practice increases shared understanding between collaborators. Software developers, working on agile software projects, collaborate in analyzing how to coordinate their team’s work around a feature-breakdown then coordinate team work around each person implementing the next feature in the backlog. Finally, they collaborate around integrating the feature components into a coherent prototype system.

    Coordination schema, where sub-goals are merged to achieve an integrated outcome

    Collaboration schema, where sub-goals are explored and defined independently, then merged to achieve an integrated outcome

    Collaboration is organized around sub-components (or sub-goals) of the planned outcome that are defined separately. Each sub-component emerges through discussion and experimentation, so the parts are managed autonomously by delegating them to different people. It is only at the integration stage that the shape of the whole solution can be understood.

     

  • Designing Social Media Platforms For Online Learning

    Designing Social Media Platforms For Online Learning

    Recently, I have been using a new social media platform to run one of my classes. The idea was, that as we are studying social informatics, we could study the effect of using social media on our own workflows first hand. I also thought that – in these days of daily Facebook and Twitter use – a social media site would add some relevance to the class. My thinking was that the “right-brain” expression that Daniel Pink  extolls as critical to motivation in the 21st Century – the design, narrative, synthesis, empathy, play and sensemaking skills – would be enabled by the use of social media (Pink, 2005). The site has a WIKI, blogs, discussion forums, and an interactive chat facility. I was proposing that we used Google+ hangout for short class discussions by video. For the first week, I set students the task to post to the WIKI, to post to their own blog, to locate some web readings, and to join Google+ if they had not already done so.

    By Thursday (from a Monday start), almost all of the students had posted to the discussion forum. Several had asked me questions by email. But no-one had posted to the Blog or the WIKI. By Friday, two of the more technologically-literate students had made blog posts. But most of the activity was still on the discussion forums – and only three students had provided me with Google+ contact details. Then I started to question my own assumptions. All of the students had used Blackboard for their online course access, which revolves around an asynchronous discussion board. So they were used to interacting via an asynchronous forum. I had assumed that they would be excited to use more “social” media for class interactions or for sharing what they had discovered about the topic. But how did this fit into their idea of how they would behave in an online class? Very badly. Most students sign up for online courses because this provides them with choices about what to do, when. They have a low learning-curve for using a discussion forum. Anything else is hard work.

    Clay Shirky talks about the cognitive surplus that is available from zillions of digitally-literate people with mundane jobs and untapped creativity. He argues that this expresses itself in the groundswell of free, open source software initiatives and in the crowdsourcing phenomenon (Shirky, 2010). But graduate students with a full-time job are already using their cognitive surplus in grappling with new areas of learning. My assumption that they may have some left over for experimenting with social media may be false. The problem is that the learning curve gets in the way of the “right-brain” expression that I wanted to encourage. I may need to rethink how far experimenting with social media is constraining people’s’ ability to express themselves.

    References
    Daniel Pink  (2005) A Whole New Mind: Why Right-Brainers Will Rule the Future. Berkely Publishing: New York.
    Pink (2005) Revenge Of The Right Brain, Wired Magazine, Feb. 2005.
    Clay Shirky (2010) Cognitive Surplus: Creativity and Generosity in a Connected Age, Penguin Press: New York.
    Clay SHirky (2010) An Extract From Cognitive Surplus. Wired Magazine, Business Video, June 16, 2010.
    Clay Shirky and Daniel Pink  (2010) Cognitive Surplus: The Great Spare-Time Revolution. Wired Magazine, June 2010.

Spanning islands of expertise

Copyright Notice:

All contents copyright © Susan Gasson, 2011-2025. The contents of this website may not be sold, incorporated in other online materials, or used in any form without the express consent of the copyright holder. Permission to use will normally be given for bona fide educational use.

Site Menu

Related Sites

Site design copyright © Susan Gasson, 2025

Designed with WordPress Twenty Twenty-Five