• http://twitter.com/Braindonut Alan Dennis

    Very good post. I would actually argue that if you don’t immerse yourself in these things and come to a thorough understanding of them (like you mention, understanding the WHY, not the WHAT), then you haven’t yet become a member of the development team. And unless you are viewed as a member of the team, living the struggles with everyone else, then there’s any number of problems you will constantly have to confront which you would be unequipped to solve.nnIMO, UX/Design can not be an entity which exists separately from the development team. nnAlso, your focus on the WHY rather than just understanding the WHAT is a great point that’s often easy to forget. If you know the “why” behind a process, tool, etc, then you can have gaps in your understanding of the what/how and still be effective. “Why” trumps everything. The example of the cargo cults comes to mind as a good illustration of how skipping the why can have a profoundly negative impact on your effectiveness. :) I personally believe this is a philosophy that has served me well in every facet of life, not just working on software teams.

    • http://www.elisabethhubert.com/ Lis Hubert

      Thanks Alan! Yes the why is the most important thing and always hard to remember, however, now to us, the most obvious thing to question. Thanks for your insightful points!

  • http://twitter.com/designoutloud Phillip Hunter

    This is one of those posts that I appreciate, but can hardly believe is needed. I’ve long taken SDLC steps and functions into account, to the point of meeting with dev and test teams during design. I am surprised that enough designers don’t that we need this helpful post to enlighten them.nnI’m glad you also mentioned the need to use the knowledge to be adaptable to what development teams need. Many designers are confronted with requests for contribution to projects in process and can respond with nothing better than quoting the standard design process. That doesn’t really fly.

    • http://www.elisabethhubert.com/ Lis Hubert

      Yes, it seems odd at first that designers don’t always see the connection with what they do and how that fits in to the greater process of building software. I’m wondering if there is also a lack of this knowledge in the schools that designers are learning at. More fuel to add to the fire :-). Thanks for reading Phillip!

  • Pingback: UX… It’s Time to Learn Software Development | Agile Development

  • http://about.me/siriomi Binaebi

    Thanks for writing this! As a UXer who got her undergrad degree in computer engineering focusing on software, this is refreshing to hear. I hate it when I hear UX designers talk about programmers like they’re ruining everything.nnProgrammers aren’t ruining everything, they’re making everything. Without their code, you don’t have much to show your client other than a bunch of plans. The programmers should be considered stakeholders just as much as the business team, design team, etc. Understanding the technical constraints earlier in the design process can only be a good thing.