Design Bird

  As a UX product designer, the Project Brief is the first major document I need to have for building a product. If there is not one already, I create one or add to one. The following are the key questions that the brief needs to answer. I don’t always use every question, but I try to fill in as much as possible. It becomes the foundation of the project and becomes the source of truth. For this reason it must be updated should truths be changed or discovered. It is shared and open to all members of the project. Project Name Project title, code name and AKAs. Dates & Milestones         Start date. Launch date. Major deadlines and targets if any. Other critical project dates. Description An overall description of the product. What problems are we solving and why? What is the goal? Key Team Members Stakeholders and project owners. Who signs off? Product Owner, Project Manager, BA, Designers, Developers, QA, others. Target Audience Who are the users? What types are there? What is the s

  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 their

  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

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