A project or idea can come in from any direction. Some projects come in and are very formal, with multiple people having contributed to the needs assessment, specific feature requests. But many projects also come from a general idea (“I wish this existed”) and that can include a very loose idea of what might be nice to have, and any level of understanding of what is needed to achieve a goal.

• https://jenson.org/paradox/
• https://www.youtube.com/watch?v=1fZTOjd_bOQ
• jenson.org/games/

From the perspective of the User Experience Designer, a good idea is to always have in mind that there are parts of a project idea that are NOT thought through. Taking an idea from inception and thinking it through is a difficult challenge. Most people in the world and the majority of ideas are not fully thought through. So it's an exception and not a rule that a project that is handed to you to look at will have been given a thorough examination. So plan on that being your job. In giving something a thorough evaluation and considering the activities the interoperability, the consequences, you will find that you can save so much development time and even save people from bad or unnecessary ideas.

This is obvious yes but when assisting with a project, look at the boundaries of the project. And look at it from a strong desire to complete the project, whether one-and-done or as well-defined phases. Constraints are a good thing. If you had unlimited time, unlimited features, whatever you attempt to make will never actually get done and will probably be too much for anyone one person to use. Look at the project and be asking a few of the following questions. …

• “Is this realistically something people are able and will want to use?”
• “Can this be smaller?”
• “Does this need to be bigger?”
• “Is this necessary and will it continue to be necessary in the future?”
• “What is the pay off, the return on investment of time and energy?”
• “What are the consequences?”
• “Is maintenance going to be feasible, by you or by others?”
• “How can you maintain the energy, and clarity when in the weeds of the project, not only of yourself but others in the team?
• “Can this complex beast of an application that's developed over many months or even years and retain momentum where people are able to continue doing their best?”
• “What happens if the team loses members, or gains them, or an entire team is upended or replaced?”
• “What happens if the project goes on hold and needs to be picked up later after all momentum has dissipated?”
• “Will you have a means to providing information to help them do their job and to not lose all the effort up to this point?”

While all of these may not not necessarily be questions for your role, there is much here that can and perhaps should dictate how you will contribute and provide resources for the project. Conversations, spoken words are here and gone in an instant. Some things are taken with you as memories, many things will disappear, become cloudy or even distorted. And anyone not part of any given conversation will not have the same information to work from.

Inspiration and discussion are fleeting moments. Things must be written down. Because that same idea or concept might never return or return only when it's too late. So the records will be essential. And those records can be communicated. So you'll find yourself in a conversation about something that could be created. The idea for something. And this can come at you unexpected. You get called into an office and suddenly you are listening to an idea that is now going to be a major part of your life for the next 12 months. Not only does this happen, it happens all the time. We don't always know how important details are, how critical or necessary specific requests might be. Emphasis isn't always as clear on the receiving end as it is on the giving end. So that means you must structure how you record information, and ensure that you are picking up on the emphasis, the necessary things versus the 'nice-to-haves' And then you can evalute all of it within a framework of time, capability, money etc as to whether these thinngs can be done or how they will be done. And that includes compromises.

In AGILE there's the concept of user stories. These are features that are dictated in a type of dialog. “I must be able to do X and the expectation is Y” These things are very small pieces of a larger project. And on their own, it's not always clear what it even means. But when you break it down, software is a series of tasks, manual and automated and they are based on a user performing them and getting expected or desired results. And you take these into account and help form the software and how the user performs tasks, how the interface is laid out for these actions to be taken.

These user stories, boiled down into tasks represent very granular record keeping. Not only do you have the task at hand, it's information as to what the task actually is, in some level of context and the expected results. To contrast that, what if the instruction to the developer was just “Add an 'Load' button to the screen.” This might make sense or it might not. And if you think of a developer, not privy to a conversation, or a new developer, or a developer returning to somethjing after 8 months of hiatus, a User Story goes from a pretentious deliberately UX vocabulary term to an useful and even essential component of a project plan.

People with great ideas, and those who can help analyize and formulate ideas aren't expected to have beautiful sketching skills, or be familiar with interface elements or screen layout. So it's expected that they will provide their best sketch to help show how something looks or how it would work. But from here rudimentary drawings need to be fleshed out. This will help the idea be formed into a framework, code or design utilizing standards and be shown closer to a potential final form. User Experience Design is what this is. Take a very bad sketch and make it look like it may look in final form. Sometimes simulating it completely in order for others to share.

If drawings are not going to be seen, they aren't useful. Drawings, especially ones of higher fidelity are supposed to be used to set expectations and to provide a goal or drive to the build process. Then in the end, the idea is that the drawings that people saw, set expectations and those expectations are met in the final product. And drawings can be modified over time as people see what will change. The beauty of software is that ideas and concepts and expectations can evolve through all those conversations. The UX designer should be in the middle of that, whether or not s/he feels they are getting enough credit for it.

Some projects *seem* like no-brainers. So why not just spit out a few sentences and send a developer to disappear for a month and come back with an amazing finished project that everyone will love? The interesting thing is partially a human desire to want to believe that they can go into a cave and come out with something amazing and impress the world.

And I will not only agree that it's surprising and impressive it's that I've also had that same desire. And there are plenty of examples of this as a human story. But as great as that story is. It is more of a story than reality for most people. Not only that but even if a craftsman is capable of disappearing and coming back with something impressive, the world can only work when a process is more transparent and more fair.

