Design Bird

  I have been managing staff now on and off for nearly twenty years. Although I still have a lot to learn, obviously, or at least I hope, I have learnt a thing or two and feel that perhaps it is time to share one of the most important lessons. That lesson is to respect your staff. Work is all about people. People are… well… people. They’re human. The point here being that they are not machines and do not react well to being treated like machines. They do however react well to being treated like people. Sounds like logic? You might not be surprised to hear that I have found this to be not commonly understood or practiced. I have no respect for the computer I am writing this on. None at all. I treat it like a machine. I abuse it, hammer it, and work it relentlessly. I do however have a deep and sincere respect for the people that built this wonderful machine. You see the difference? Respect your staff. Why did you hire them to begin with? Hopefully you hired them because they know th...

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

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

Understanding A fundamental function of the UX design department is to give the end user the best possible understanding of the application and its workings. The elegant solution is sought based on the designer’s intimate knowledge of the User Language. For this reason it is important that the designer understands Understanding as a concept. So what is understanding? You know the answer, but how does that help you? What you really need to know is what creates understanding. We know what it is but how do we create it? How do we increase it and manipulate it? To do this we need to break it down into the parts that make up understanding. In the world of design we hear a lot about communication, excitement, trends etc. Yet there is a lack of knowledge as to how all these tie together to improve the end user’s understanding. They all fit into the three parts that that make up understanding. These three parts are Affinity, Reality and Communication (ARC). Together they make understanding. Th...

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

The short answer: A design is a solution to a problem. Design is about solving problems. Simple enough, but how can we use this information? How can we make this a tool to improve future designs? The problem is that now that we have defined design, we also need to define problems in order to really get to the bottom of design and really see how we can use it. Problems arise when there are two opposing wills, or forces. So, a problem is a flow, movement, or dynamic that has been stopped by an opposite. It can be visualized as a wall or a barrier. Problems are solved in one of two ways: force or by understanding. Force can be effective but it is seldom clean or even acceptable as a solution. War and fighting is a good example that may work, but we don’t want it. A hammer can crack a nut but it can also do a lot more damage besides. Understanding, on the other hand, is the clever, clean solution. With understanding we can design a solution. A nut cracker will uncover the nut without the c...

 +++ Redo from Start

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

Mexican drug cartels communicate with bullets and knives. If you try to enter their territory, they will communicate very clearly and effectively this way.

I just came across an old document I put together for UX work on a project called US Labour App. It is an example of a high level look at timing that was requested and thought it might be useful to share with others. I changed some of the names for non-disclosure reasons. Plan for US Labour App UX Design UCD Planning The planning phase is all about understanding what we have been asked to do and work out the best combination of activities that will give us the outcome we need, within the time, budgetary and resource constraints of the project. It is our job as UX design professionals to deliver the best user experience within the time and budget available. Phases These are the phases from start to delivery. UX is involved throughout the process but this plan will mostly be about the first three phases which bring us up to development. Discovery/research phase . This is where we immerse ourselves in the project to get the background we will need to make design decisions later in the pro...