Nordic Design

Design, Music and Life, by Alex Lillo

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.

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.

How long it would take us to hate Material Design?

I have to say that, right now, I love Google’s material design. It’s fresh, easy on the eyes, affordable enough, and has as little visual design as possible. The right middle point between the silly flat design, and the pompous skeuomorphism.

But as any trend, it will soon fade and people will hate it, make jokes about it. At least we designers will do it, we’re a bit nerdy sometimes.

In the meantime, if you’re building a website and want to quickly make it look nice and modern, here’re a couple of frameworks to materialise your design:


UX is a way to measure a product’s quality

You’ve probably heard/asked the question many times: What is User Experience? Ask it to a 100 people, and you’ll get 100 different answers.

If you look at the job roles in the industry, UX is related to the user research and design of digital products, in particular websites and mobile apps. So it’s understood as a discipline, like Graphic Design or Project Management.

User Experience (UX) involves a person’s behaviours, attitudes, and emotions about using a particular product, system or service. User Experience includes the practical, experiential, affective, meaningful and valuable aspects of human–computer interaction and product ownership. Additionally, it includes a person’s perceptions of system aspects such as utility, ease of use and efficiency.

(Quote from the Wikipedia)

I don’t think User Experience is a discipline, but a way to define the quality of a product.

I’ve said many times that UX happens whether you want it or not. It’s like quality, can be good or bad. You take care of many details and that increases a product’s quality.

When you design a product, you may create a great User Experience, that’s a quality that defines it. But you’re never doing UX. You’re designing to create a great UX.

You can study a product’s User Experience, though, so in that sense UX is more related to research than design. The understanding of an audience’s behaviour and needs, the study of a user journey, the different touch points your customers interact with your business, all that is the study of a particular User Experience. It’s the ammunition you use to create something better.

If you’re creating something, if you’re solving a challenge and exploring new solutions, you’re not UX’ing, you’re designing.

A More Robust Design Process with Use Cases

Digital projects vary in shape and size. Some allow you to keep a lean and simple process, whilst others require a more robust approach. Those normally involve hordes of Business Analysts, so I thought it would be a good idea to study their process and see if I can reuse something.

There are times when it’s difficult to draw a line between BA and UX. Business Analysts define a system’s behaviour and thus they’re designing it. We do that too, but we approach it from a very different angle. Nonetheless some of their tools could be useful in complex UX projects, and there’s one that interests me especially: the use case.

Use cases in the design process

Use cases come in many flavours, but normally have a combination of: plain English descriptions of what a page or functionality should do, flowcharts, data formats, user stories explaining the actor, narrative and goal, and basic and alternative flows.

Use cases are goal-oriented, and that’s great because the majority of our work as designers is too. We specialise in solving problems, and many times that involves designing tasks so users can fulfill their goals. Describing what happens in a task step by step, considering not only your Sunny Day cases but also the infrequent ones, exceptions, etc., can only help your design process.

I like to list the key functionality of a system with all the imaginable scenarios, and then check whether the experience of use is correct or not for all of them. I consider things like: accessing via google, session time-out, logged-in and out status, first-time or recurrent visit, no network, etc.

It’s incredibly useful to define those scenarios and subsequent workflows with your client, and then sketch some quick solutions. Having a common understanding of how a task can be solved will bring you two benefits:

  • Your process is more transparent, and you won’t be seen as a magician
  • Your will get client buy-in, as you defined the solution together

In some circumstances I use user stories, as they are easy to understand from a developer to a senior stakeholder. User stories normally look like this:

  • As a…
  • I want to achieve …
  • So I do …

And example could be:

As a logged-in customer, I want review my previous orders, so I can reorder them.

As you can see, there’s a clear goal your user want to achieve, to reorder past orders, and you write the story around it. The story should obviously be aligned with your requirements, and based on the user needs and goals identified during the research phase.

Tell me how big you are…

Your project’s scale should dictate how deep you want to get into the use cases. For a simple redesign user stories will bring focus and help convey the important messages or functionality. It will also help you make less mistakes.

Bigger projects will benefit of a more expanded approach with user flows and document maps, turning vague wireframes into more structured and documents that can more easily be digested by developers.

Large-scale ones will inevitably require the involvement of BA’s, so in this case you’ll need to sit together and decide who can bring what, separate responsibilities and clearly define:

  • How your design and analysis processes are going to work together
  • What your final deliverables are going to look like.