Fairness and transparency and taking responsibility means that people have an idea of what's going on. Teammates, supervisors, even customers. Because this developer is being paid, because the thing being built is going to be used by people who are not the developer, these things are important. And because teams are teams to work TOGETHER. And when one team member is away in a secret cave, this bumps into more important aspects of human nature, which is The innate desire for humans to work as a team, to participate, to have trust and to contribute their talents, feel valued and be able to contribute.

Because many people on a project cannot read the abstract languages of code, nor is it in the best interest of time to teach non-coder members of a project what every given line of abstration means, instead a process of development of implementing features swiftly with the ability to show results is where you want to be. So what not to do is to make assumptions things are being done and allow a developer more time than reasonable for any given task. And it's the responsibility to the project to ensure that a developer is given specific, understandable tasks that they are capable of completing and showing results back to the team in a timely manner. As timely as a few hours, or a couple days.

The team's layout has a non-trivial impact on the energy and delivery of the work. In the UX Designer's role, you may find that the idea of teamwork really only flows in one direction, away from you. We all love the idea that being on a team will appear as a significant boost in productivity, enjoyment and problem solving that can't manifest with only an individual. We hope we can wake up motivated to start working with partners, generating innovation and originality and seeing the time fly by so much as you had such a great time in the zone you don't want to leave it.

Hate to say it, but that's the least of the categories of team dynamic that I have experienced.

This is not a statement in order to preserve the jobs of the lowly starving UX developer. Or to inflate egos or pretend that the savior of all projects is the UX designer. It's a statement that is meant to remind people that a project no matter how small deserves the care to ensure success and to safeguard the process. Drawings help do this. Just like a list of requirements does. I don't have to use too many words to keep hammering this home I think, but consider the very real scenarios.

• Nobody was given enough detail as to what to expect so their brain filled in their expectations
• A developer is human, imperfect, not infallible. They cannoy retain and recall every aspect and are solving numerous problems of abstraction and nuance.
• A developer can get sick and quit a project and that project STILL needs to get done
• A developer deserves to be set up for success.
• A business analyst deserves to have their requirements adhered to so they are successful in communicating.
• A project shouldn't take longer than needed because things were misunderstood consistently.
• A project that goes awry requires at the very least to be a learning experience, but not every mistake needs to be made for learning to take place.

Get a drawing before you develop. Drawings don't have to be amazing. They should be competent and they should be recorded. They aren't a napkin that you throw a way. They are part of a project record. A list of requirements isn't something you shout into a wall or up to the stars. They are on paper, they are part of the record, the goals and expectations.

No matter how formal a project starts off, there's always the moments where people can stray. “You know it's just different text for an error message, just change it, we don't need a new UI screen.”

These are words of regret. And whereas they may be true. They also may equally be false. And if something is such a quick and easy change, why is it so difficult to get updated drawings? It's not only about ease. It's about accountability and again teamwork. And when people think they have it covered, there's no bottom to that kind of thinking. It will lead to more and more details that will be overlooked, assumed and formalities ignored. Formalities shouldn't be viewed with disdain, they should be viewed with pride in fact. Because discipline and adherence to a system is really the only way to properly evaluate yourself and the quality of the system or process after the fact.

Stick with the discipline and take pride in it. You won't really know what it does for everyone but it's important and is part of being a team.

people thrive on communication. And not in a campy soap opera kind of way. But because your brain activates in new ways when you communicate in different ways. That's why you get fresh ideas through the act of speaking to your colleague. Where you can sometimes answer your own question because you spoke the question you know what to do before needing an answer. You figure out what to do, or how to find something WHILE in the process of writing that email.

Meetings can be dull, they drag on, they can have characters you don't particularly like. But they also can be THE source of understanding, concensus and compromise. And some person can get wildly different things out of the same meeting or activity than another person. One person's boring meeting is another person's first time they figured out how to explain something. It could also be a second, third or even last chance to catch something that later looks glaringly obvious but didn't bubble up to the surface until subsequence discussions.

People are communicators. Talk to them, talk to everyone. Be a leader in that respect. Assume that people around you are in need of communication unless you are certain as to otherwise. Show respect for them by inquiring on things and getting their expertise and acknowledge that it was better they were there that day than not.

Many personal projects don't get done because people don't put enough constraints on them. Constraints are good even when they first seem to be limiting things or causing a less-than-optimal situation, when it comes to User Interaction. Fact is every project always has constraints and getting creative within those constraints or working through and within standards is not a bad thing. So embrace the constraints and cooperate and try and show your talents within those. Part of the conversations you need to be having is acknowledging constraints and limits and communicating your choices and behaviors because of them, or in some cases, seeking out help to lift some of them, or help others work through their own limits, challenges or thinking too much inside constraints that aren't actually there.

You don't have as many people as you want at your disposal. People don't do things for free too often. Unless it's a novel experience. So you will be able to figure out what you can afford, but get your work in front of users and try to make the experience inform how you build something. Formalize the process and do it all truthfully. Don't create busy work, because you can go through formalities and it not inform anything. It's up to the User Experience people to make the user research meaningful. Otherwise it will just be empty and an expensive motion exercise.