1. Harry Brignull on how to get hired in UX

    Posted May 10, 2015 in Uncategorized  |  No Comments so far

    In my last job I spent a lot of time interviewing candidates for UX jobs and running design exercises. So I can recommend reading Harry Brignull’s tips for anyone looking to get hired in UX – they all ring true.

    And in fact they’re still worth reading even if you’re not looking to get hired but are the person doing the hiring. If you’re not already  looking for the red flags he mentions, you should be.

    I’ve lost count of the amount of times I’ve asked people about surprises or unexpected results from user research only to receive a content-free response. One UX designer even said, “I’ve always been right.” Needless to say, that person didn’t get the job.


  2. “Fast is good, clever is better” – on speed, or the lack thereof

    Posted April 28, 2015 in user centred design  |  No Comments so far

    Two articles on a similar topic. One is recent and the other is old. Both UX design related so don’t worry if you’re not interested in that kind of thing.

    First, “Let Your Users Wait” by Tal Mishaly at UX Magazine. The upshot is that designers of interfaces should think more about time: about how users perceive it, about how the same period of time can seem to pass more quickly or more slowly depending on what the interface does, and even about how it can sometimes be useful to create delay.

    Second, an oldie but goodie from four years ago: a cognitive teardown of the Angry Birds user experience by Charles Mauro in 2011. Reading the first article made me remember this one and how much I liked it at the time, so I dug it out of my bookmarks and read it again. I was hooked on Angry Birds back then, and some of Mauro’s comments about the game’s approach to response time management had a big impact on me:

    In Angry Birds, it was possible for the programmers to have made the flight of the birds fast – very fast, but they didn’t. Instead they programmed the flight of the angry flock to be leisure pace as they arc across the sky heading for the pigs’ glass houses. This slowed response time, combined with a carefully crafted trajectory trace (the flight path of the bird), solves one huge problem for all user interfaces – error correction. The vast majority of software user interfaces have no consideration for how users can be taught by experience with the system to improve their performance.

    I reinstalled Angry Birds recently to show to my 3-year-old son before recoiling in terror from its barrage of ads and—worse—dark patterns leading to shady in-app purchases. But despite all that I think there’s still a lot for interaction designers to learn from Angry Birds.

    If you’re one of them (an interaction designer that is, not an angry bird) feel free to spend tomorrow morning playing Angry Birds. If your bosses ask you what you’re up to, tell them it’s research and point them to Mauro’s article.


  3. The worst yes/no dialog ever

    Posted September 8, 2014 in ephemera, user centred design  |  No Comments so far

    If I was better organised and had more time to spare, I’d collect pictures of dodgy dialog boxes and probably set up a tumblr for them.

    As it is, I only take these pictures when I come across a particularly dodgy example. Here’s one.

    "Yes to abort, No to continue"

    “Yes to abort, No to continue”

    It appeared when trying to buy petrol from a self-service machine. You’re quite stressed in those situations as you sometimes have a queue of cars waiting for you to get on with it. The last thing you need is a woeful piece of design like this that forces you to lay aside your preconceived notions of what “Yes,” “No” and big red X’s actually mean.


  4. Are you a “UX Ninja”?

    Posted July 8, 2011 in user centred design  |  No Comments so far

    There seem to be a lot of “UX ninjas” about these days. Are you one? Here’s a handy flowchart to help you find out:

    Are you a UX ninja? ...No


  5. Why I hate the Delicious extension for Google Chrome

    Posted December 16, 2010 in ephemera, user centred design  |  8 Comments so far

    (Edit: less than nine hours after I posted this article, Yahoo! announced plans to shut down Delicious. I guess there’s a reason why people call Yahoo! the place good ideas go to die)

    If you haven’t heard of Delicious, all you need to know is that it stores your bookmarks on the web. This is handy because you can access them from anywhere and share them with other people.

    Delicious used to be pretty exciting. Social bookmarking, tagging, RSS feeds – the potential seemed mind-boggling. But then Yahoo! bought it and it started losing its edge. Nowadays there isn’t much excitement about Delicious, but it’s still useful.

    One thing that makes Delicious particularly useful is the availability of various browser extensions. These extensions put a little button on your browser, allowing you to add and tag a page really, really quickly. Because it’s quick to add a page, you find yourself adding more pages – and the more pages you add, the more useful Delicious becomes.

    I use the Delicious extension for Google Chrome quite a lot, but I think I hate it. Here’s what it looks like:

    So you click on the “tag” button,  and then this appears:

    So far so good. But when you use this several times a day, you’ll notice some annoying and even hateworthy things about it.

    The first thing is that it has no persistence. If you’ve typed a brief, witty description of the page in the Notes field, and then carefully selected some tags to go with it, you don’t really want to go through that process again. But if you accidentally click outside the extension, that’s precisely what you’ll have to do – because it forgets what you’ve entered! Having to re-enter stuff I’ve already typed isn’t something I enjoy, even when it’s a relatively small amount of text.

    The second thing I hate about it is the placement of the Save and Cancel keys. You’ll notice that Cancel is in the bottom right, which is slightly unconventional – primary actions (Submit, Confirm etc) are usually placed to the right in forms like this. They’re also very close to one another. These two design choices conspire to make it a little bit too easy to hit Cancel by mistake – especially when you’re working quickly. Hitting Cancel closes the extension, meaning that – you guessed it – anything you’ve typed will need to be typed again.

    So these are the two reasons why I hate the Chrome extension for Delicious. If it remembered the stuff you typed, however, I would probably love it. This shows how fine a line there is between love and hate in user interface design, or (more likely) how much of a pedant I am about these things…


  6. The city as interface (part two)

    Posted August 18, 2010 in user centred design  |  No Comments so far

    NB: this post is a continuation of “The city as interface (part one)“, published on 6th August 2010

    The modern city is a built environment whose purpose isn’t just to house and feed us. It offers us access to both information and capability, and it has evolved ways to help us to understand and navigate its considerable complexity.

    In this sense the city is an interface and the people within it, residents and visitors alike, are its users. But the city is not a passive interface. It is a highly responsive one which evolves continually over time.

    This constant development is the result of many social and economic factors which I’m not going to explore here. Instead, I’m going to look at two mechanisms that help cities become more effective the more they are used – adaptability and feedback.

    Multiple layers of experience

    Many modern cities are so complex that even if you spend your whole life in one you’ll never fully understand it. London’s taxi drivers experience physical changes in their brains after spending years memorising its street map, which is just one of the city’s many layers. So what hope is there for the visitors experiencing it for the first time?

    The fact is that cities are not allowed to be complicated. If they can’t successfully accommodate outsiders, the outsiders won’t stay, and the city won’t be a city for much longer. The city must therefore be adaptive – it must offer a range of experiences to its users based on the extent of their familiarity and expertise.

    A first-time visitor must be able to access the features they need to use without being confused and obstructed by those they don’t. Cities achieve this by using transport networks to negate their geography, or by having certain locals (such as London’s taxi drivers) learn the intricacies so that others don’t have to.

    Locals have a better background knowledge of the city so, like power users of a computer system, most things they do become habitual, almost instinctive. But the interface of the city still accommodates their needs. An example of this in many cities is the bus system, which tends to be optimised for locals at the expense of outsiders.

    Computer interfaces have similar ways of providing a layered experience to users, and the less specialised the interface the more layers there are. The Nintendo DS has a specific purpose, so its interface has very few layers. More advanced users might configure the clock or change wireless settings, but there’s little else to do apart from load a game:

    Systems like Mac OS or Windows are very different. There is a “welcoming” layer aimed at newcomers in which commonly used applications and features are highly visible, and many people use an OS for years without moving on from this layer. But under the surface there are other layers – the registry, the command line, the process list – which can seem intimidating but are essential tools for other users of the system.

    Multi-purpose interfaces fail if they intimidate new users with difficult features, and they also fail if they force experienced users to wear kid gloves. A strong interface, like a successful city, will accommodate both user types and all the grey areas in between.

    Becoming a part of the interface

    When we “use” cities,  they use us too. They incorporate us into the experience offered to other people – we become part of the show. Here’s an example.

    One morning last week I was walking to my local tube station. Before long I started to sense that something was wrong. As I got closer to the station this conviction grew, and eventually turned out to be correct: the station was shut and all hell was breaking loose.

    How did I know there was a problem? I hadn’t received a text alert or seen any signs. Instead, I’d used something that many city dwellers use all the time, often without knowing – the city’s feedback mechanism.

    On that morning I noticed, almost subconsciously, that there were more people than normal on the pavements. Several people apparently dressed for work were walking away from the tube station, or looking confused and directionless. It was subtle but noticeable, and as I noticed it my behaviour changed also. Before long I was part of the feedback mechanism, part of the crowd whose behaviour informed others that the tube station wasn’t working.

    The city is full of behavioural patterns that we observe, follow, and unwittingly learn from all the time. Their importance can’t be overstated. Remove the flow of humanity and the city becomes a surreal, frightening place, a sensation that was exploited by the film 28 Days Later.

    The inherent eeriness of an empty city

    It’s only recently, in the age of social software, that computer interfaces have developed the ability to emulate this sort of feedback mechanism. Older interfaces couldn’t reflect aggregate user behaviour in the experiences offered to individual users. But in today’s online environment things are different.

    When you browse Amazon, your navigational choices are used by the system to influence the choices that subsequent visitors will see. When you watch a video on Youtube, you add to its view count in a way that’s visible to others. And if you removed the flow of users from Twitter or Facebook you’d be left with literally nothing at all.

    Modern interfaces are starting to use feedback mechanisms similar to those that cities have been using for centuries. Our use of the system affects the system, and affects how others experience it too. The dividing line between the user and the interface becomes a blur.

    Conclusion

    Analogy is a slippery slope. Successful interactive interfaces may well have lots in common with successful cities, and we may well think of the city as an interface, but the analogy shouldn’t be taken too far. Cities have spatial constraints that computer systems don’t share, and they tend to be the result of long-term evolutionary design processes rather than centrally directed ones.

    But even with these differences in mind there’s a lot we can learn from how cities function as interfaces. Cities solve problems that interactive systems have only recently become sophisticated enough to have. If we can understand those problems well enough, the modern city can be a treasure trove of inspiration and insight to designers of future interactive systems.


  7. The city as interface (part one)

    Posted August 2, 2010 in user centred design  |  No Comments so far

    In Responsive Environments: Architecture, Art and Design, writer Lucy Bullivant refers to urban environments as “interfaces in their own right”. Reading this, I found myself wondering – do modern cities function as interfaces? If so, how? And can designers of interactive systems find new inspiration by thinking of cities in this way?

    “The map is not the territory”

    By expressing functionality in a way that’s more suited to our needs, interfaces help us understand and act upon devices and systems that could otherwise be confusing. They’re most helpful when something’s function is not directly expressed by its form: a pencil doesn’t need an interface, but a pencil sharpener might.

    From this perspective, it could be said that the Tube map of London is an interface for the city. After all, it abstracts the tangled system of London streets into a neatly organised network of straight lines, making its complexity manageable even to tourists. But this is incorrect. It’s the tube network itself – not the Tube map – that acts as an interface for London.

    This is because the Tube map isn’t actually an abstraction: it might distort geography, but it represents the network’s structure faithfully. The network itself is the abstraction, the layer of navigation that helps us forget the confusing mess of streets and avenues above ground. It is interactive: we can use it. The Tube map is an ingenious visualisation of that interface, but is not an interface in itself. As Alfred Korzybski said, the map is not the territory.

    So when we think of cities as interfaces, we should go beyond thinking of visualisations and maps and focus instead on how the physical make-up of the city facilitates its use.

    The problems cities are required to solve

    All human settlements have certain things in common. Places for people to eat and sleep, and facilities for producing food, materials and so on. Another is navigation. Even the smallest hamlet has a navigational or wayfinding role to play, acting as a landmark for passing travellers with no interest in local happenings.

    These three basic roles – habitation, production and navigation – apply to almost every place that people live. But in larger settlements additional uses are encountered. A traveller passing through a town might look for medical assistance, or establishments providing food and accommodation. In a larger town, there might be thriving local industries, academic institutions, working artisans.

    As settlements grow in size these roles explode in number. These in turn attract ever more visitors, many of whom establish businesses and institutions and therefore add to the range of uses on offer. After a while the vast size and complexity of the settlement begins to pose a new challenge: how can anyone possibly understand everything that’s happening?

    It’s in response to this challenge of incomprehensibility that the “interface” of the city has evolved over time.

    The designed environment

    As cities grow, they effectively become designed environments. Rivers are submerged beneath roads, hills and valleys are smoothed over, landfill and burial sites override the natural topography. When we’re surrounded by city we’re in an environment shaped (consciously or not) by humans, an environment whose very structure has a function: to point us towards the roles, uses and amenities that the city offers.

    If the city’s environment fails to do this well, the city itself is failing. Visitors looking to sell won’t locate the businesses willing to buy. People needing help won’t know where to look for it. The “functionality” of the city will go undiscovered and the city won’t be used. The goal of the urban environment is to make the city’s functionality discoverable to its users.

    Patterns

    The structure of a city, then, has objectives in common with “conventional” interfaces – to help users locate and utilise underlying capability. In a city, this capability could be anything from acquiring a visa to buying a rare, imported album. In a computer system, it might be turning the wi-fi antenna off and on. But in cities, the number of capabilities is significantly greater. So how do cities help us make sense of them?

    One way – which can also be seen in interactive interface design – is through the presence of patterns which help make cities comprehensible. As we enter an unfamiliar city from its outskirts, we will probably know without being told when we’re entering its central district. Other patterns are more specialised. Record collectors visiting unfamiliar cities will often find record shops easily, thanks to the patterns that “signpost” those sorts of areas.

    Just as computer interfaces use patterns to accommodate the mental models of their users, cities use them to reward familiarity: the more cities you know, the easier it is to find your way around the ones you don’t. And there’s a functional importance too. These patterns often develop into localised “clusters” within which industries or disciplines are closely concentrated, such as the cluster of media businesses around Soho or the legal profession’s concentration around Chancery Lane.

    Windows 7 control panel

    Grouping related controls in Windows 7

    When this happens the city isn’t just making itself easier to navigate, it’s making itself easier to operate, just as an interactive system is more usable when similar features are placed near one another. And when cities are easy to operate, all constituent parts – from local businesses to visiting strangers – feel the benefits.

    So far we’ve explored how the structures of successful cities share some of the conventions of successful interfaces. But real interfaces are interactive – they aren’t just static maps and informational aids. When we do something with them, we receive feedback and response. The second part of this post will look at how the city provides feedback and how, when we  use a city, we become a part of the interface ourselves.

    This is part one of a two-part post. Click here for part two of this article


  8. Microsoft’s design strategy: open formats, proprietary interface?

    Posted June 1, 2010 in software, strategy  |  1 Comment so far

    This might not be a very advisable disclosure to make, but I’ll make it anyway: I actually like Microsoft Office 2007.

    Liking Office 2007 is not really the done thing – lots of people in my line of work turn their noses up at Microsoft in general and Office in particular. And I’m no different. Last year I spent about six months attempting to move away from Windows to use Linux instead, but ended up returning to Windows. Why? Because, for me, OpenOffice was simply no match for Office 2007.

    The thing with OpenOffice is that it looks and feels a lot like Office 2003. If I was a heavy Office 2003 user, OpenOffice might have worked out because its user interface (UI) is fundamentally similar. But Office 2007 has a radically different UI, with none of the old “File / Edit / View” menu groupings.

    Office UI screenshots

    Office 2007 replaced the conventional menu structure with the "Office Ribbon"

    Lots of people were confused by the Office 2007 UI when it launched, myself included. Today, however, I see it as a big improvement. The new interface makes features more discoverable and more immediately accessible, and I get far more out of the software today than I ever did before.

    But why did Microsoft carry out this redesign, which must have been costly? After all, they had a monopoly in the office software market so could get away with being a bit conservative. And people don’t like it when familiar things change – just look at the protests that erupt whenever Facebook changes its layout – so the redesign must have looked pretty risky too. How did the Office 2007 team convince Microsoft to fund a design project that was risky, expensive and potentially pointless?

    Microsoft, like all companies, would like us to think that it does these things out of altruism, to make our jobs easier and lives happier. But that’s not how things work in the corporate world. Instead, I think there might be a slightly more crafty and devious strategy at work here.

    Imagine you’re Microsoft. Your monopolistic behaviour during the browser wars of the 1990s cost you over $2 billion and led to you being forced to promote your competitors. The last thing you need is for something similar to happen to your Office package, your most lucrative product line after Windows.

    Being proactive, you wonder what line of attack the courts would take if they came for Office, and it hits you – proprietary file formats. Documents created in Microsoft Office can’t be opened by other packages because the files aren’t compatible, which inhibits competition and annoys the hell out of the open source community. So you decide to phase them out. You’ll set your file formats free, and will even start supporting open source file formats. This way you’re far less likely to be accused of monopolistic behaviour.

    But there’s a problem here. What if, by trying to look less like a monopoly, people move to OpenOffice and you actually become less like a monopoly? After all, proprietary file formats do encourage lots of people to stick with Office. What you need is a way to become less vulnerable to government lawsuits while retaining your product’s “stickiness”. And then it hits you – make the file formats open but, at the same time, make the user experience proprietary.

    When an Office 2007 user switches to OpenOffice, they’ll be able to open their existing documents easily. But using the interface will feel like stepping back in time, to the period of Office 2003. Ultimately, the user will go back to Office 2007 not because they’re locked in by proprietary file types, but because they’ve learnt and absorbed a proprietary interface. And no-one’s going to launch an antitrust lawsuit simply because Microsoft made some design changes.

    This line of thinking about why Microsoft changed the Office UI so radically may seem slightly paranoid, but there is such a thing as design strategy and companies like Microsoft certainly take it seriously (most of the time). It wouldn’t surprise me, and I wouldn’t see it as controversial, if this “proprietary UX” strategy helped convince Microsoft to invest so much in a risky design overhaul. Given that Office 2007 caused me to abandon Linux and move back to Windows, the strategy – whether it’s real or not – would seem to be working.

    EDIT: unlike me, lots of people really hate the Office 2007 interface. If you’re one of them, you might be interested in this freeware add-in that introduces an old school Office 2003-style menu system into Office 2007