and Breaking Down the Design/Development Barrier

The design department (the user interface and user experience kind) has always tried to influence the entire production lifecycle of a product out of an instinctive need to improve upon it from every angle possible. The same applies to modern day page & app design where the design department needs to have input from the very earliest concepts of the product all the way to construction and delivery. In this day and age and in the most forward thinking design departments, we are all designers. For this reason there is more and more overlap and connection between the various departments and indeed a complete breakdown of the siloes and walls when we form agile, multi-disciplined development teams. Here I want to talk about the overlap between design and front end development using component driven development.

Component driven development is all about centralising, unifying and simplifying the design/development cycle. In the simplest terms, before any development starts we have the UX cycle which takes the product from concept to a well researched and tested set of wireframes and stories. These wireframes and stories are naturally closely linked. They are also closely linked with our library of components allowing and developer to quickly read the story, see the wireframes, and then pick the components needed for the view.

After this, in a perfect world, it is just a case of stitching the parts together for a release candidate. This works well in a close knit, multi-disciplined team as well as across teams so that aspects can be farmed out to other offices or even other companies.

The Component Library

Component driven development relies on three main branches coming together at a point where development has a complete understanding of what is being built, together with the component parts required to do so. Here I will talk about the third branch: the component library.

What is a component library? A component library is just another name for a living style guide or pattern library. It is a central collection of all the elements, widgets, colours, fonts, sounds, animations, etc. used to build our apps/pages. In short, if a user interacts with it, it should go in the library. It is formatted in a way that is easy to use, link to, or copy and paste .

There are many reasons for this but here are a few key ones:

• Faster development time
• A common, centralised and unified style
• In part already tested, and so fewer defects
• Better code control leading to better security
• User tested patterns

This marriage and breakdown of departments where stories, wireframes and code are so closely locked together can only lead to improved products both from the business point of view with a quicker/cheaper turnaround, and from the user’s point of view with a higher quality experience.

The library is the design department’s masterpiece. It is what we build and horde and lovingly tender to and refer to it as “my precious”. It is a living document that we update and renew and police. It is a powerful device, but the true power comes from the overlap of design and development. The truth is that a modern, living component library is just as much Development’s and it is Design’s with all the HTML, CSS and JavaScript that can go into them. If we did not break down these borders however, we would not see this new horizon of possibilities.

Conclusion

If you are running a design department and have not already done so, break down those walls, build your nest of components and share it with any and all who are involved. Make it the bible for your wireframes and stories and you and your business will have a much better and more productive time of it.

Note: none of this is to be confused with Test Driven Development, but instead considered complimentary. In fact TDD can be improved by having common tests for individual components.

Welcome to Talking the User Language, a look at the role of the designer, and the basics of getting a client to understand a product.

Sections

• Languages. Developer language, designer language.
• Scale of communication Art to bomb
• ARC Triangle – Understanding
• Encouraging creation by allowing mistakes and iterating
• Idea to reality graph – Concept, Planning, Sketch, Wireframe, Prototype, POC, Deliverable
• We are all just problem solving

Translating the Application

The simple answer is: the conveying of information. This can be done using words, but a more elegant solution might be to use colour, sound or animation. Take for example a list of buttons. One of them is the primary button, the others are merely optional. How do we convey the message/communicate the fact that one of them is primary and probably the best option? Perhaps colouring it blue while the optional buttons are grey? Perhaps it is animated and jumps to get your attention? The choice depends on what will best communicate, and to know what will best do that we need to understand the foundations of communication.

A developer is very much tuned in to the language of a computer. It is what they are trained to do. Although he or she will seldom read binary, the computed conversion is a logical, direct translation of the digits. The mind of a developer then is very much used to the language of technology. This is the developer language. A product that is produced by a team of developers will be logical, do what it is meant to do, and probably do it very well assuming the end user is trained how to use it. I say trained because the end user will have to understand the developer language in order to use the product.

The designer’s job is to translate the language of a technology into the user language. The user language is a wonderful thing, not just made up of words, but also colour, emotion, expectation, sounds, animation, sensation, consideration, time, space and more.

Design is understanding

Talk about the user language

Design is elegant

Talk about finding the elegant solution.

