Doing anything well is hard. Writing good code takes more time than writing bad code. If your team's management is dedicated to making a great product, then it will do the work to align team goals and schedules into a reality that creates that product. That's their job. If they fail to do this, it's your job to let them know. If the problem is learning about how to integrate the UI, interaction design, or usability into the development process, then ask your design and usability folks if you have them, or send me your questions. Good product design comes from good team process, and many teams still have not figured it out. In many cases, investing in usability engineering saves time and money, because you design things well the first time, instead of trying to patch things up release after release.

A team with good leadership directs everyone to understand how their individual contributions affect the customer. There should be a framework in place before development beginsprovided by project management, product planning, and usabilityfor what problems users have and how the features and technologies the team is building can solve those problems. Without a framework, you're guaranteed to build technologies that don't solve any problems. Once a day, you should ask yourself what problem you're solving, whose problem it is, and whether it makes sense for you to invest your time there.

If your goal is to make something useful, and you know how to make something useful, then you should schedule your project so you can make something useful. Saying, "We don't have time" to develop a critical aspect of the product is always a cop-out. It really means that your team doesn't plan well, or its goals and schedule were not designed to match. If the user's experience of your product is a low-priority item, then maybe it's time to reassess your project's priorities. If you believe something is important, you can schedule and plan for it.