A Year without layout pictures

I’ve been working with the new kauppalehti.fi site a bit over year now and noticed that I haven’t created a single layout picture. Why? I’ll go through a traditional design process that I was familiar with and how we are designing services at Kauppalehti.

Traditional design process

Traditionally a projects starts with the design — layout pictures created with Photoshop, InDesign or similar. The size of a logo, typography, graphical elements, buttons and links are pixel-perfectly stylized.

Layout pictures are then sent to customer for approval. Often these layout pictures are then commented and then sent back to designer. Normally this step repeats 1 to 10 times, depending the amount of pictures and change requests.

This traditional design and approval process leads to several problems:

Design approval

By evaluating the layout pictures the customer is approving the look & feel of the service — “Okay, this is the service I will get”. Most designers forget that the layout pictures communicate a lot more than intended look & feel. Almost every single web page contains some kind of interaction.

Interaction can’t be communicated with static images. Designers know this but customers don’t. Customers approve a service design which interactions are an assumption based on own experiences and preferences. It’s not uncommon that the customer wants to be sure that the design is meeting these preferences: “could you make me a layout where the user mistypes her password?”, “we are missing the pictures of the purchase process.

User Interface Design

At this point the designer starts to think the user interaction in different situations and the visual design is transforming into user interface design. Sneakily the number of layout pictures could be easily grown from 1–3 look & feel pictures to 10–20 detailed user interface designs. Because the customer wants to be sure what to approve.

But still there is something that can’t be communicated with detailed user interface pictures containing several use cases based on user behavior: how does it feel to use the service? How does the elements look like when a user mouse over them? Does it feel fast and snappy? Does it work good on different devices?

Prototype to the rescue?

Customer asks the designer to change button color from blue to green and the font family from Georgia to Open Sans through the site. The designer is probably a bit frustrated with these changes, because it takes at least a day to make the changes in layouts.

The designer knows that the changes would have been 5 minute job to do in a web page. So the designer asks for the customer that could we make these design changes in a prototype version of the site?

Live site sounds good for the customer and the designers and developers start to build the prototype — keeping in mind the changes that were not made in the layouts but should implement in the prototype. Eventually the prototype finishes with the changes promised.

Customer has learned how to approve the design photos but faces now a new challenge: how to accept a prototype?

The prototype doesn’t feel good to use: the check out process is not smooth like Amazon. Error messages seems to be a bit too harsh. Why the site has a hamburger menu () when I’m using it on my phone? The customer calls out a meeting where these issues are discussed. This was not exactly what they were expecting.

How it should have gone?

Start designing together. Use pen and paper for rough sketching of site structure, navigation and element positions. If something doesn’t seem to work, start again with a blank paper, it’s almost free.

After both the designer and customer agree on the hand-drawn sketches or wireframes then — if needed — use a Photoshop to visualize page or two. Tweak the colors, typography and other visual elements if you think in that the layout can help you to launch faster.

Based on the wireframes developers can easily start to work with the prototype, since they would know the crucial elements of the site. It may look ugly, but it works. Use the unfinished version of the prototype as early as possible and shape it to fit your needs.

Design will rot

Wireframes, layout pictures and user interface designs are only tools to communicate an idea of a service, not the outcome. As the world keep on changing, design will rot.

User behavior changes, different devices are used and new design patterns are being introduced almost every day. It’s nobody’s interest to keep the drawn designs up-to-date. Focus your energy in changing the service rather than pictures.

My tips for designers

Learn HTML & CSS enough to create a prototype layout. Try to make the layout from scratch without any layout pictures. It’s surprisingly easy to modify colors, typography, element positioning and whitespace with HTML & CSS.

Learn some Javascript for simulating user interactions. Toggle element visibilities, display error messages and so on. Google and Stack Overflow are also good friends, others have probably been working with the same issue whether it’s design or programming.

Almost every developer I’ve met has been really helpful in programming related issues or challenges. I’m still a terrible programmer but advanced enough for making a prototype from scratch (without Photoshop) and tweak the user interactions (Angular, jQuery). Actually I’ve learned so much from my co-workers that I can now build a full service — backend and frontend — on top of a MEAN stack. And that’s cool!

If the customer asks for a layout picture for some new functionality or design change — ask yourself that is it really necessary? For the last year we needed layout pictures once. Even those photos were actually screenshots of HTML prototype.

Sharing is caring

Our website changes all the time, sometimes four times a day. It would be disastrous to keep layout pictures up-to-date with all the changes we are making. Instead we are maintaining useful CSS (Sass) library that each developer or designer can use while maintaining the look & feel of the site.

I’ve created a common shared assets of fonts and font icons in CDN (just like Google Fonts + Font Awesome). This way we can help the consistency of the typography and icons used across different services created by another teams or contractors.

My tips for customers

You should have some kind of a vision of the service that you want. What would be the most efficient way to get the service up and running? Hire a professional team and start sharing your thoughts. Show some examples that you might have in mind. Print out some of your favorite services or examples certain elements and start drawing based on those.

Normally website project or a new feature process is something like:
1) design
2) programming
3) testing
4) tweaking
5) acceptance
6) launching (and maybe a little panic)
7) maintaining

Try to reverse think this path. What would be the actions to reach the launch at the most efficient way? If you are already familiar with this kind of process — how could the team adopt to a new one? You can of course ask this question for your designers & developers.

Try to start with prototype and evolve it into functional service. That way you can combine design, testing, tweaking and acceptance phases and focus on the service it self. Of course there will be steps — like programming — which can take some time to finish. Launch the prototype when you think it’s good enough. Remember that it’s your service and it’s never ready.

It’s all about trust and communication

If the designer thinks that there is no need for more detailed layout picture(s) and/or the prototype could be done based on the wireframes, listen to him. Good designer knows which is the most efficient way to get the service launched.

Meet your designers and developers face-to-face. This is extremely important. If the designers and developers don’t know you in person it’s really hard to figure out your intentions or emotions from email.

A kind feature change request may seem as unhappy customer nag. Instead of email use some group chat tool like Slack or Flowdock. If something doesn’t work as expected: communicate — meet the team if needed.

If the design & development team is not responsible of the project expenses be sure to negotiate these issues with someone who is (not the team).

This was my first public blog post ever, so I would be more than happy for any comments or feedback! You can also follow me on twitter: @AkiNaerhi

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.