I'm Dave Stadler. I help businesses build stronger design teams. Currently I work as the Director of Design with some amazing folks at Kapost.
My background is in fostering UX teams integrated within an Agile Development environment. Often design teams are mistakenly formed toward decorative ends alone. It's important to state that product design is not artwork, but rather a craft that is built first and foremost around solving problems. In today's field it is not enough to create answers with pixel perfect Photoshop or Sketch files. Design solutions need context, rationale, and results. More so, design solutions need advocates. Client presentations, check-ins, quick chats, conference calls, video hangouts, etc. are all important legs that allow design solutions to stand on their own. This structure enables an iterative and collaborative team approach that I believe is the best way to create outstanding products.
My process focuses on all aspects of problem solving UX Design. This includes researching, meeting, proposing, selling, planning, implementing, testing, and iterating. Every project needs a scope, and proper planning of sprint deliverables. Preliminary research drives content, layout, navigation, flow and addressing usability issues.
A team approach requires open and honest communication, and an ego-free understanding of our goals. The best goals solve for three main stakeholders, the customer, the business, and of course the technical constraints. Good designers are advocates for their customers. But great designers can temper customer desires with their company's business and technical goals as well. To this end, our design team must be critical of their work with unbiased eyes. A design review for a new feature requires not only being able to say what is working, but also what is not. When designs fail, this can be a great opportunity to reframe the problem we are trying to solve!
Ideas are Everywhere
New voices and approaches are always encouraged across PMs, developers, and designers alike. We've all been in meetings where it might be easy to sling some mud at an incomplete idea, but we must remember that investing the time toward a potential solution takes discipline and hard work. There is a time and place for feedback, but we must dedicate ourselves to following research and data. Often times we are not our own users, so as builders of software we have a responsibility to follow facts over opinions, even when that runs contrary to what we would believe is the best product. Critiques exist to help us find solutions, even if that means sometimes being wrong. More and more we need to be of the mind, how do I give first, so that we all rise-up together?