Nordic Design

Design, Music and Life, by Alex Lillo

How to deal with good UX

We’ve all been there, presenting some work only to find somebody defending an alternative as it’s good UX, or best practice. Equally disheartening and difficult to deal with if you don’t know what it means.

It normally happens when somebody disagrees with your work but doesn’t know how to express it, and it’s your job to find out what they actually mean. Let’s have a look to some scenarios.

If the client is looking for good UX

A few years ago during a project’s conceptual design phase, it was clear that our work wasn’t ticking all the boxes of one of our senior stakeholders. He agreed with the key elements but something was missing. And one day he said it: “it needs more UX”.

We were puzzled, he opened a new tab and showed us a website with a 3D animation, where elements rotated as he moved the mouse. Suddenly all the meetings made sense,  our flat designs were missing that feeling when you interact with a product, when you touch it.

Some people would have rolled their eyes and send the story to Clients from Hell. That’s wrong. He was not a designer, nor had to know how to articulate his concerns. He actually tried to use our language, so it was our job to understand what he really meant.

How to deal with more UX

Start acknowledging their concern and ask them to explain how their proposed solution meets their business or user goals. If the answer is not satisfactory, use the 5 why’s technique to identify the root cause. If needed, move them away from their solution and onto why your proposal is not working for them.

Once you understand what the root cause is, tell them that you’ll find a way to solve it. Ultimately, that’s why they are paying you.

When a developer proposes best practices

Similar to the client situation, although normally presented as “it’s best practice”. Often this behaviour is motivated by the differences between how design and development work. When you write code, you can argue that there’s a better way to solve a particular problem: more performant, cleaner, easier to maintain. In a nutshell: best practice. But there’s not a single or best way to solve a design.

So when they argue about design this usually boils down to what they feel comfortable with. Maybe they are more familiar with the Android/iOS/Facebook/etc. interface, and defend it as best practice.

Dealing with best practices

Again, ask how their solution meets user or business goals, why it’s better than your idea, discuss the merits of each proposal.

Remind them that there’s no such thing as best practice. Just because something works for Amazon/Twitter doesn’t mean it will work for you.

Although common UI patterns help users understand how to use your product, it doesn’t mean it’s the only way to solve it, or the most effective. Help them see the design from the users’ point of view.

When a designer gets defensive and argues that his design has better UX

One of the most important jobs of a designer is to articulate the reasons behind your design decisions. Meeting business and user goals is what separates design from art, so if the designer can’t explain the reasons behind a flow, layout or colour choice, they should go back to the drawing board and figure out why they did it.

[Design is] the intentional solution to a problem within a set of constraints.
Mike Monteiro

How to deal with better UX

Even experienced designers can do this mistake, specially when they are not strong interaction designers. They have a solid intuition based on years of experience on other design disciplines, but they can’t rationalise it. Maybe they lacked the time, or they have a preference to a particular trend or operating system, applied without reason on a different context.

Common examples are iOS patterns used on Android, or websites that mimic a native app. This can lead to friction on many levels as developers struggle to code something that goes against the medium, and users see it as a spoof.

Challenge it, explain them why it doesn’t work, and let them come back with a better proposal.


3 rules of crisis management

High on my list of designers’ sins, probably next to “good design sells itself”, is the lack of ability to reflect on your own acts and accept when you have fucked it up.

As professionals (you get paid for your work right? Then you’re a professional) we have to accept responsibilities for what we do. Be humble, do some soul searching, analyse the situation, understand your client and look for your own faults. Never get defensive, nor blame others. And definitely never get angry, that’s not going to take you anywhere positive.

And if it happens that you’ve made a mistake that’s fine. We all do mistakes, it’s how you manage them.

Here’s a simple recipe of what to do in case you (or your team, or somebody you’re responsible for) have fucked it up:

  • Tell your client that you’ve fucked it up
  • Tell her how bad it is, and why that happened
  • Tell her how you’re going to solve it
  • Move on

I read this on Helio Fred Garcia’s book The Power of Communication (brilliant book, you should read it), and it works. Also make sure that you control the timing of the crisis. You want to be the person calling saying we need to talk. You don’t want it to get so big that the client needs to call you wondering what the heck you’re doing with their budget.

Remember, design solves business problems, otherwise it’s art. Somebody, somewhere, has trusted her budget on you, to solve a business problem. And when things go wrong, you’re playing with that persons’ budget, and potentially her career.

So before blaming others about how they don’t understand your brilliant design, do some soul searching, maybe you’re also partly to blame (hint: you normally are).

Git for designers

