UX Processes, Product Design, and Development Methodologies

One of the things I pride myself on is practicing technology and process agnosticism. However your organization works, whatever you want to build, we can work that way.

If you don’t want to read this whole narrative, jump to the list of articles on process below.

Except for one thing we hold near and dear. We always want to be sure we’re making a quality product. By quality, we mean things along the lines of the formal business definitions. ISO 8402–1986 has a good one:

“the totality of features and characteristics of a product or service that bears its ability to satisfy stated or implied needs.”

Satisfying the needs of the organization and the end user is what we’re all about, but is far too often set aside in the name of speed, ease of implementation, or is not even considered due to fragmented decision making.

We solve this by injecting a methodological overlay into your process, and that’s what I’ll name GSDR:

Getting Stuff Done Right

GSDR means:

  • Listing all the stuff on the project, whenever it comes up. I use stuff deliberately. Not just features on the traditional story backlog, but everything operationally required to make the team get their work done, and get the product out the door.

  • Making no assumptions, so defining every end user feature, and clearly understanding and logging the dependencies to make sure everything is built in the right order so it all works together.

  • Defining what each item is. Never make assumptions and rely on jargon, but explicitly state everything.

  • Agreeing on success criteria for all the stuff. Never make assumptions that the definition of the problem is enough, but make sure everyone can understand when to declare something is done.

The value is in getting the right answer to the end user faster. This results in:

  • Less rework, so reduced effort and cost

  • Fewer iterations, so less time, to get to the same solution

  • More satisfied end users, increasing tolerance for early phase products

GSDR helps your team focus on the existing—but often overlooked—bits of existing methods, and goals. GSDR assures the viability of your MVP. GSDR makes sure you satisfy the customer through early and continuous delivery of valuable software.

GSDR creates a definition of working software so you can declare a story complete and move to the next one/

GSDR focuses on assuring you meet the true goals of your project, and fulfill the promise of your process, methodology, or technology by making sure you are doing the right things the right way.

Why Do We Need More Process?

GSDR isn’t actually more process. It’s just an organizing principle to remind you of what the true goals always were.

For any process your organization implements, teams will tend to chase metrics that prove their value to the organization. GSDR helps create measurable project goals, so everyone works together.

The result is a more efficient project, saving the organization time and money. The project avoids rework when the wrong thing is built, increases the total speed by reducing the number of releases to a more useful version, and improves customer satisfaction—for improved revenue, reduced customer care costs—by releasing better products sooner.

Tactics for Getting Stuff Done Right

This isn’t just a general appeal to “do things better.” We have good tactics that have long been applied by individual teams, for other bits of processes, that can all be used to pursue the goal of getting your project done right the first time.

  • Plan by not setting requirements, but goals and measurable objectives. OKRs are one way, but any number of others will do.

  • Get everyone’s input. Don’t just listen to the loudest executive, but use workshopping methods to get real info from the largest practical team.

  • Develop concepts, and review with the team to assure they meet the needs.

  • Don’t start solutions with UI, but with understanding and defining the process.

  • Validate your concepts with real live end users, using valid methods. No surveys, no demos, no focus groups. Usability methods.

  • Be open to new knowledge and ideas, whether the changing technology landscape, or things you never knew users did.

  • Don’t assume you know all there is to know, or can force users down a single path. Plan for the unknown, instead of for the happy path plus errors.

  • Create a plan, and write it down. Document the design. Explicitly approve the final plan, with signoff by the whole team.

  • Iterate, and improve the product as you build it. Revisit customers, and review what has been made to be sure it is what you want. Don’t just increment to build blindly to the plan.

  • Encourage productive criticism at every step. A demo is useless if you simply demo it without feedback, from every team member.

  • Stick to your goals, and don’t declare a feature complete or launch the product if it fails to meet the measurable objectives you set.

  • Learn from mistakes, and successes. Take the time to review what happened, discuss, and change how you will approach the next project.

Get rid of gut instinct, kick expediency and inconsistency to the curb. Start getting stuff done right, the first time.

More To Read

Many of these articles are already linked inline in the narrative above, but here they are listed in turn, with titles and explanations for completeness and clarity.

Principles and Concepts:

Methodology:

Process:

Tools:

ReportsSteven Hoober