Tag: design patterns

  • 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.

  • Design Methods as Performative Objects

    Design Methods as Performative Objects

    Brown and Duguid’s (2001) concept of a “network of practice” has been niggling away at my consciousness. The idea is that a collection of people are enabled to understand each others’ work because of commonalities in practice, but not to the extent that a Community of Practice creates shared ways of framing and performing work:

    “we include under the rubric … groups whose members, to the extent that they have common practices, are able to read and understand one another’s work. Disciplinary networks of practice cut across heterogeneous organizations, including, for example, universities, think tanks, or research labs. Professions make up yet other such networks of practice, where again similar practitioners, by virtue of their practice, are able to share professional knowledge through conferences, workshops, newsletters, listservs, Web pages and the like. … different networks of practice cut horizontally across vertically integrated organizations and extend far beyond the boundaries of the latter. Along these networks, knowledge can flow.” (Brown and Duguid 2001, p. 206)

    So create closer bonds than organizational membership, spanning organizational boundaries. If the type of intersubjectivity that derives from shared practice (i.e. what Polanyi calls tacit knowledge) does not underpin a network of practice, what does? This rings true, given the observation that IT professionals identify more with the interests of their profession than with their organization (Chou and Pearson 2012). Which brings me to the second property of networks of practice:

    “it is important to note that networks of practice may also inhibit the flow of knowledge. As Lynn et al (1996) show, professional networks will occasionally work to resist the spread of ideas felt to be inimical to the interests of the network’s members.” (Brown and Duguid 2001, p. 207).

    So how do networks of practice share knowledge? Brown and Duguid have an explanation:

    “We have used the notion of networks of practice to explain leakiness. This is not, we have suggested, simply an inherent property of some kinds of knowledge. It does not result from making knowledge explicit and so tradable. It is, rather, a function of the common underlying practice, which creates social-epistemic bonds. Where practice doesn’t prepare the ground, knowledge is unlikely to flow.” (Brown and Duguid 2001, p. 207)

    But this is not very satisfying when members of the network are not co-located. Surely, “common underlying practice” includes some form of shared framing as the basis of those social-epistemic bonds? I thought back to the work of Howard Rosenbrock (1981), who explains that IT professionals’ paradigm of system design with the aim of making users interchangeable results in deskilled, repetitive, and unfulfilling jobs for those who use these systems. He explains:

    “The paradigm is transmitted from one generation to another, not by explicit teaching but by shared problem-solving. Young engineers take part in design exercises, and later in real design projects as members of a team. In doing so, they learn to see the world in a special way: the way in fact which makes it amenable to the professional techniques which they have available.” Rosenbrock (1981, p.6),

    So we have design methods as a form of performativity, embedding ways of framing job design, as well as creating a shared design practice that ignores users’ psychological and motivation needs. But surely, IT professionals are continually learning, acquiring new skills and approaches to system design? It would appear not:

    “The fact that most IS professionals learn the bulk of their technical skills during college or immediately afterward encourages recruiters to focus on technical skills for new hires. IS professionals generally learn non-technical skills in the workplace.” (Lee et al. 2001, p.28).

    All is not lost. Lee et al. (2001) go on to observe

    “IS professionals generally learn non-technical skills in the workplace. And because these non-technical skills are so valuable in the long term, new hires need to possess the aptitude to learn these skills. This may help explain why recruiters prefer graduates who took more MIS classes than those who concentrated strictly on computer science courses.” (Lee et al. 2001, p.28).

    How can we remedy the perspective that leads to such impoverished outcomes? As Rosenbrock observes, IT systems can be seen as a replacement for human ingenuity and skill, or as a way of supporting these. We have a choice to automate or to informate work (Zuboff 1988). We also have two chances to undermine the automation-on-rails approach taught in so many methods classes. Back to the network of practice idea. IT professionals have a network of practice with really strong bonds. We can teach IS methods more thoughtfully to those who return – for ongoing education in Masters degrees, etc.  Finally, we can mobilize the network of practice, on LinkedIn and elsewhere, to ensure that IT professionals are aware of the types of skill and knowledge-preserving approaches to organizational system design that we would want to see used in our own organizations.

    References

    Brown, J.S. and Duguid, P. 2001. “Knowledge and Organization: A Social-Practice Perspective,” Organization Science (12:2), pp. 198-213.

    Chou, S.Y. and Pearson, J.M. 2012. “Organizational Citizenship Behaviour in It Professionals: An Expectancy Theory Approach,” Management Research Review (35:12), pp. 1170-1186.

    Lee, S., Yen, D., Havelka, D., and Koh, S. 2001. “Evolution of Is Professionals’ Competency: An Exploratory Study,” The Journal of Computer Information Systems (41:4), pp. 21-30.

    Rosenbrock, H.H. 1981. “Engineers and the Work That People Do,” IEEE Control Systems Magazine (1:3), pp. 4-8.

    Zuboff, S. 1988. In the Age of the Smart Machine. New York NY: Basic Books.

  • Design as Bricolage.

    Design as Bricolage.

    When attending a boundary-spanning design meeting the other day, I was reminded of how important pattern sensitization is to design. When we explore a new problem-situation, we structure it according to the patterns that we perceive in that situation. This is why experienced designers are so much better at design than novices. It is not that experienced professionals are sharper, or better at design — but just that they have a wider repertoire of patterns to call upon. As they recognize familiar elements of the situation, they fit partial solutions to those elements. Problem decomposition is not hierarchical, in the sense proposed by Alexander (1964), but convergent. The problem-space and the solution-space co-evolve, as designers explore these in tandem (Maher and Poon, 1996; Maher and Tang, 2003).

    Back to the meeting.
    A group of strategic managers (including the systems people and the business process change manager) were examining how to revise business process support for a routine workflow. The problem that they faced was that this had been adapted by several workgroups (whose representatives were present) over time. So each of these managers had a different perspective of the problem, depending on what each group was trying to achieve. The customer support group were frustrated that they could not access all of the customer information in the system, but had to call another group to obtain missing information. The order-processing group were frustrated that they could not track the progress of an order without having to run three separate IT applications. The sales and marketing group were incensed that not all of the latest products and services were publicized on the website. None of these people – including the IT group managers – could see that these were related problems. They spent hours debating the fields to be displayed on the screens and the detailed reports needed, without realizing that the workflows were related.
    The breakthrough came by accident, when the Process Improvement Manager was mapping the “requirements” on a whiteboard. He started to link two of the requirements, stood back and then said “So this step is also related to this one, isn’t it?” Then the Marketing Manager said “That comes just before the promotions stage.” As the Process Improvement Manager drew a process diagram, each individual kept adding in pieces of the puzzle, with how they were related.

    Design as bricolage.
    Bricolage involves repeated “trying out” and experimentation until a pattern is discerned that is useful. (The word derives from Bricoleur, a French term meaning “handy-man” or “jack- of-all-trades.”) Claudio Ciborra described bricolage as “the constant re-ordering of people and resources that is the true hallmark of organizational change.” But Bricolage is not random experimentation. It is based on leveraging the world “as defined by the situation” (Ciborra, 2002). Pattern sensitization adds another dimension to bricolage. It can now be seen as an ordering of situation elements until they make sense according to previously encountered patterns. So design is like a jigsaw. Each person carries around a partially-completed set of jigsaw pictures in their heads. The core problem of design is to use a problem-representation that can allow people to communicate the structures in their “mental jigsaw picture” to others.

    References
    Alexander, C. Notes On The Synthesis Of Form. McGraw Hill, New York NY, 1964.
    Ciborra, C.U. The Labyrinths of Information: Challenging the Wisdom of Systems Oxford University Press, Oxford UK, 2002
    Maher, M.L., and Poon, J. “Modelling design exploration as co-evolution,” Microcomputers in Civil Engineering (11:3) 1996, pp 195-210.
    Maher, M.L., and Tang, H.-H. “Co-evolution as a computational and cognitive model of design ” Research in Engineering Design (14:1) 2003, pp 47-64.

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 design copyright © Susan Gasson, 2025

Designed with WordPress Twenty Twenty-Five