The Maunsell Sea Forts: Photography

The Maunsell Forts were small fortified towers built in the Thames and Mersey estuaries during the Second World War. They were named after their designer, Guy Maunsell. The Thames forts shot down 22 planes, 30 flying bombs and were instrumental in the loss of one U-boat which was scuttled after coming under fire from Tongue Sands tower.

A couple of weeks ago I spent three hours on a converted tug boat visiting the Maunsell Forts at Red Sands in the Thames Estuary. The anti-aircraft guns are long gone, and the forts are in a state of slow decline without the funding to restore them and too expensive to demolish. The MOD have little interest in preserving them; the forts are maintained by volunteers and by donations from the public. I shot a few rolls of B&W medium format film (Ilford and Kodak) on my Mamiya 645, and a roll of AFGA E6 35mm which I shot through a LCA and cross processed. A selection of shots are below.

More information on these amazing structures, and how you can help preserve them, can be found here:

The full set of photographs I took can be found on my Flickr feed here:

Maunsell Sea Forts

Maunsell Sea Forts

Maunsell Sea Forts

Maunsell Sea Forts

Maunsell Sea Forts

Maunsell Sea Forts


phatic musk – some new releases

We’ve had two releases out on phatic musk  this past two months, which is amazing considering we’d previously done 1 a year!


Analog is a C40 release with the added bonus of receiving a vintage copy of Analog Sci-Fi zine to read whilst listening.

The Second release is in conjunction with a subscription service called . This release was limited to 5 mp3 players custom skinned loaded with over 14 hours of drones created by apkallu of enmerkar – the subscription service will be offering over 4 hours of new drones per month for the price of £3.  That’s a lot of drones for your pound!

Drones to Code By - apkallu of enmerkar

DTCB:07/15 by apkallu of enmerkar

Keep your ears peeled as there will be more releases coming up from phatic musk in the not so distant future!


Two years on the other side – from making stuff to sell stuff, to making stuff that just works

I’m not one to generalise, but let me do some generalising. My career in design has has been unplanned and random at best, and my life as a designer has been varied – there have been some common themes but the biggest shift was a couple of years ago when I joined Semantico, and the world of digital publishing.

Before Semantico I had a stint for a small agency that mostly made games with the purpose of selling stuff, and before that I had a longer stint at a strategic comms agency which made all sorts of different kinds of stuff with the purpose of selling stuff (Back then I was the creative lead for our publishing clients – Faber & Faber, Hachette Livre and Dorling Kindersley, one of the reasons I’m enjoying working with publishers again now). And before that I spent quite a few years freelancing at various advertising agencies large and small, making stuff with the purpose of selling stuff  (Mother London and Mccann Erickson being two of note). So that’s knocking on 17 years designing to push product, shift units or somehow facilitate ‘engagement’ (because engagement somehow means stuff will sell).

‘Clickthroughs’ used to be the currency, soon followed by the zeitgeist of ‘likes’ and ‘shares’ – that was the ROI, the bottom line, how work was judged (I will avoid mentioning ‘awareness’  - unquantifiable but seemingly keeping the internet in banners).

So what’s changed? I still work for a paymaster, a business with clients to satisfy, clients that need to make a profit, have ‘brand values’ to communicate, who want a return of investment, and who need to sell product, shift units. But there is a difference.

In the main, the differences are in the product’s lifecycle, its longevity or life expectancy. Often (but not always) in the world of advertising the work is campaign work, and those campaigns can be short sharp affairs, designed to burn brightly but quickly, just like Rutger Hauer in Blade Runner. The emphasis is on the message, the comms, the impact.

I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched c-beams glitter in the dark near the Tannhäuser Gate. All those moments will be lost in time, like tears in rain. Time to die.

Semantico make products that hang around for a while. They have to be robust. The product our users interact with isn’t just for a few three minute bursts but for hours and hours. They are not used for entertainment, distraction or sociality, but for work, for research and study.

And our clients don’t just sell stuff, they also have to do a ton of other stuff really well too. They need to add value around their content, find new relevant ways to get their content to new audiences. A student or researcher will use this product for years. A single purchase by one institution will serve a multitude of people. Not everyone has a bought the product they are using, or even directly paid for it.

In the world of advertising, knowing your demographic, your target audience is a huge part of the creative process. You need to speak the same language as your audience, communicate in the same way, resonate. Be their friend, part of the same pack, the same tribe.

