Nordic Design

Design, Music and Life, by Alex Lillo

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.

On swarms and squares

If you’re one of those that like to check-in at every place you go, you’ll know that now foursquare has a dedicated checkin app, Swarm. The old app is now all about exploring the city.

As every time a popular service changes, the Internet has gone nuts. People has started to publicly state that they are about to stop using it. Like if anybody cared.

Why so sad?

Apparently they don’t like the product decisions at Foursquare. I suppose that’s fine if you work for them or own shares on the company. I can see a shift this size affecting the app usage. But for a mere mortal like me, well we’re just a merchandise for them to trade.

Personally, I don’t care about them splitting their functionality in two. Actually, I’ve always found the recommendations side of the app pretty useless, so that angle won’t be missed from Swarm (if I’m looking for a nice restaurant nearby, one that’s 9km away from me is not helpful, thanks).

And I quite like the way they’re transitioning from one app to two. I’ve found the process quite smooth, even if Swarm is quite different from Foursquare. So I’m enjoying the transformation (and taking screenshots of it, you never know if a client will need something similar in the future).

Ultimately, people don’t hate change, they just hate when you change things for the sake of changing. Maybe the new Foursquare will be so amazeballs that everybody will agree that the move was genius. Maybe the app will fade, become irrelevant and be sold/close, like gowalla, who knows. But in the end, it’s Foursquare’s decision. Disagree if you want but, why so emotionally?

Extra ball

That guy complaining about the horror that is their forced Swarm app install, works for Facebook. A company that forced users to install their Messenger app if you wanted to keep chatting with your friends. But probably that was ok. </irony>

2nd Battle of St Albans re-enactment

Living in the British countryside it’s easy to find little fairs and celebrations about all sorts of things. Last week the Medieval Siege Society remembered the 2nd Battle of St Albans, so it was the perfect opportunity to take my camera out and photograph something different than my daughter.

medieval lady

The battle took place on Bernards Heath in 1461, as part of the Wars of the Roses. More info about it on the wikipedia.

It's a hard life

Apparently the First Battle of St Albans (1455) marks the beginning of the Wars of the Roses. So if I they ask me that type of questions when I request the nationality, hopefully I’ll get this one right!

A few more photos on my Flickr set.

A bit of music – Poliça

According to the blog’s tagline this is also about music, so here’s one of my favourite bands of the last 6 months, Poliça.


It’s not me, it’s you Feedburner

I still use feedburner to serve my blog’s feed, but given that Google stopped supporting it like 2 years ago, it’s time to move on. I will delete the feedburner feed soon, so please update whatever you use to read me to the new url:

BTW, you probably already use it but I recommend Feedly, a great free feed reader.

On lean and documentation

Andi Plantenberg from Neo writes about using lean UX on secret project where you can’t get out of the building to validate your hypothesis. There’s a paragraph I particularly like about fidelity and documentation:

Work low-fi. It’s important to acknowledge that the starting vision is wrong, wrong, wrong. It will need to change as you’re building. So we work fast, low-fi and towards a common goal. We think aloud as a group, favor white-boarding to wireframes, favor hacking up screenshots rather than maintaining PSD masters. We favor the product over design artifacts and documentation. Get over it. Your product is the documentation.

Unfortunately not everybody understands this reality, and we have to educate a few clients overcome their fears about the lack of documentation. Good progress is being made though, and I expect that in a few years those that understand and embrace digital will prevail over their more traditional, documentation-heavy colleagues.

MailChimp Pattern Library

MailChimp’s pattern library is public and if you want inspiration about how to use one, or maybe you need to create one, you should definitely check it.

The MailChimp Pattern Library is a byproduct of our move to a responsive, nimble, and intuitive app. Constant iteration requires both an efficient workflow and a well defined collection of atomic elements that can assemble new UIs quickly without accruing new technical or design debt.




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.

↑ Back to top