It's been a bit since I did a "weekly wins" post, mostly because of…lassitude…but with the convenient excuse that we've been finishing the house project and moving and setting up and shepherding the girl through the last bits of high school. So some wins have occurred since the last post, the highest of which have been

• High school is done, with great results. Good grades, an IB diploma, grandparents visiting, relief and happiness and the bittersweet knowledge that for some friendships this might be the last hurrah all in one.
• We're in the house and it is great.
• We got our full security deposit back with no argument, probably because we cleaned the hell out of the old place. And because the owners are nice. And because since they plan to move in the management company was losing the business anyway and it
• I have an employee that has gotten some negative feedback; the core of it is old complaints, transmitted up the chain of command and lingering. People not working directly with the employee have formed persistent opinions that aren't accurate. How to extinguish the senior management echo of a problem that's been dealt with? Generate some data – survey the people the employee actually works with to monitor whether or not the positive behaviors in question are witnessed or not. Happily, the employee is taking it seriously, the team members are participating and helpful, and the numbers look good.

Beta is not a release type. Thinking of beta as a release type, essentially a quality level, leads teams to take something not ready for prime time, ship it to everyone, and call it "beta" to excuse its deficiencies. If you are making excuses for the deficiencies of your product you are probably doing it wrong, and it certainly doesn't feel good to do so.

Beta is a testing period. The purpose of beta testing is to take a product that you suspect might be ready for release and expose it to real users that will break it in ways you didn't think to test for. That implies a few things:

• These users are testing the product, so you have things you would like them to do to make sure they are exercising the product fully. Therefore you have a testing plan.
• You want these users to be active in testing the product, so you have selected them and are actively managing their activity and feedback. Therefore this is not a passive exercise.
• Since you are actively testing the product, you are able to score and count the issues your testers find. The product can prove whether or not it is ready for general release. Therefore you have release criteria. and if you are doing it right you have one or more dates on which you will examine these criteria to determine if the product is ready for release.

In short, since beta is testing, you have a plan, participants, success criteria, and a decision point. If not, you're just trying to hide the fact that you don't care about quality as much as your users will.

At seventeen I joined the staff of a Boy Scout camp, and as an activity area leader I had a role to play in leadership, instruction, and the interactive programming that occurred each week. Each day had something special happening that made the schedule differ from one day to the next, making preparation, instruction, and even rest difficult. With scouts in camp for just a week at a time the strategy to engage them was clearly to make sure there was always a competition, series of skits, cookout, campfire show, ceremony, or recreational extremity (optional, happily: run off the end of the high pier! race to the far rock and back in an overloaded canoe! swim two miles in frigid water!) to draw attention and raise the available hype.

No one day was "normal." There was no opportunity to settle into a routine, so there was lots of opportunity for scouts, generally between 11 and 16 years of age, to wind up in the wrong place, unsure of where they were supposed to be and how that matched up with what they wanted to be doing, swimming in options and unable to settle into a helpful routine.

It seems the same is true for knowledge workers – above a certain flavor of entry-level position, it's difficult to settle into a daily or weekly routine that would foster comfort in one's competence. It only gets worse as you enter into management or become a senior leader; you are constantly adapting, adjusting, re-focusing, trying and abandoning directions.

I've learned not to lament the lack of routine. This is the job. But I do try to create it for the people I support who need it.

For me the centerpiece of a design exercise is seeking knowledge and adapting your design ideas to that knowledge. You create and adapt and discard ideas readily and easily if they don't fit the emerging situation. So it is essential to ask questions during the exercise to understand as much as you possibly can about the people, environment, stakeholders, goals, and constraints so that you can demonstrate this process.

You don't want the entire exercise to be taken up with this "research" activity – you do need to design something. So consider offering a very rough concept and then asking questions that will lead you either deeper into or away from that concept.

Example – imagine Home Depot had a magical way of printing and delivering orange aprons to new employees, and employee apron customization/self-expression is culturally important. What ideas does this spark? What do you want to know to confirm or discard some of these ideas?

My thoughts immediately go to a part of the new employee offer process that leads people to a website where they can customize an apron at their leisure. But these are hourly employees – the store manager is not going to want ANY work activity to be done outside of the store or in off hours. So the kernel of that idea needs to come in-store. Come to find out that they'd also like to offer this capability to existing employees. What is the technical environment in-store? How much time is the store manager willing to have an employee spend on this while on the clock? What are the required elements of apron customization and what are the optional ones? Etc. Understanding these you can sketch out a process that quickly gets the basics taken care of (perhaps in ONE or ZERO steps) and offers any options easily and quickly.

In a design exercise you'd do this all narratively – talk about the core idea, check it against their answers to your questions, change the core idea, sketch a little, ask more questions, adapt to the answers, etc.

My current employer is much like others in that it has a product management process, an engineering process, a design process, a customer onboarding process, a customer support process, etc.

What do you notice? That's right – each discipline group has a separate process. But what is it we are trying to ship?

If you turn on a machine, and hammers come out, it's a machine designed to make hammers.

Geoffrey Canada, Harlem Children's Zone (paraphrased from memory)

We're trying to ship a problem-solving, efficient, coherent, usable, pleasant, and effective piece of software. So our process, the design of our organization, needs to be arranged such that this is what the machine produces. We're not trying to ship a little bit of engineering, a little bit of design, a little bit of support, and a little bit of product management all shaken up in a bag.

So I don't offer a UX process. I talk about what the product development team needs to do informationally to get from the customer need to the satisfaction of that need. You've heard this before from me:

• Benefit: What benefit do our customers need? What problem are we solving?
• Concept: What concepts can we come up with to deliver that benefit? Which concept should we deliver? How should it work?
• Detail: How should it work specifically? As we work on this are we maintaining or improving usability, intelligibility, functionality, appeal?
• In Use: Are users successful in using it? How might we help them be more successful?

You'll note that "In Use" folds right back into "Benefit" and the cycle continues.

The specifics of each informational phase might be organization-specific, but you'll need to harness all of the faculties of the product development organization, including (but not limited to) product management, design, engineering, customers, and users to do a good job in each phase. So this should be a single, integrated process.