Within publishing, understanding your audience is just as important, but there is a change of emphasis. I am now designing tools, and designing a service, for different wants and needs.

Full Circle

At Semantico we very user centric. Our whole design methodology and philosophy is based on user insight. So my design life has come a little circular in fashion – The agency where I learnt most of my game was, for the time, particularly user-centric. When I joined them in the early noughties it was standard process to produce wireframes and user journeys and use these as tools for insight and production. We actually had an information architect and producers who ‘got’ UX. And as I was reminded by my old strategy director the last time we hooked up in London, we often profiled archetypical users, and created stories and narratives around those archetypes – designed to get under our audiences skin and help us deliver effective solutions for our clients. We wanted to understand our users so we could offer them the aspirational experiences our clients expected us to deliver.

Now I have the need to understand our users so we can design a better service, better tools. User research is now a task absorbed into all our design activity and all our design choices are informed by real users and the user insight we gain from research.

I can’t say I miss working on stuff that just disappears into the internet abyss once a short term goal is reached (or not), but what I find most rewarding is that I am designing useful stuff – stuff to help people educate themselves, learn about new stuff and answer problems. And in the case of the online clinical procedures tool we launched earlier in the year, stuff that might help save lives too.



From the physical to the emotional: User experience research and design

In my previous posts on User Experience (UX) methodology I have touched on sketching, wireframing and prototyping. I would be remiss not to discuss the most important factor in any user-centric design approach: user research.

Since the emergence of Participatory Design in the 60s and 70s design thinking has moved on from the physical to encompass the emotional and behavioural. Designers today create a context for experience* and user experience is an expertise that provides a user-centric and data driven approach, needed when designing appropriate and effective products in today’s digitally fragmented world.

UX is no new speciality, rather it is an umbrella term for processes and methodologies that have had their genesis in other specialities for a number of years. Human-computer interaction, behavioural and cognitive psychology, usability and user centered design: all influences on what we call UX, and all methodologies that have a focus on the user.

Ignore users at your peril

I generally work with publishers, and I often encounter a quite complex user ecology. To make a generalisation we usually design for a specific task – research. But our user base is complex. Domain expertise varies between the undergraduate, the postgraduate, the academic and the professional. Differences in subject area throw up variations in behaviour, down to the favouring of a tatty notepad over using the latest digital tools. There is a vast difference between an undergraduate accessing textbook content through a desktop computer situated at their university library to an architect accessing building regulations whilst onsite, through a tablet on a 3G connection.

We have to understand this complexity of our user base. The differences and commonalities between user types, mental models, motivations and triggers – all areas that as designers and UX practitioners we need to fully comprehend before we can design the appropriate collateral that combined, make up the overall experience and impression of a product. This can only be achieved by talking and listening to our users and UX methodology gives us the tools to do just that.

Crafting experiences for online research

One of the most important factors in our approach to UX is that we are involved with a projects lifecycle from start to finish. We have an integrated and embedded approach – our front end development team encompasses developers, UX architects and designers – this integrated approach ensures UX is a consideration in every decision no matter at what point a project is at.

At the preliminary stage of any project our work is predominantly requirement gathering. We do a raft of exercises and workshops with client stakeholders designed to sanity check business requirements, aspirations and priorities, making sure a project brief is created that all parties involved believe to be feasible. We facilitate workshops around our clients data, the earliest stage of producing a sites taxonomy: the information architecture and interaction model. The output of these collaborative exercises and workshops are the beginnings of the documentation that make up the ‘blueprints’ of a particular project.

Following on from these early requirement-gathering workshops we move onto user research.

Once we identify the appropriate testing and research techniques we recruit a user group that we test on throughout the whole production process of a site build. At the beginning of a project we use our user group to create personas defining common user mental models and user tasks. The insight we gain from our user testing can point to the relevance of tools and features, and how those tools are used. What motivates our users to use our product, how social activity differs between user types and an idea of device usage. This research gives a shared view on the typical user(s) of a product, a view we can share with all stakeholders. When decisions are made, they can be made within the context of understanding users’ needs and motivations.

During a project build we use our user group for comparative testing and prototyping, giving us feedback and direction on our interface design. We also carry on this activity post launch, checking benchmarks have been met and making sure a product is being used as intended, and if not, why and how? It is important at this post-live launch to be especially active – feedback forms and surveys, a look at analytics and a further round of user testing all make sure that the solution we have provided performs as expected and intended.