And remember, these are just suggestions. There are no clear rules for each case. You’ll always have to analyse the project and audience, adapting your design process with the best weapons of your toolbox.

Should designers embrace developers’ tools and processes?

During the second LDNIA#1 talk Collyn Ahart said that on some project they took an ‘Agile Planning’ approach. It was a short mention but some time later a fellow UXer was ranting about it:

“UX shouldn’t use Agile. It’s a tool created to ship software, not design”
(not literal, I don’t remember the exact words)

The conversation moved on to excessive research (yeah that’s right, excessive), but that phrase stuck in my head on my way home. I’ve been reading recently a bit about agile and development, and I find concepts like test-driven development, just-in-time design or the Kanban board really clever tools.

So, should designers use those developers’ tools?

Task-driven design

I’ve been thinking about how to incorporate test-driven development into my design process. The only way I can create a test that fails before I mockup a concept is to use an empty canvas, and that’s not very helpful is it? But I can write all the cases I need to cover before I start sketching a page, and treat them as my tests. Having that list in front of me whilst I visualise the concepts helps me stay focussed on the task and, once I’ve finish, I can go through the test list to make sure nothing is missing.

Axure prototype with variations


This can’t probably be called test-driven design, maybe task-driven design. And it may be that every designer except me is doing this, but I’ve taken this approach recently and it helps. I’m more organised, I work faster and it’s much easier for the client and their tech team to validate my work.

Just-in-time design

A lot has been written about just-in-time design lately, as the Lean UX concept has been buzzing the internets. It all started as a way to reduce waste inspired by the lean manufacturing process created by Toyota years ago, and again I think it just makes a lot of sense.

The User Centric Design process is quite often long and expensive, so I’m not surprised that many firms just skip the whole UX part and jump directly to graphic design and build. They probably see the benefits of UX Design but find it excessive. A nimble, just-in-time thinking would suit those firms and dramatically improve their products.

Same with Kanban, last year Caplin showed us how they embraced Agile and it was really inspiring. I wonder why we don’t take a similar approach on projects that require design and build.

It just works

Are these tools damaging my ability to solve design problems? Are they specific to the development world, or could they be applied to any other creative process?

If a tool works we should add it to our toolbox, regardless its origin. I don’t care if it’s a developers’ tool, what I need is to have the best tools in my pocket as no two projects are the same. I’ll decide then what to use, and that may be something inspired by the software development industry.

Is Responsive Design a one-size-fits-all solution? An online video industry view

Responsive web design is the hottest trend of the moment, the silver bullet that is going to solve all our problems. But does it work in every situation?

At KIT digital we design online video platforms, and I’ve found that this industry’s particular rules and constraints make responsive design a lot less exciting.

The main benefit of responsive design is to serve one site to multiple, unknown devices. It’s future-proof, and allow us to customise the experience for devices with different capabilities, both in terms of screen size and features.

Now think about the online video industry, where Digital Rights Management (DRM) is an absolute requirement. Studios and content rights holders don’t allow sites to serve certain content unless their video player is DRM-protected. And one of the preferred solutions for DRM-protected video players is Silverlight. A great, solid and dead technology. Only available on desktop operating systems, that will never get to your mobile, tablet, connected TV or Internet-enabled fridge.

Does it make sense to create a responsive site using Silverlight? No.

If a user access a Silverlight-based website using a mobile phone or a tablet, she will never be able to watch a video as Silverlight isn’t available on that platform. She’ll need to use the native app, that has a DRM-protected player. Take for instance the new Demand5 iOS app that now has more shows available:

We’ve implemented a new Digital Rights Management system that meets the security requirements set by the larger studios and production companies, which means we can bring you even more shows.

From the Demand5 iTunes page.

In that scenario the benefits that a responsive approach brings are minimised. Yes, the user will still be able to use more easily other features like account management or playlists, but the main purpose–to consume video–will be blocked by technology constraints. If you don’t have an unlimited budget it makes sense to limit the scope of your site and design it using a fixed layout.

Once new technologies become available this scenario will change. Hopefully we’ll have HTML5 video players that fully support DRM making Silverlight unnecessary. That day one site could serve every platform, making native apps somehow superfluous. That day responsive design could save online video companies millions of pounds. No need to design, build and maintain one app for each device.

↑ Back to top