To a company built by developers, run by developers and strongly staffed by developers, a designer can perhaps get a little lost. There seems to be no doubt that “design” is a necessity, but this can be more based on gut instinct than hard fact, so let me explain the necessity.

The products we produce and sell do a job, and they do it well because they have been produced by a skilled team of people who know what they are doing. You actually don’t need a design team to do this. Logic is all you need. Problem solving is the key. We produce problem solving software which does its job perfectly logically.

So why have designers?

There is the obvious, which is, to make the products look nice. This is the superficial job of graphic design in order to make our applications “pretty”. This may be obvious, but it is in fact not true. It is false. It is so obvious that it blinds us to the true task of a design department. What is true however is that if a design department does its job properly, the product should indeed look nice or at least have the optimum look for the task it performs. This is why the term “designer” has erroneously become synonymous with the term “graphic designer”. Graphic design is just one part of the design department’s arsenal of tools.

So what is a designer if not the guy or girl who spends all day playing with Photoshop, you may ask? Let me cut to the chase and give you the answer:

A designer works in the design department and the job of the design department is to ensure that the company’s products communicate with the end user in a language they understand.

The user language is not pure logic, hence the translation. The user language is fluid and can change over time. It is influenced by an end user’s depth of knowledge of our applications, fads, technology, culture and many other factors. Application documentation, training and support is an attempt to educate the end user. This is changing their user language to the logic we have dictated. In a perfect world, the application would speak so clearly to the end user on its own that none of this education is needed, and the design department aims for this. It is probably unrealistic to expect such a perfect design, but we aim as high as we can. We aim for a user language that at all levels instils understanding and confidence for those that use our applications.

The design department is all about communication. With proper communication comes understanding and with understanding we get a happy user. You may have heard the term User Experience. We focus on ensuring the optimum user experience for our end users. The front line is the look and feel of the application, hence the use of graphic design, but it goes much deeper than that. In fact it reaches right back to the prenatal stages of the product because we need to always and at every step remember that our applications will be used by end users. For this reason we get involved in the flow of a product, how it does what it does so we can ensure that it is doing it in a way the end user can understand.

Understanding

Understanding is born of these factors: Reality and Communication. Together they dictate the level of understanding.

Understanding – let’s have a look at it, break it down and discover how a full understanding of the word Understanding can help us to improve a user’s experience. UX is after all about finding the elegant solution to UI problems. If we know

Reality is just how real something is to somebody. A computer can be a very unreal device to some people. A Bacon ice-cream is unreal to most, yet to some it might be a very real prospect. When you get the reality you also get communication. If you love bacon ice-cream and met someone else who loves it, then you start talking. The communication goes up and an understanding grows. Another example is Microsoft Excel. To some people it is an unreal and mysterious table of rectangles, to others a fine example of how to organise numbers and data. If reality grows, then communication grows.

It works the other way too. If communication grows, then reality grows with it. One can talk to a person about the benefits of a bacon ice-crème. That person would start to see the concept as more real. The same can be said for Excel. Simply talking about the reasons for all the rectangles suddenly makes it real to a person who has never seen it before.

As both reality and communication grow, they form understanding.

As designers we can use this knowledge to help the end user understand the products. We can make the application more real and communicate better. Real in this case would be to make sure we are not doing things in a way that is radically different from how they have done things in the past. It is designing in a way that is expected by the end user which means that we have a modern look and feel, with a system of messages, buttons, forms etc. all placed predictably and functioning as expected with certain considerations taken into account such as screen size, readability, amount of content, speed of device and more.

Another example of making it real is to look like you mean it. An accounting application cannot use Hello Kitty icons with a pink background and dancing hamsters. That would be totally unreal. Real in this case would perhaps be an understated colour palette designed to allow high readability of multiple columns of numbers.

Communication comes in many forms from the written word to the colour of message box, red being a warning. Sound, animation, layout, icons, images… anything can be used to communicate and it is the designer’s task to find the most elegant solution.

The power of a good communication cannot be over stated.

