Nordic Design

Design, Music and Life, by Alex Lillo

Prototyping with CSS grid

Last week I finally took a deeper look at CSS grid, the new way of creating layouts supported by all major browsers since early 2017. Until now I had just used it for very simple grids, the image gallery kind of ones. An hour of reading later, I was amazed by its power and simplicity.

So what is it exactly? Is it like flexbox?

A key element of CSS grid is that it creates rows as well as columns. That makes the distinction between flexbox and grid very simple:

  1. Use flexbox for 1-dimensional compositions like rows or columns. E.g. tabs, your primary navigation
  2. Use grid for 2-dimensional compositions. Like defining a *ahem* grid for your content areas (header/sidebar/main content/footer, etc.)

How it works in a nutshell:

  • You define horizontal and vertical tracks, delimited by grid lines
  • You assign areas to use one or more cells created by the intersection of the grid lines, in whatever place you like, as long as it forms a rectangle (no Tetris shapes yet)

Example of css grid layout

(Image from CSS-Tricks CSS grid guide. You should totally check it out after you’ve read this)

A key consideration is that you don’t have to fill the grid. Think about it as the holes of your IKEA furniture. You can use them to put hangers and stuff on them if you want to, or leave the shell empty. With the added benefit that the tracks can grow with the content. It’s like having a wardrobe that grows as you put more clothes in it!

(Image from CSS-tricks)

CSS grid is so flexible that you don’t even have to assign explicit areas. Any child element of the grid will automatically use the next available grid space, from the top left corner (when writing in a western language). That means that you can perfectly layout an image gallery in seconds.

Then you can use CSS to reposition that content, maybe for another platform. This makes the separation of content and presentation a lot easier.

An example

Let me show you what I coded last week. Inspired by Jen Simmons’ Modern Layouts presentation, I wanted to create a layout for our intranet’s staff page that didn’t follow the standard main content + aside columns, but would rather use a more complex layout inspired by print magazines.

Start with the content

Having more flexibility to define fixed sized areas and flexible ones that use any available space, I started with chunks of content without a particular structure. Exploring what width and order were appropriate on different viewports to tell the story of that person, while trying to use a 1.414 scale to ensure all typographic, image and text elements were harmoniously related.

It was an iterative process to assess what seemed like ideal sizes for a given viewport size, and then how the different elements would adapt, what should maintain its size, what could flex.

Early concept of how chunks of content could be positioned:

Create your grid

Once I had a rough composition, I looked at what grid lines and areas would be needed. Time to get off Sketch and into the text editor. Turning those lines and areas into code was a bit of trial and error, but nothing you won’t understand in less than an hour.

#staffPage {
 display: grid;
 grid-template-rows: 10em 8em auto auto auto;
 grid-template-columns: 18.8333333333% 1fr 32.9166666667%;
 grid-column-gap: $baseline*2;
 grid-template-areas:
 "photo name links"
 "photo biog coached"
 "profile biog coachingRel"
 "quote quote coachingRel"
 ". experience coachingRel";
}

With the grid structure ready, adjusting the different breakpoints took literally minutes. Try to do that with a framework!

 @media all and (max-width: $medium-break) {
 grid-template-rows: 10em 4em auto auto auto;
 grid-template-columns: 18.8333333333% 1fr;
 grid-template-areas:
 "photo name"
 "photo links"
 "profile biog"
 "quote quote"
 ". experience"
 ". coached"
 ". coachingRel";
 }

The result

Once you understand how the grid works it’s very simple to create different types of layouts that would have been an absolute nightmare to code using floats, opening the door to thousands of ideas that would’ve been considered crazy just a few months ago.

Staff page on Webcredible's intranet

If anything, designers will have to work hard to get out of our comfort zone and start creating compelling layouts that get the most of the medium.

What can I do with CSS Grid?

If you are a UX designer with basic HTML and CSS skills, you can use CSS grid to quickly prototype responsive websites in code. Ignore frameworks, you don’t need them anymore.

For example, I really like what I call content prototypes, very low fidelity designs that help me assess the basic grid and visual hierarchy of the content, in code, using actual devices. CSS Grid is perfect for this and will make my life a lot easier.

Learn how to do it

A great place to start is Rachel Andrews excellent site Grid by example. She also has a book that is high on my to read list, Get Ready for CSS Grid Layout. And her talk in An Event Apart will give all the basic knowledge of how to use CSS grid.

Jen Simmons’ talks are an amazing source of inspiration too, and I plan to follow her recommendation and start paying more attention to print, getting ideas to create different compositions that elevate the content on the web, getting us out of the standard header + 2 columns layout that we’ve been using for the last 15-20 years.

What do you think, would you use CSS grid to prototype?

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.

 

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.

Critiques

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.

↑ Back to top