Nordic Design

Design, Music and Life, by Alex Lillo

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.

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

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.

Ignore the user experience at your own risk

Sim City Fail

Electronic Arts learned last week that when you ignore your user the consequences can be catastrophic. The anticipated SimCity launch was an utter disaster, with their DRM system preventing customers to play.

What happened is that the new EA title requires constant Internet connection to play. Is not enough to validate your copy when you install the game, Sim City is in constant communication with Origin’s DRM server to ensure your game is legal.

As a result customers that have paid £45 for the game were unable to play, sitting in interminable queues in front of their computers only to get error messages as Origin’s servers were overflowed with requests. Such was the outrage that even Amazon has stopped selling the game.

Some may say that this is a technical problem: basically the system wasn’t ready for the avalanche of excited gamers, and that soon the issue will be solved as new servers are put in place by EA.

I’m sure this storm will quickly go away. The game is apparently quite good so I expect people to show mercy once they can play. But for me this is not a technical issue, it’s conceptual. Is not about not having enough servers, is about ignoring your users.

And how’s this related with UX? For many the user experience field is confined to the creation of blueprints for digital products (websites, apps and similar). But in reality UX is about caring for every detail of a product, and here’s where EA has failed miserably with an insulting attitude. Let’s see why:

You don’t own the game, you’re only renting it

It’s not nice to spend £45 on a game only to find out that EA can decide at any time if I can play it or not. If sometime in the future EA decides that this version of Sim City is not profitable or wants to promote the next release of the saga, they only have to pull the plug and you won’t be able to play it again. A game you -in theory- own. Don’t be fooled, you’re not buying the game, you’re only paying for the right to play it -until EA decides you’ve had enough-.

EA decides how you can and can’t play the game

Do you have a 12 hours flight to Japan next week? Sounds like the perfect time to improve that city on your shiny new game, but there’s a problem: EA decided you can only play if you’re online.

No Internet connection = no game, so forget about playing on a plane, on the train, when Sky is down or whilst you’re moving houses and your Internet connection is not yet working.

They don’t care about you

EA only cares about your money, and they definitely want to amass as much as possible even if that means ignoring you, the guy who is paying it.

By ignoring their users and putting every imaginable barriers between them and their games EA is achieving quite the opposite: fomenting piracy. It’s like a DVD, filled with unskippable anti-piracy warnings and trailers. You vilify your customers whilst those who downloaded the film illegally can enjoy it without barriers. Not a clever move.

Don’t make things difficult for your customers

If you want people to buy your products, your name is not enough. You have to minimise the pain points and treat your customers in a fair way. If anything you’re doing goes against those that are paying your salary, maybe you should consider a change of direction or you may find yourself looking for a new job soon.

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.

What I’ve learned from my mistakes: Part III and conclusion

This is the last of three posts covering what I was going to talk about during the UXCampLondon. You can check the previous ones here:

We focus too much on the users

I know this is going to sound nuts to some of you, but personally I think we spend too much time thinking on the users.

Don’t get me wrong. Obviously users are key stakeholders on any project but, I’ve seen too ofter how we spent days creating user journeys, personas, etc., without any actual research, or at least enough information. And more often than not, once the journeys and personas are created and signed off, we just put them in the drawer and never revisit them again, or use them as part of our conceptual design and wire framing process.

Then, what’s the point on creating them? Because they are a cool deliverables? “Hey I’m a UX Designer and I create personas“. Because we’re charging our clients for those days? We create them for the sake of following a methodology, another deliverable more?

Personally I believe that unless you do a proper research, and use journeys and personas as a central tool in your design process (the whole process, from beginning to end), that time will be better spent in other things like:

  • User flows. Getting a really deep understanding of how every single page and feature of your website wrongs. A great document to discuss with your developers.
  • Study the key tasks your site/app/etc has to do. As Robert Hoekman Jr. says in his book Designing the Obvious, Situation Centred Design could be a much better approach than ‘User Centred Design’. For instance, if you’re creating an app to upload pictures to Twitter, how relevant is to know that your user is a 25 years old guy, art student from East London? What you should focus is on learning everything about the activity and situation around taking and uploading pictures. The who, what, when, where and why.

I don’t know you, but my projects normally are constrained by time and budget, so I prefer learning about those situations and tasks rather than about the users, specially when there’s no budget for research.


But as I said, I could be wrong, so I’d love to know what you think about these three topics. What I’m really sure is that we have to stop blaming others about what goes wrong, be more humble and think about what can we do to improve our working relationship with other players.

What I’ve learned from my mistakes: Part II

This is the second of three posts covering what I was supposed to be talking about during the UXCampLondon. You can check the first post of the series here.

Clients have no idea

Oh, classic mistake. We love to rant about our clients. They have no idea about the Internet, they keep asking for stupid changes, they don’t listen to us… and the list goes on.

Actually it’s our attitude towards them what generates those problems. Although yes, there are toxic clients, in general they only want to be sure their money it’s well spent. Actually they normally are as exited as us about projects.

Remember my previous point? This is the same. Because our main stakeholder is a marketeer, that doesn’t mean he’s incapable to understand user experience.

Actually he probably knows a lot about their customers. About what his company is doing well, their strengths and weaknesses. A lot more than us, who have a great background in User Experience, but probably know close to nothing about his business.

What I’ve found is that instead of approaching a new project as the expects, it works a lot better if we approach them willing to learn. If we listen to them, if we make them part of the process. They will start trusting us, because obviously we know about our craft, and we’ll have much better information, be better prepared to deliver a product that works, making your client happy.

So the next time your client ask you for stupid changes, think first about how are you treating him, if you’re listening to him and trying to understand their problems.

A way to do this is by being more open, making them participant of the design process. Showing work in progress wireframes, sharing discarded sketches and ideas. Those things help them to understand that we’ve spent hours thinking about their problem from different angles, and will be more receptive to our final proposition.

In the end, clients are paying your bills, so you better have a good relationship with them.


What I’ve learned from my mistakes: Part I

Last week I was supposed to be doing this talk during the UXCampLondon but unfortunatelly I couldn’t make it, so I’m posting it here. 

This is part one of three posts and I’d love to hear what you think about it. I’m pretty sure you’ll have a different view on it. 

I’m the UX expert. I have the ultimate truth.

I had this attitude for ages, and I’ve seen it constantly in other ux’ers. Assuming that only those with an UX, Information Architect or similar title in their business cards can have a valid opinion on user experience.

This creates unpleasant situations, affecting our ability to successfully deliver our projects and ultimately hurting ourselves. We think that WE are right, and the rest of the world is wrong.

Ok maybe I’m exaggerating a little bit, but I’m sure we’ve all seen this happening. It normally leads into a position where it’s your word against the rest, and you end up constantly fighting to make your thoughts prevail. An undesirable situation.

With experience we learn that other people’s views can be as valid or more than ours, specially when we’ve spent weeks or months immersed in a project and our thoughts are not as fresh as desired.

It seems to me that we constantly try to protect ourselves, acting defensively and trying to show everyone that we know about this. Like if we were going to be redundant if we don’t do so.

Actually, I’ve learned that few people wants to do our job. Yes they’re excited about the projects like us, but visual designers, marketeers, developers etc don’t want to do our job. They solve different types of problems, they think in a different away. They find journeys, sitemaps and wireframes really boring. It’s ok if someone else do them, but I’m sure they they don’t want to take that role. That’s why they hire us.

So we should stop being afraid of accepting other people’s ideas, that doesn’t make us more vulnerable. Quite the contrary, it strengthens our relationship with peers and clients.

↑ Back to top