Imagine a scale of communication. At one end it is light, easy flowing, understandable and accessible – art would be the very boundary at the far end. On the other end is the bomb. It is a gradient scale from air to solid. As you slide down this scale you go through aesthetic, beauty, boring, jarring language and poor imagery, shouting, punching, bullets, and finally The Bomb. Each end is just as powerful in their own ways. Did you know that punching someone is a form of communication? It is, but in our current civilisation it is just not a great way of doing business. In others it has been very effective, just not very friendly.

The middle gets ignored. It’s boring. It has poor understanding. We want to be up higher. As high as possible, or as low as possible. Just not the middle.

We now know that the design department translates the language of the application into a user language. We also know the reason

SLIDE 1

Developer and Designer Sitting in a Tree

SLIDE 2

Aimed at developers, BAs, Testers, Project Managers, Product Owners etc

We are the Arts and Crafts Department

It is a craft and can be an art

SLIDE 3

What is Design?

We are all designers

We design a solution to a problem every day

The design department design user experience solutions

First off let me point out that we are all designers. We take a problem and design a solution. That is what a designer does, but today, right now, right here, in this day and age of pixels per inch, touch friendly, power hungry desktops, laptops, tablets, and mobile phones… Design (with a capital D) i.e. the design department of a web application company… is all about the user experience.

SLIDE 4

So what makes a happy user?

A happy user is a person who switches on her screen, with intention of getting or entering some information, and manages to do this quickly, easily, with confidence born of understanding.

SLIDE 5

What makes a happy user?

Understanding

Knows what to do

How to do it and knows when it was done right

When I say confidence, I mean that she knows what she is doing, has done, and knows that she has done it right. She knows this because the application has shown her how to do it and how she did, in a language she can understand.

Let’s assume for a minute that the server side code – the logic and data going on behind the scenes is all working. The developers have done a great job and it just works.

SLIDE 6

This is brilliant, but… that is only half the story. What needs to happen now is that all that clever stuff needs to be conveyed in a language the user can understand.

This is where Design steps in and translates the language of the technically minded to a more universal one.

Translations like this happen all the time. For a developer who is sitting there with a page of c# or classic ASP, life makes sense, but what if the equivalent page of C++ is placed before them? It would probably make some sense but it would also start to get confusing. The developer would no longer be confident. Take another step and the page is now Assembly!  Keep going and we hit Machine Code and so on all the way down to the movement of electrons. You have to hit the right language to instil the confidence.

The point is that we all speak many languages, but we do not all speak the same language.

Design tries to talk a user language.

SLIDE 7

The World of Design

Where does design fit in? As the translation from development to end user, design fits in between the two. This is the interaction space, often the screen space, the physical input and output devices placed in front of the end user. Mostly this is the screen, keyboard and mouse. It can be the tablet, mobile phone or any other device that interacts with our services and applications.

Whatever the end user sees, reads, writes, clicks, listens to etc. is the realm of Design.

Our job is to worry about the understanding of the end user and we worry a lot. In fact a good designer like any good developer can be quite passionate about it. We think about how best to present data to an end user in a way they will understand. We use graphics, layout, style, flow and key words to do this.

We worry about the best way to convey the concept. Where should this button go? What size should the font be? How do we handle huge tables? When you click the form button, what does the end user both need to know and want to know? How do we make a complicated concept simple and quick to understand?

SCREEN 8

Designer 2.5

As a company, we build web applications. This is web 2.5. However you describe web 2.5, we are there and with it comes designer 2.5. This person, people, department has the job of making the world of servers, databases, rows and columns, strings, integers etc. all understandable to the end user.

To do this job we have to be able to transverse the boundaries of both development and end user. We have to understand the language of the machine and the ideas of the public.

To this end we have tools which are commonly Photoshop, HTML, CSS and JavaScript, or some similar combination.

‘A designer who does not write markup and css is not designing for the web, but drawing pictures’ – Andy Rutledge

Note how we have to use a graphics editor in combination with three other computing languages to be able to convey the message. It is an odd set of skills to bunch together, but this is how it has to be if we are going to translate the ways of a machine to the ways of an end user. Designer 2.5 (a person or department) has to speak many languages to create the final User language.

Designer 2.5 is constantly looking for better ways to talk to the user with new tools and methods and practices. We love to push the limits further and further in search of a better experience. There is an ocean of tools out there from funky new JavaScript libraries to CSS/HTML/graphics editors and we check them out and try them on for size. We might go too far, in fact we have gone too far outside of the comfort zone of the business, but we still have to try, and keep pushing.

