“Having periods like that when designers can have the freedom to explore and dream up kind-of-out-there solutions is essential for good design ideas to flourish. If you are always executing on a week-by-week roadmap and running the product development process like a bootcamp, it’s likely you will get some optimization wins, but full-blown new concepts are not usually born from those environments. There needs to be time for both an execute-and-optimize strategy in design, as well as room and space for more creative, bigger-picture solutions”
– Julie Zhuo, Go Big by Going Home
“Recently, when working with a development team that didn’t have well-defined user stories that would allow them to define priorities or the scope of each iteration of the project, I volunteered to write the user stories myself. Having a clear vision and requirements are essential prerequisites to doing effective UX design, especially when working on a tight schedule. Whenever these are lacking on a project, I do whatever I can to bring clarity, even if it means that I need to take a greater role in requirements definition than a UX professional typically would.”
One thing I really like about working at Opower is that I work very closely with the Director of Product and the Product Manager for my scrum team. I get to take an early and active role in requirements definition, which means I gain clarity on the primary UX concerns and am better prepared to advocate for those concerns and make recommendations to my engineering team during the development cycle. It’s a much better position to be in than doing sprint-ahead design work.
However, I will admit that my design work is six months out on our roadmap, and that other designers on my team don’t have the luxury of time. That said, UX should still be included as early as possible during requirements definition, even on a condensed timeline.
“If you’re building a product for customers (not just for yourself), you’ve got to test your assumptions early on with your potential users.”
Test Your Assumptions Before Implementing Them: Introducing Enroll
(As a side note, I’d ignore the product pitch…I think whatever considered method you use to test assumptions is fine, as long as you’re doing just that.)
Marty Cagan of the Silicon Valley Product Group (SVPG) wrote a letter to the design community discussing some keys issues concerning company culture and the design process. It’s worth your time to read it.
One piece of this article that I struck a cord with me is this:
Titles – usually one of the first actions a company takes after I engage with them is to start to staff a UX capability. So the execs start searching but they quickly get confused with the potpourri of titles. Honestly it just makes the UX community look like it doesn’t have its act together. From my perspective, we need to pick our battles, and this isn’t one of them. I’ve long ago adopted Alan Cooper’s titles of “Interaction Designer,” “Visual Designer,” and “User Researcher.” I occasionally use the title “Product Designer” for those few that really can represent the holistic design of the product – including interaction design, visual design and sometimes product management as well. Most of the confusion is with the various predecessors and derivations of interaction designer, including old titles like “information architect,” “human factors engineer,” “UX designer,” “interface designer,” “UI designer,” “user interface architect,” and “user interface analyst.” Same problem with “usability engineer,” “usability researcher,” or “usability designer” when talking about user researchers. I am glad to see our industry finally standardizing on “User Experience” for the design organization as a whole. If you’ve got one of these old titles and you want me to help you get a job, you’ll want to use switch to the standard title. Again, I didn’t pick any of these names, and you could split hairs on any of them, but let’s please not waste our energies there.
That’s the point of my project, “FortéFocus — your career guide to web design.” The web design community would benefit greatly from having a common resource that articulates web design roles and facilitates a common vocabulary for talking about the responsibilities of different roles in various production environments.
Cagan asserts that “User Experience” has been standardized for the design organization as a whole. I think that’s fantastic. Jesse James Garrett probably helped this standardization along.
Jesse James Garrett…made a pronouncement in his closing plenary [at the 2009 IA Summit] that “there are no Information Architects” and “there are no Interaction Designers” … “there are only User Experience Designers.” [Andrew Hinton]
He was being provocative, for sure. His point wasn’t that there are literally “no information architects,” or “no interaction designers;” the point he was trying to make is that each role in the design process is responsible for the user experience, for ensuring the quality and emotional connection of the user with the product being designed. It doesn’t matter whether each role (e.g. interaction designer, visual designer, information architect, etc.) is taken on by one person, or whether roles are distributed across an organization, but that the user experience is taken in consideration during each phase of the design process (e.g. interaction design, visual design, information architecture, etc.).
Probably one of the best ways to take UX in consideration and foster a company culture focused quality UX design is to educate designers about how each design role is responsible for different aspects of the user experience. In turn, designers will be better prepared to articulate to management and execs the importance of each role, and how different UX touchstones can affect the level of success of a product design.