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


  2. What UX can learn from product strategy, and vice versa

    Posted August 9, 2010 in strategy, user centred design  |  1 Comment so far

    Dirk Kneymeyer of Involution Studios writes on his blog about how he’s losing faith in UX. He’s reacting primarily to an article by Whitney Hess characterising start-ups as being focused on the what rather than the who, why or how.

    One of Kneymeyer’s central points is that product strategy and user experience are ultimately different domains, and that user experience professionals aren’t typically the most qualified people to define product strategy.

    I’m inclined to agree with that point. Because user experience, as an emerging discipline, is still consolidating many of its techniques and methodologies, there’s an exuberant tendency that often sees UX extending its dominion into other areas. This can sometimes be appropriate – it’s a good thing, for example, that user experience practitioners increasingly concern themselves with content strategy –  but in other cases it blurs the definition of what user experience is, and it can sometimes come across as disrespectful towards professionals in other fields.

    There is an obvious overlap between user experience and product strategy, centred around scenario planning. But even this exercise works very differently in a user experience context than it does in a strategy & planning one. Scenario planning in a strategic context involves having to discard or gloss over some issues that are central to ‘traditional’ UX, while becoming obsessed with details that a typical UX project would leave to one side.

    My experience of working with people who specialise in product strategy is that it’s a well developed field in its own right. Yes, it can learn from experienced UX professionals (and it knows it can – I’ve noticed increasing interest in UX from product & business strategy teams in the last two years), but the opportunities for learning are reciprocal and not just one-way.


  3. Encountering the future over an omelette

    Posted August 5, 2010 in ephemera  |  1 Comment so far

    Yesterday I was in the Workers Café on Upper Street eating an omelette, when I encountered the future. Or at least it felt like the future, for a couple of seconds anyway.

    The café has a TV on the wall which shows Sky News, whose stream of “breaking news” is regularly interrupted by ad breaks. It was during these ad breaks that I had my brush with the world of tomorrow.

    My eye was lazily watching the screen when an advert appeared for the Samsung Galaxy S, a new Android-powered mobile phone. The usual stuff happened – the phone was lit in an appealing fashion, it spun around invitingly, a disembodied hand did things with the screen.

    One of the things the disembodied hand did during the advert was open up Google Maps. And in Google Maps, the street being shown was the street I was actually on – “The A1, Upper Street”.

    But I didn’t think, “what a strange coincidence”. Instead my first reaction was to assume that the advert was somehow geo-targeted, dynamically displaying the TV’s location on the phone’s screen.

    A second later however I realised that while this might be technically possible today it’s unlikely that a greasy spoon café, however venerable, is equipped with that sort of kit. It’s also unlikely that something as expensive as dynamically geo-targeted video would be used so casually, to show a particular street on a phone’s screen for around half a second on a daytime TV advert.

    The feeling I was left with was a strange one. My initial, subconscious assumption was that the ad was geo-targeted rather than that an unlikely coincidence had taken place, so I was a bit disappointed when I realised I was expecting too much from the cafés TV and Sky’s ad platform.

    So what looked like the future turned out to be a false positive. The ad break ended, Sky News went back to its gentle newsy clamour, and I went back to my omelette.


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