SCREEN 9

User Expectations

Having established that Design is all about communicating to the end user, Design always needs to keep in mind what is expected by her. Firstly, we aim to make a user interface as simple as possible. We look for the most elegant solution to each problem. Some simple tricks we use are a unified, consistent design, using a modern look and feel, making sure elements line up properly, use images that are recognisable such as icons and so on. Clean and simple.

With an elegant solution comes a certain beauty or even an aesthetic. If you get things as simple as you can, as straight forward and clear and obvious as possible, the look and feel side of the job is half done.

SCREEN 10

We have to know what the user expects. This is all about realities or trends. What is the user’s reality? What can they relate to? A geocities design from the 90’s was hot, cutting edge and very real back then. Today it is just a horrible and totally unreal mess. We have to look at what people can relate to in the now based on trends and the target audience. This is what real is. It helps in the communication process to understand this and keep the reality common. A common reality creates a high level of communication and a high experience.

SCREEN 11

Communication is power

The power of getting the communication, the design right is akin to the power of a nuclear bomb, but at opposite ends of the same spectrum.

SCREEN 12

Imagine a scale of communication. At one end it is light, easy flowing, understandable and accessible – art if you like. On the other is The Bomb. It is a gradient scale from air to solid. As you slide down this scale you go through aesthetic, beauty, boring, jarring language and poor imagery, shouting, punching, bullets, and finally The Bomb. Each end is just as powerful in their own ways. Did you know that punching someone is a form of communication? It is, but in our current civilisation it is just not a great way of doing business. In others it has been very effective, just a bit anti-social. Social to anti-social.

The middle gets ignored. It’s boring. It has poor understanding. We want to be up higher. As high as possible, or as low as possible. Just not the middle.

SCREEN 13

Who remembers Altavista? What happened to them? Google happened to them. Altavista and all the other search engines of the time were a complicated mess of text, links, buttons, advertising and general information overload. Their job was to provide search results, and they did, but it was such a mess – poor communication. Google came along and pretty much just had the search box in the middle of the page and that was it (or at least that is all you saw) – simple design giving the user what they want – that is User Language. Altavista is now dead and Google own the world. They could have used the bomb and nuked Altavista, but they went the other end of the scale (thankfully). If you look at the original Google page now you will find it a bit ugly, but that is only because it is no longer real to us. Back then it was a breath of fresh air.

SCREEN 14

I remember when Apple where about to go the way of the Dodo. So what happened? Design happened.

SCREEN 15

The iBook and iMac were release around 1998 both designed by Jonathan Ive who later went on to design the iPod and iPhone – goodbye Nokia, Blackberry and Sony Eriksson. If Google own the world, then Apple now own your soul. Design did this – maybe not all of it, but without the right communication at the right time, things would have been very different.

SCREEN 16

Great design, powerful communication, can and does change the world.

So you see, a company has to be good at communicating. Its products have to talk to the user in a universally understood language that is made up of words, layout, graphic design, pictures, icons, movement… anything and everything that can convey the message.

Anything can communicate well, even a table with hundreds of rows. Done right it can be a beautiful thing to behold. Done right, it can make the job of a user much easier, faster and more enjoyable.

This is the job of the Designer.

SCREEN 17

Design + Development = Love

Let me be very clear and point out that just because you are a developer, it does not mean that you are no good at design, nor does it mean that you should ignore design. We are all designers. Design starts at the very first second that an idea for a product is formed. It then travels that long road from concept to development, from development to testing and testing to final, valuable product. Design is there the whole way looking at how to communicate in the best possible way to the user.

As the design department, we are tasked with making sure the language is right, and we focus on the front end, but to really get it right on the front end, we need to reach right back and be involved in the process from concept to user. As you can see, the Designer 2.5 is more a product designer than a graphic designer. The developers need to be on the same page. Developers need to work with designers and vise-versa so that together we create that elegant solution that talks the way our users want it to talk – the User Language.