In recent years I’ve seen many designers prototype in code, but very few of them used any kind of version control. This is dangerous as the wrong change to your page structure or CSS may break something that was working, and make you lose a lot of time trying to figure out what happened. Even worse, you may think that writing code is too hard and fall back to a comfortable tool like Axure or Photoshop.

If that sounds familiar, I’ve got good news for you. Git is a very simple tool to use once you understand a few basic concepts. It also enables collaboration between teams.

Read more

Design agencies and continuous deployment

In this short podcast, UX Advantage Podcast with Karen McGrane: Shifting To Continuous Deployment, Karen talks about the challenges of User Experience in the era of continuous learn-design-iterate cycles. It’s an interesting topic, but what fascinates me is how agencies can help clients to continuously iterate and improve their digital products.

Everything that Karen mentions seems to be focused on in-house teams. But in the UK, many brick-and-mortar companies still rely on agencies to redesign their sites, apps, etc. It’s not trivial to build an in-house team, and a lot of talent is still on agencies. At least in this country.

I see two fundamental issues to be solved:

  • Cultural. Management needs to move from one-off products that are redesigned every 2-3 years, to constant iteration and improvement
  • Economical. Agencies have to be cost-effective, compared to the short/mid term costs of building and running an internal UX team

Once those two are solved, we’ll be ready to face the next challenge, integrate agency and in-house teams.

It’s sad to see you going, Mixture

Final announcement from Mixture

I had Mixture on my radar for a long time, but it was only until last year that I started using it. It’s been a really useful tool as interaction designers tend to be scared of the command line. Its GUI made it easier for a few colleagues in the office to start using preprocessors, templating languages and even JSON.

It’s very sad to see it disappear, and I only hope somebody else will create a similar tool in the future.


Thanks for 20 years of sharing your thoughts

Jeffrey Zeldman’s site was 20 years old yesterday. His blog and his book helped me start a career as web designer, about 13 years ago. Disillusioned with university, I learned about visual design, html and css. I remember how his work blew my mind. A better Internet was possible.

Thanks to him I discovered web standards, and its beauty led me to become a front-end developer and my first job, back in my hometown. I loved shipping sites and compared the code to some sort of modern poetry. But I didn’t stop there, I wanted to create better websites so I became a UX designer.

During the last 10 years I moved to Madrid, and then to London. I grew up as designer, and the ideals of an Internet for everybody stayed with me.

Now I do a bit research, a lot of interaction design and I still write code for fun, and that’s partly because of Jeffrey Zeldman. Thank you for everything you’ve shared with the world.

Prototyping a flyout responsive navigation menu without javascript

Off-screen navigation, flyout menu, navigation drawer, there are many ways to call this common pattern. It’s a great way to save valuable real estate on small devices, and most people is aware of it as many native apps make use of it.

There are hundreds of jQuery plugins out there that can help you achieve this pattern, but I’ve found a simple and clever way to make this work using only CSS, no javascript required. Kudos to Bev from @fofwebdesign for the code. All details and cross-browser code can be found on her Responsive CSS3 Multi-Level, Fly-Out Menu (no JavaScript) post.

What I’ve done is to turn the vertical left-hand navigation into a horizontal one, whilst keeping the left off-screen nav on small devices. As I only need this for prototyping I’ve removed the second navigation level, and most of the code meant for cross-browser compatibility.

In essence, I’ve made it really simple so anybody with basic HTML and CSS skills can use it.


See an example / Another example
Grab the code on

(Resize the browser to check how it works on a small device)

How it works

You’ll need one container for all your content, and another one positioned off-screen for your navigation elements. The latter can be inside or outside the main container. Check the two examples above and you’ll see that it’s possible to place your navigation inside your container, or outside.

Lastly, you’ll need a checkbox (that we’ll hide from the viewport), and a label to select/unselect that checkbox.

responsive flyout navigation without javascript

The CSS will make your elements slide in when the checkbox is selected, and slide out when unselected, so no javascript is required.

The code

<input type=“checkbox” id=“main-nav-check”>

#main-nav-check {

The checkbox is not visible, but it is still important where it sits in your code.

You’ll also need a label to select/unselect that checkbox. And you can make it look like a navicon, or use an image if you want.

<label for=”main-nav-check” class=”toggle” onclick=”” title=”Menu”>&#x2261;</label>

As we’re using the ~ selector, the checkbox and the two containers we’re going to animate (menu and container) must have the same parent. In this case, all elements have the body as its parent.

|_ #main-nav-check
|_ #menu
|_ .wrapper

About the ~ selector – from w3schools:

The element1~element2 selector matches occurrences of element2 that are preceded by element1.

Both elements must have the same parent, but element2 does not have to be immediately preceded by element1.

