Reasons your next sprint, product, or project might fail


Good design happens at the intersection of discovering real user needs/wants and business goals that are ACTIONABLE (by design and engineering). Yes, there's a little magic/instinct that creeps into good design too, but you can get far without a lot of this magic. It's really more about nailing the problem set, and having really clear goals. But what does that mean?
 
When I am talking with a prospect about a new project, I ask them tell me their business goals for the project/app/product. More often than not, I get a reply like this: 

"an elegant user interface"...
"easy to use"
"sexy"
"supports our data infrastructure"
"like Apple/Iphone"
"easy for engineering to build"
"a new dashboard/visualization"

This usually requires a follow-up conversation, as none of these are really business objectives at all.

They are design objectives...the desired end state of the user interface. And guess what?

They're ones that almost EVERYONE wants for their application. It's almost like saying, "we want funding for our project so we can move it forward."

#metoo !

Most of you on this list are stakeholders; PMs, execs/founders, analytics leaders, engineering leaders, and data scientists. Whether it's your role or not, demand or help create clear, design-actionable goals for the project. Without them, you're simply at higher risk to fail because ultimately, by the end, your customers, users and superiors are definitely going to be passing judgement in retrospect. Why not establish the means for "passing judgement" at the beginning and share it with the team?

Here are some other warning flags to keep in mind when creating or evaluating your project's goals: 

  • Engineering implementation requirements masquerading as business goals ("The app will use API xyz v2.0.1")
  • UI implementation detail masquerading as business goals ("will have a button that allows XYZ filtering and mapping") 
  • Little to no discussion of the goals prior to execution work commencing (whether it be engineering, data science, design, etc.)
  • Lack of a UX person or knowledgeable facilitator who can facilitate the maturation of the goals from vague-->design actionable.  (No offense to resident UX folks, but as a general rule, I find that internal resources aren't usually going to push as hard to get the goals stated clearly. Why? They usually feel like they have less skin in the game.)
  • Because we use "agile," it's less important to establish design-actionable objectives

You can always adjust the objectives as you move forward and learn, but when you get the core ideas defined up front, EVERYBODY involved wins and EVERYBODY can usually come together on course corrections.

And one final note: you can still have goals, even with projects such as machine learning where you may not know ahead of time what the outcome is. A business goal can still be stated for this, e.g. "Perform a minimum-effort lab-style experiment to determine a set of future business problems/opportunities [along the lines of X, Y, and Z] that may be possible to satisfy using [data set x]." In this case, our outcome is not a solution, but a set of possible future problems. The point is, we tried to make it CLEAR and actionable to the stakeholders, and the team, from the start.