The image below is a snapshot of a few desks at the studio where I work – everyone works on a Mac, but as individuals we have different roles, we use these machines for different tasks. We bring our idiosyncrasies into our working habits. Our personal life bleeds into our work environment. All these desks are different, but we all use the same tool.

If we speak the same language we could have different accents, different traditions and inclinations. Localisms change the cultural meaning of symbols and signifiers with a short hop across a border. This is what makes people interesting, the differences, the ability to surprise and be surprised. And this is why we cannot make assumptions about our users.

User Experience challenges

There are challenges in the adoption of UX methodologies. One such consideration is cost. Research and development in any field is not cheap, and with UX research it is no different. Time and resource defines the extent and scope of our research. Analytics alone, although cheap to obtain, can only take us so far. We believe in a lean methodology – we keep our UX overhead as low as we can get it, but when it comes to user insight we want to do as much as we can, and we firmly believe that any quantitative data needs to be paired with more in-depth qualitative data that could be more costly to obtain.

Combating bias can often be the hardest challenge to overcome. I mentioned the importance of keeping an open mind – this was no throwaway comment. We all have bias, a favoured interface, a way of interacting we are familiar with. A prefered aesthetic, a cultural association …  all these factors add bias. Overcoming them is a matter of self awareness and by having the experience of being surprised one too many times. We all have our prefered solutions and outcomes usually for seemingly rational reasons but seeing your own expectations confounded and discovering insights previously hidden from you is the best antidote to adhering a little too much to your own predilections.

Keeping it real

I have been undertaking some user research in conjunction with the University of Sussex. Initially we have been conducting in-depth interviews with a cross section of student and academics. This research will hopefully point to areas of interest which we can investigate more thoroughly. Andrea Fallas, our UXA, will be publishing some insight from our research activity with the University on the Semantico blog soon.

This post first appeared (with some slight edits) on the Semantico blog.

*Hummels, Djajadiningrat and Overbeeke (2001)


ID Situations : Laica release phatic musk

ID Situation is dedicated to the millions of unknown faces caught on hours of grainy CCTV images every day, to all the footage that will be stored away and never looked at again, the boxes full of old VHS tapes of empty streets and hard drives loaded up with hidden shop corners


New release on phatic musk ID Situations by Laica –  with remixes by Production Unit (Broken 20)  and decadnids.

Following on from the Uschi-No-Michi release there was a bit of a challenge from a packaging design point of view – so we’ve gone ultra minimal and opted for a matt black bubble envelop with a clear sticker.


Helmut Schmid & Otsuka Pharmaceutical

In 1980 graphic designer and typographer Helmut Schmid produced packaging design for Otsuka Pharmaceutical. these examples, featuring Univers, are amazing exercises in typographic clarity and a beautiful example of graphic design boiled down to information and clear communication. Nice colours too.



There is a great book covering the design of Helmut Schmid, ‘Design Is Attitude’ not sure if it’s still in print, details here. You can check out more of his work in the archive section of his website.




Golang! Go Language.

Go Language or golang - is a relatively new language from Google.  It was created in 2009 – it’s essentially a system language. It’s statically typed and has some similarities to C and C++ (structure, and syntax to some degree).

I recently decided I wanted to do some system programming, or at least some command line tools. In the past I would have looked at C as the option, but I thought I’d give Golang a Go!

The task I set myself for the initial project was that of a simple ftp deployment helper. I currently have to do quite a lot of deployment of development work, and currently this involves a lot of ftping different files. This can be a real pain, making sure the correct files have been uploaded – especially if they’re in different git repositories (essentially I want to set up our servers so we can deploy via git, but that’s another project!). So what I wanted to do was create something simple so I could just type :

iri deploy config.json files.json

And it would do the hard work for me.

I started the development in my limited spare time, and found Golang very easy to get into – there are plenty of useful documents and plenty of help on the variety of forums out there. One great feature of golang is it’s ability to use code repository sites such as github to home packages and a lovely simple mechanism to install them – it’s as simple as typing

go get address_to_some_repository

And there are a whole host of packages listed at the GoDoc website.

My deployment project – code named iri – can be found over at github . It’s still early days, it doesn’t actually do what it should do as of yet – so keep an eye on it and I’ll make a proper post once the project is working properly.