Can you guess what the Developer + Designer solution is? It is, as always, communication. In this case the communication is between Data and View. Here we need to draw the line so that the two areas are separated. Here we need to talk a language such as JSON or some other object that we both understand. This way we can populate templates, and get a handle on the HTML and CSS. Gone are the dark days of hard coded HTML and CSS – Long gone!

Screen 18

Together we are more than the sum of our parts. Together magic happens.

00011100 01000100 01100101 01110110 01100101 01101100 01101111 01110000 01100101 01110010 01110011 00100000 01100001 01110010 01100101 00100000 01110100 01101000 01100101 00100000 01100011 01101100 01100101 01110110 01100101 01110010 00100000 01110000 01100101 01101111 01110000 01101100 01100101 00100000 01110111 01101000 01101111 00100000 01110111 01110010 01101001 01110100 01100101 00100000 01110100 01101000 01100101 00100000 01100011 01101111 01101101 01110000 01110101 01110100 01100101 01110010 00100000 01100011 01101111 01100100 01100101 00100000 01110010 01100101 01110001 01110101 01101001 01110010 01100101 01100100 00100000 01110100 01101111 00100000 01110000 01110010 01101111 01100100 01110101 01100011 01100101 00100000 01100001 01101110 00100000 01100001 01110000 01110000 01101100 01101001 01100011 01100001 01110100 01101001 01101111 01101110 00101110 00011101

Did you understand the above? Binary, ones and zeroes, the language of computers. Binary is perfectly logical and yet very few can read it. For this reason a computer translates it into letters, numbers and punctuation for our convenience.

This is what it says:  “Developers are the clever people who write the computer code required to produce an application.”

The point of the above is to show that the binary which is in logical English, still needs translating to be of any use to a developer. In fact there are many levels of translation that go on between the developer and the computer, all done so that the computer can easily communicate with the developer and visa-versa. The computer and the developer talk the Developer Language.

A developer is a human being just like you and me, and so it is not unreasonable to assume that the developer can translate the Developer Language into something the end user of the application is going to understand.  What the end user understands is the User Language.

This can work, but it is not the speciality of the developer. In general, and even with the best intentions, developers speak a broken form of User Language using best guesses and logical assumptions. They specialise in the logical thinking of computers. Users, although logical and often clever people, do not speak the Developer Language and developers are not fluent in the User Language. This can and often does lead the experience of the end user to be jarring, awkward and sometimes even painful. To put it simply, the user experience suffers due to poor communication.

The User Language in this case is meant to convey the purpose, functions and journeys of the application. As you can imagine, it is very important to get this right. The application was after all produced for use by an end user. For this reason specialists are used to translate the application into the User Language. These specialists are the designers. The designer’s job is to be fluent in the User Language. The reason we need specialists is because unlike the Development Language which changes little, the User Language is a strange and wonderful thing, not just made up of words, but also colour, emotion, expectation, sounds, animation, sensation, consideration, time, space and more. It is a living, evolving language influenced by trends, culture, technology, demographics and endless other factors.

As a manager of people (UX designers and front end developers in my case), where should I sit?

I am being literal here. Where should my desk be? Should I sit together with the other managers and heads of, or should I sit with the team?

I know this sounds petty but it is important.

This question was raised the other day and of course this other manager did not think that I should be sitting with the team. She is one of those managers that thinks that they are above mortal worker drones and should be aloof to the lower levels of creativity (you can probably guess that this attitude annoys me).

Of course it can be useful to sit as a group of managers. This is great of high level planning and epic thinking, but to be honest, that stuff does not take too long and most time is spent putting them into effect. This all happens “lower down the food chain” where the creatives and builders get to work making the dream come true.

This is where a manager should be seated. Not so that he or she can meddle and slow things down, but so that the manager can listen and be a part of the process. The manager can  react to situations instantly, and work to clear blockages as and when they happen. In this way the manager has first hand knowledge of the issues and does not need to have it explained to them like a six year old.

If I sound frustrated… I am. I am so sick and tired of the bullshit attitude you get in the workplace from some people. The action is all happening on the floor and the manager is just there to clear the way. Plumbers! We clear blockages for the builders. We do dreamy stuff, but we also get our hands dirty and if you don’t, then you ain’t doing it right.

Anyway… In an agile and lean department, I vote for siting with the team and being a part of the process.

What do you think?