So, how does this work? The CSS will check whether the checkbox is selected or no, and move the container (.wrapper, that in this case contains the menu as well), 13.75em to the right. And that’s exactly the width of your off-screen menu.

#main-nav-check:checked ~ .wrapper {

No javascript required, just be careful to position the checkbox and elements to be moved as child (direct descendant) of the same parent.

Check the codepen here, and examples here and here (resize your browser to check how it works on small devices).

Improving your design process

I’m a big fan of learning from other disciplines to improve my design process. This week I found an interesting article on UX Booth: Engineering our design teams. If you’re a digital designer go and read it as you’re likely to find something to add to your routines.

The truth is that some of those things have been part of the design toolkit for a long time, just maybe few companies do it.

Quite often agencies (can’t speak for in-house teams, never been in that side of the industry) assign one designer to a project, and that person will have to deal with the production of wireframes, visuals, etc. This tends to be for cost reasons, but working in isolation makes it harder to achieve great results.

At Webcredible we use a more collaborative process, and that ends up improving a lot the quality of what we do. Here are a few examples:

Pair designing

No matter the size of the project, a designer will never be the sole consultant. Having somebody else to bounce ideas off is critical to have more and better ideas.

You want people with different skillsets as that will allow teams to view problems from different angles. For example, pair an interaction designer with a visual designer, a front-end, or a researcher.

I don’t know who did this first, but it’s definitely not a translation of the software’s world (pair programming), companies like IDEO have been doing this for ages.


Informal critiques are always been an important part of our design process, but after reading UIE’s blog post Good, Bads and Dailies: Lessons for Conducting Great Critiques, I wanted to turn this into a routine.

Now we hold Webcriticals almost every Thursday. When a projects is about 50-75% complete, it’s time to gather feedback from a wider audience. The sole process of showcasing your work to your peers brings clarity to your ideas, and the quality of our work always benefits from this sessions.

Project retrospectives

Last thing you want is to forget all the hard learnt lessons, and end up doing the same mistakes again and again (though we humans are very good at it).

Agency life is fast-faced and often you’re dragged into a new project in a few days, but we strive to find time and do a retrospective. Those involved will be better prepared for future challenges, and lessons learnt are communicated to our peers via skill swaps sessions.

Agile’s retrospectives, combined with a Post-up game, are an effective way to capture what happened. But you don’t want that knowledge to stay on a few people’s heads (or worse, getting dust in a file). That’s why we hold regular skill swaps, 1-hour sessions to share a knowledge we have. Sometimes we talk about photography, meditation or cooking. And sometimes we discuss what we learnt in a project. It all makes us better designers.

Have you tried any of these activities? Maybe you use others that make your design process more effective? Find me on Twitter, I’d love to hear your thoughts.

Bye bye Foursquare, or how to save battery on your phone

Battery usage on a Nexus 4I’m not sure if this is a Nexus 4 issue, or happens to every Android device. But from time to time mine decides to stay awake, even if I’m doing nothing with it. Stopping Foursquare put the phone on sleep mode again, so if you have this issue try it, it may help.

I know of a bug on the Mail app that makes the phone stay awake whilst on the train. I suppose that as it looses and regains signal, the app enters in some kind of infinite loop trying to check the network and download mail. It means that unless I kill the app, every time I go see a client my phone is dead in an hour.

Some Fridays ago I was having some drinks with my Webcredible colleagues. Battery was doing fine, and I hoped to have some left to listen to music on my train back home. Then we moved into a pub, I checked-in on Foursquare and… zas, my phone turned into a heat emitting device capable of frying a steak. Battery was dead a few minutes later, something my wife didn’t appreciate.

So when my phone got into hot pan mode a few days ago, I decided to investigate a bit. As you can see on the screenshot, there was a drastic use of energy going home (1). That’s normal, as I was using Spotify and checking some news. Problem is, I got home, stopped using my phone at all, but it was still quickly draining the battery.

A quick charge later, battery was still draining at a ridiculous rate, so we checked what was running in the background. Foursquare was there pretty high on the list, even if I don’t use it at all. So I killed the app (actually uninstalled it), and as you can see (2) my phone went into sleep mode again. That’s probably what happened that Friday night, Foursquare kept running in the background in some kind of infinite loop.

I’m sure there are other apps that do exactly the same, so if you have this issue and don’t use Foursquare, simple go to Settings > Battery, check what’s using it and kill it. Quite likely that is some app checking your location or trying to sync information.

Air traffic visualisation

The guys at NATS (UK’s traffic control provider) have created a beautiful video showing what happens in the UK airspace in 24 hours.

Airspace navigation and traffic control is a fascinating topic, something that very few are aware of, but that keeps all the planes flying securely and on time(ish).

Via Microsiervos (in Spanish)

↑ Back to top