Action Needed

It's the end of July. We've just finished up showcase, where one of my stories got demo-ed - the first for BigDog's team in quite a while.

I'm sitting next to Devil, who is proxy for Product Actual. Devil is awesome. Today, everything went more or less to plan, so what happens next is mostly formality - but the forms must be obeyed.

Was everything accepted?

Agile requires that our team demonstrate what we've done to Product, and they get final sign off on whether or not it is done to their satisfaction. Devil nods, and I look in the queue and click the 'accept' button three times:

One.
Two.
Three.

And immediately forget about it. There's an iteration planning meeting coming up. I need to be ready. I think some of my stuff might get picked up.

I'm focused on that as I walk out, unaware of how three clicks will turn into a sh!t show.

*   *   *

From: Ahhh 

To: murph

Cc: Nugget

Subject: thanks, but please don't move the tickets to accepted

Hello!  There’s work I need to do on the tickets and having them in the showcase queue, checking them, and then moving them is my process.  I don’t think there’s any immediate hurry outside of the showcase day.  If you’re being asked to move them please let me know so I can address it with whoever is asking you.  Thanks

Brief aside, here: Ahhh refers to stories as 'tickets' and refuses to call them anything else. Whatever. Ahhh has cc'ed Nugget, who is our Scrum Master, for reasons that are clear to pretty much no one.

---

From: murph

To: Ahhh

Cc: Nugget

Subject: RE: thanks, but please don't move the tickets to accepted

What additional process is involved in accepting stories?

My understanding was that you were minding the RFD queue with regards to priority. If this has changed, that’s news to me. I moved the cards to accepted because I was sitting next to Product when they said they were accepted.

---

From: Ahhh

To: murph

Cc: Nugget

Subject: RE: thanks, but please don't move the tickets to accepted

If there’s any of the field entries out of whack/missing/etc. I get a talking to.  So, no.  Not just priority.

At this point, Nugget comes over to my desk to ask me if there is some irrevocable aspect to marking a story 'accepted.' There isn't, I say, and since Ahhh is an admin on the site, they are able to edit any aspect of a card. Nugget seems confused by why Ahhh is making a deal out of this. I share their confusion. Nugget walks off.

---

From: Nugget

To: Ahhh, murph

Subject: RE: thanks, but please don't move the tickets to accepted

I like the process of updating right away in the showcases as the Dragon team does it that way too.  I also try to update the release page shortly after (don’t always get to it) and look for Accepted before marking them off.

Are there some fields that are not updateable after the status is changed to Accepted?

---

From: Ahhh

To: Nugget, murph

Subject: RE: thanks, but please don't move the tickets to accepted

I sure can change my process to accommodate your process.  Who will be the responsible party for moving the tickets to Accepted?  Thanks

---

From: Nugget

To: Ahhh; murph

Subject: RE: thanks, but please don't move the tickets to accepted

Ok, thanks.  I think you should own all the activities with the board which includes marking as Accepted.

Translation: Nugget is washing their hands of this. 

---

From: Ahhh

To: Nugget, murph

Subject: action needed RE: thanks, but please don't move the tickets to accepted

Thanks!  murph, Do you agree? 

(Subject change and highlighted text in original)

---

From: murph

To: Ahhh, Nugget

Subject: action needed RE: thanks, but please don't move the tickets to accepted

I Do Not 8-) 

Partly because I think the point of a tool like Mixer is to share a workflow, so that tasks have more coverage and people can help each other out.

But also because I really don’t see limiting use in Mixer as solving this issue. If you’re getting grief because there are missing fields, we can add validation to the transitions to enforce those fields (and share the issue with the larger team, so that new cards are filled out correctly, rather than have the same process lead to more cards to clean up).

---

From: Nugget

To: murph, Ahhh

cc: Gumby

Subject: action needed RE: thanks, but please don't move the tickets to accepted

Copying [your boss] as well for their thoughts.  I agree the team should all move their cards through the workflow.  Am suggesting that Ahhh owns the “bookends” to that flow meaning she will get it moved through the analysis phase and get it RFD and then be the one to close it out by Accepting it.  If the Accepting can be done during the showcase, then this should work (at least for me).

If we still disagree, let’s set up some time to discuss further.

---

From: Ahhh

To: Nugget, murph

cc: Gumby

Subject: action needed RE: thanks, but please don't move the tickets to accepted

Nugget, Could you describe what moving it through the analysis phase looks like for you?  We have various UXers assigned to the analysis work on the different cards – and typically the assigned UXer is the one to present it for estimation (in pre-ipm) and for RFD.  It would be helpful to understand you thoughts in more detail.  Thanks

---

From: Gumby

To: Ahhh, Nugget, murph

cc: Gumby

Subject: action needed RE: thanks, but please don't move the tickets to accepted

First and foremost, my expectation is that the team works together. Attached are the expectations based on what is needed for the team…regardless of who is doing the work.  Ahhh is the single point of contact and we look to them for the work to be completed (like before a Pre-IPM). However, if murph is moving stories to accepted during the showcase, I would see this as a nice gesture.  

I’m not sure who is providing the “talking to” as referred to below. The bottom line is BigDog’s team is relying on us to manage the queue. If managing the queue is creating such issues that it creates strings of emails on a regular basis, then we need to rethink the process.

When I read discussions like this, I feel like a lot of energy is being focused on the Mixer board that would be more productive if focused elsewhere.  

And when I read discussions like this, I feel like hurling my laptop out of window.

Progressive Disclosure

Alright, you're gonna think I'm looking for something new to slag on - but this really happened.

And
I

get

to
b!tch

about
it.

*     *     *

Rewind to a several months back. Noddy's webform is only three months late, and it's barely a form. Scratch that - it's barely the idea of a form. Noddy's written up a story for the devs that says basically, "put some text boxes and dropdowns on a web form. Oh, and give them labels, too." No validation, no function - a dead end of a feature that mimics the same old schlock in the rest of our app.

Which is sad, because Noddy has been given a gift - and was blowing it. All the webforms in our app were built with a common engine. A common engine that was built before we thought about UX at all. As a result, all our forms are uniformly terrible. Improving one form meant doing the heavy lifting of overhauling the entire engine.

But not Noddy's form. Noddy got the greenlight to be a standalone new form. Which means Noddy is free to do all the modern UI they want.

And they're replicating the same old schlock.

Runner has noticed this and is trying to browbeat some quality into Noddy's up-till-now lame-@ss feature. Runner's been appointed the guardian of the style guide and there are so many things that need fixing in our forms - they cannot bear seeing the same crap happen all over again.

Our forms have many problems but two of the newly fixable problems are our multiple required indicators and lack of conditional display.

Our forms have two kinds of required indicators (field is required to save, field is required if you want to mark the document as 'finished'). This is bad enough, but is compounded by the fact that we don't have an indicator for fields that are required to submit the form to Nachen.

Mind you, the whole reason you fill out our forms, is to send them to Nachen. And we don't have required indicators on fields that Nachen requires.

Beyond insane.

If we just add more required indicators, we would end up with THREE different required indicators.

Which simply cannot happen. Since whatever solution we come up with could influence other forms, we call a UX huddle to agree on a first step. Runner, Noddy, myself and Ahhh end up in a room and spell out the problem.

Required to save seems like the easiest indicator to lose. It turns out only two fields of data are required to save a form. One is prefilled, and the other is just a date field.

I've seen other forms with this problem and rather than make you read little symbols on the page to see what needs to be done, they frontload some prerequisite fields and don't let you see the rest of the form until you fill them out.

So, let's put the two required to save fields on a mini form before the main form. Fill out the date field and hit "continue" and we'll show you the rest of the form. Then, once you get to the actual form, you can save at any time. *Poof* 1 less required indicator.

We come up with a conditional display of the Nachen indicators that seems good.

The team seems okay with this as a first shot, and Ahhh (true to form) wants to have a wide ranging discussion of how we will come up with a design language for validation going forward. Ahhh is just compelled to make discussions larger and less fruitful - we call a halt for now and I send out the meeting minutes.

From a possible 3 indicators, we're down to 1, with an option to turn on a second. Not bad for an hour meeting.

*     *     *

Let's skip to a few weeks later. Noddy's demoing the form with the mini form up front and Ihaq is laying in like a buzzsaw. "I've never seen that before. I'd like to have a discussion about this."

When Ihaq says things like this, you can tell they are not pleased. True, this is a new UI element, but Ihaq is the same SME who thought our previous required indicators were for Nachen fields. This is our Subject Matter Expert - who as worked here for years, misinterpreting the standard interface of our App.

There is no better proof we have a UI problem with required fields.

But back to the UI - the SMEs get to weigh in on their field of expertise, but they don't get to design the interface. That's our job. If the SMEs have a specialist objection to the workflow, like they know the user won't have the required data up front, then sure - we'll listen to them and adjust. But if they just don't like the button, tough bounce.

Post showcase, Gumby asks after the UI, "did we test this?" No, I say, this was a decision that came out of UX. I can tell Gumby is still smarting from being called out in the stakeholder meeting, but there's not much to do about it.

Later, Runner, Noddy, Gumby and Ahhh meet with the SMEs about Nachen work - and Ahhh pulls a reversal. They denying playing any part in making the mini form, despite being in our meeting and agreeing to the approach. Despite the fact that progressive disclosure was something Ahhh had suggested in prior meetings.

I'm irritated and dig up the meeting minutes that show our decision to use the form. I don't send it to Gumby, but I show Runner so they know that Ahhh is full of it.  Standing up to the SMEs can be hard, and I can see the pressure to please them - but you can't just surrender the role of UI design. SMEs inform the design, they don't draft it. Ihaq doesn't like the progressive disclosure of the mini form - because it is new. Not because it is a real problem, they just were unprepared for it.

Gumby wants us to vet the entire form in a user test - and our new guy, Dash is supposed to put that together. Heck, at some point I was going to be doing it - but Arwafn blew up and put that to rest. Dash would be great - they are a veteran user tester and completely outside of the design.

A designer should not test their own design. Bad things happen if you do.

Somehow, the test doesn't manage to happen. I'm eye-deep in the Arwafn hairball and forget we were even thinking of testing the form.

*     *     *

So, a few days ago at standup, Ahhh mentions that they are working on a user test. I'm like great! I love user tests - they are awesome. Sure, sometimes they kick your ass, but they are so worth it. Normal run of things back at CorpWorld was invites would go out to the full team to observe - so everyone can learn from the test.

A test has a primary and a second. Primary runs the show and writes up the findings, with final edit. The second is pretty much there to help with the metric ton of work that a good test requires.

A good test should look effortless to the participant, but getting credible task scenarios is not easy. Getting a working prototype to test those scenarios is pretty frickin hard. And notetaking, and analysis, and on and on....

I don't know who is leaping on all of that, but I'm glad that we'll finally get some user testing done at Nerdhaven. Whoo! Heck, if things calm down in a week or so, I might have time to help out.

The next day, I get an email from Ahhh "I can't get the form to load and I've got a user session in a few hours."

I'm headed out the door to pick up the kids (it's my early day) so after I figure out what they are asking I get QA to help Ahhh out.

User session? WTH?

But I'm out the door.

*     *     *

Day after that, Ahh is talking about the next user test they're setting up, and there's still problems with the form loading. I can't help myself, I fire up IM:  User test? Can you forward the webmeeting link? I'd love to observe? I back off a bit. Or are you recording?

Ahh takes awhile to respond. All the while I'm thinking: How is it that they are holding tests and haven't emailed the team about it. No one else on the team even knew this was happening.

This is weird. Somebody should be helping Ahhh with the test. Not only is this the first user test that Ahhh is doing for NerdHaven - this is the first user test that's been done at NerdHaven. Period.

How is this being done by one person? And our newest UXer, to boot?

Ahh responds with "I'm recording. I'll get you the link." The implication is, I'll get back to you. Now, I don't need to observe in realtime - observers don't get to ask questions normally anyway - too much pressure on the participant. But the tone was bothersome.

Ahhh was at the point of having participants in sessions and nobody had heard a thing. Asked for access, Ahhh has basically said I'll tell you when it's over.

Later that day, Dash sits back from their desk - and snorts.

"I tried to get a hold of Product and they say they are busy because - get this - they are observing Ahh's user test."

WHAT? Okay, people on your team - whose interface you are testing (Dash's prototype is also being tested) have not been allowed to observe - but Product is sitting in.

Nice.

I have a quick client call and end up debriefing with the account Rep on how it went. The Rep's like "No problem, it went fine. I was on that user study with Ahhh earlier and that was a little rough, but it all works out."

I can't help myself - "Can you send me the link to the recording?"

That's sh!tty of me, but Ahhh said they'd send the recording, and they haven't. And really, the recording is made by the rep, so I'm jumping past the middle man.

The rep - in an act of karmic payback - totally forgets to send me the link. They are good people, and I believe this is so - but it is right that I should not get this from some back ally maneuver.

I should get it from Ahhh - directly. And Ahhh is pointedly not giving me, or any other UXer access to their tests.

*   *   *

I cannot stress enough how bizarre this is. Designers can get pretty prickly about their pet designs, but any designer worth even half a hoot knows you are going to get better design with collaboration.

More to the point, any designer worth considerably less than that knows their own bias is going to hang them if they don't have regular contact with opinions outside their personal bubble.

Ahhh makes much of their history in UX. They have an MBA, they've been doing user research for almost twenty years. I have heard this ad nauseam pretty much every time our team is asked to introduce themselves to some guest. I get it, Ahhh. I do. You are not wet behind the ears when it comes to UX. So why the F*&k are you doing user research in secret?

The ENTIRE POINT of research is to share findings - and while convincing people with research is nigh impossible - it is absolutely impossible if your audience thinks your research came from some black box process.

Erika Hall gave a talk on design research that just blew my mind - not because it's some previously unthought hunk of wisdom, but because it perfectly reveals wisdom that is hiding in plain sight. Research that comes from the mountaintop in the hands of some sage is trivial to dismiss. Sages...amIright? Research that tells a story can resonate. Stories you participate in are far more compelling than stories that are told to you.

If you give a crap about research, watch Erika make it make sense - or buy her book - or both - because I'm going to get back to griping about work.

*   *   *

So...
Whisky Tango Foxtrot, right?  I do not go to the boss, because this is not a discussion that needs management. I haven't confronted Ahhh about the situation, I'm merely asked and not gotten much of a response. I've vowed to be direct about things at this job, and I'm going to do this if it burns every bridge around - because dammit, direct communication should not be a last resort.

I'm neck deep in some Arwafn stuff, when Ahhh gives her standup update as, "I have user testing session today."

What?? Still no upfront notice? Okay, we'll talk, you and I.

I call Ahhh out at standup and ask to be able to observe the test. Ahhh's on the video conference, in front of the entire team. Rather than look petty in front of all of us, they hedge, "If you want to... I guess..."

I do. And I make it known again, that I do. I corner Ahhh on IM and ask them for the web conference link, and book a room on our office to invite the entire UX team.

Ahhh becomes very prickly over IM when I mention that I'm grabbing a room.

"WHO is going to be attending?"

I am upfront to the max. I'll send you a list of the attendees and everyone in the room will understand that we are *observing* not questioning or interfering. We know the drill.

I'm starting to get the sense that Ahhh is afraid they will have some higher up observing them, and they are all kinds of on guard. Which I would understand if we were back in CorpWorld, but this is NerdHaven - we don't do that kind of bullsh!t here. I'm not ambushing you by videoconference, jeezus.

Most of our client contacts are managed by Reps, who maintain client relationships far better than anyone on our team could - so I ask who Ahhh's Rep is on the test.

"Does it matter?" is Ahhs response.

Well, yes - actually. I'd like to invite them to the room I'm booking for the other observers - in case they want to be there.
A lot of Reps do all their conferences from their desk, but some find value in being in a room of people who are also on the call. I'm amazed this has not occurred to Ahhh, but I spell this out.

They icily give me the name of their Rep and sign off.

Well...

So, now I've got a conference room with Runner, Heater, Dash, and the Rep, and we're finally going to observe the test. Irritation aside, I'm actually excited, because tests are exciting. Real users, doing stuff.

w00t!

The session starts up, and Ahhh - twenty years of UX/research etc - is H-O-R-R-I-B-L-E. I don't know any other way to say it. I mean, typically if you have a test, you have scenarios with test data that the participant uses to attempt each task. There are success criteria/ fail criteria. There's a notetaker, there's...

Ahh has nothing. They have the live system and a participant, sure, but "Hey, try to fill out this form" is not a valid set of instructions. Our users - like most users - are truly bad at making up a set of data to fill an ill defined scenario. I'd actually say our users are worse than most, because our users are highly trained, detail oriented, and used to working in incredibly complex environments.

They sweat every detail and anything out of place will have them derailed and talking about bogus data for twenty minutes. They - as a rule - do not make up data. They want to know details before they proceed.

Ahhh has started a 'test' by loading up the mini form and saying 'have at it.'

'Oh, and tell me what you think of what you're seeing....'

The participant is looking at the mini form which is asking for a specific date. They are like 'you want me to make up a date?'

Ahhh is like 'oh sure'

So the participant types in the current date and hits the button to go to the rest of the form.

Ahhh does not ask them what information they would start the task with, nor have they supplied any. They don't ask why they chose today's date, if that would be representative, or where they would get a real date if this were an actual scenario.

What Ahhh does ask about - is the mini form. 'What did you think of that - not seeing the rest of the form until after you put in the date?'

The participant is confused 'uh, it was fine.'

Ahhh asks about this a few more times, phrasing the question differently each time. I'm looking over at Dash like what the...? until I get it.

Ahhh doesn't like the mini form - and they are really hoping that the participant will find fault with it. When that doesn't happen, Ahhh gives them a few more chances, in hopes of hearing what they want to hear.

Which is RULE NUMBER ONE as to why you don't test designs you've had a hand in making if you have any way of avoiding it.

I'm shaking my head when Ahhh asks about a piece of form UI that they designed - and believe is crucial to the workflow. "What do you think of that?'

The participant is confused. They hadn't noticed Ahhh's pet piece of UI until now. 'uh, I dunno.'

Ahhh repeats the question, gets a similar response - then tells the participant what the UI element is and what it is trying to do.

At this point, I'm about to roll my eyes when I catch Dash shaking their head. This is another thing you just DO NOT DO in a user test - if you have any way at all of avoiding it. You do not tell the participant what the interface is, or what it is doing. You let them tell you what they think it is doing. This way you can learn if if it's intuitive or not. As soon as you tell them the answer, you've lost the chance of learning more about the participant's point of view.

Now, there are lots of research techniques for lots of different situations, but this is a user test. The participant's unadulterated behavior is the entire point of the exercise. They may falter, but you do not give them assistance until you've learned what their perspective was without assistance.

Ahhh wants their pet UI validated by the test, and they cannot stop themselves from interfering. They do this repeatedly until Dash and I are absolutely disgusted.

There are no success or fail criteria, no test scenario, so the participant gets to the full form and basically stops doing anything and waits for more information. Ahh pokes them a bit by asking for their thoughts about the form, what they are thinking - typical UX probing techniques. But there is no task, so this is just an airy, off the cuff discussion.

This is not a test. This is a walk in the woods.

"What do you see?"
I see trees. I like trees...

The entire session is just a colossal waste of resources and time. I've worked hard to get access to see this so I can learn more about our users - and all I've learned is that Ahhh is really, seriously bad at testing.

A lot of what Ahhh did in the session would have been fine if it was just an informative interview - "hey, tell us about this" but this was set up to be a test - more to the point - this is being *represented to the organization as a test* and it was nothing of the sort. I'm not confident that the organization is ripe to receive test findings yet, but if they were to get a report based on this load of... crap - I'm not sure what would be worse: accepting it at face value, or tearing into the method.

*   *   *

And I want to be clear - the mini form is not a design I'm terribly fond of. This is not about pride of ownership - if the participant had trouble with the mini form, I'd cheerfully bin it and move on. Never mind the fact that Ahhh had suggested progressive disclosure like the mini form to solve our validation issues to begin with - then dropped it like it was leprous as soon as Ihaq came out against it.

Ahhh's behavior has me seriously questioning Ahhh's professional integrity. For all appearances, it looks from the outside like Ahhh has kept the UX team outside of their research, while they have been - evidently - seeing what they want to see.

There is no doubt in my mind what Ahhh's conclusions will be at the end of their 'tests.' They will reject the mini-form and completely validate their pet UI element.

And that is just sad. Because that means NerdHaven's first round of user testing has been performed by someone who cannot be trusted to do user research.

And now, having discovered this problem. We are left with the problem of what we are going to do about it.

Derailment, part I

All at once, work is exhilarating and terrible.

Arwafn is rolling out to the world, and while the internal reviews are good - the only score that counts is the one you get from the end users.

The early reports are the worst. Not because they are bad, but because they usually represent incomplete opinions, initial reactions - delight in something new. They are passed along by hopeful co-workers who want to believe the same thing I do: that it has worked. That our customers are pleased with what we've done.

Somehow, I always manage to fall for this.  I supposed to be dispassionate, but after a year of working on the project, I want success. I want happy customers.

And so I flatter myself to think that this time, we did it right.

And then the second round of reviews roll in.

Second round is usually polite, deferential even. "Hey, I'm wondering about this bit here..."

By the third round, you know you have problems, and you start looking for patterns. This is not a drill. You'll need to fix this.

Bin the ego and lean into this, because it's going to hurt.

"Customer has some questions about this filter. It doesn't seem to work" 

"...numbers aren't adding up. They want to know why..."

Third, round - the co-workers have stopped being nice. They want to know what the problem is. And how those problems managed to make it through QA and beta testing.

There is no worse feeling in UX than watching a customer delight in seeing what they wanted to see - and then watch them realize their mistake.

Oh...I guess that isn't working.

*     *     *

The flaw in Arwafn that managed to make it all the way into production is the most maddening of all. Arwafn relies on customer supplied data - in the form of a data feed.

Data flows from a client's system and flows into Arwafn. Arwafn turns the tidal wave of data into an intelligible grid and allows the user to manipulate it in several ways. We've checked the design against the industry standards, we've verified that the added functionality was wanted by the customers - we've set up beta testers with their live data in Arwafn and let them play with it to get their responses.

And we've had QA try to beat it to death with everything short of a tire iron.

Arwafn came through all that. The board was green.

But we'd missed something - something that was admittedly pretty hard to quantify, but something that we could have noticed earlier.

The client data feeds are crap.

We were like engineers building a colossal aqueduct across miles of countryside and then aiming it at a dry lake.

Or, more accurately, a bog.

Some customers follow the agreed on specification for supplying the data and - for them - all is well. But for a still to be determined group of customers, they send us garbage - and for them, Arwafn is smelling pretty foul.

And it's no good pointing the finger back at our clients. We told them Arwafn was a new feature - we did not tell them it might work if your data isn't godawful.

Nor did we design the report to degrade gracefully. That principle I began learning with regards to crap browsers ages ago was noticeably absent when I baked out the stories to build this report.

It's a basic idea - and yet I'm re-learning it for the umpteenth time:

Okay, it works when A, B and C are present. What if I take away A?

Easy. It looks like it's still working - but isn't.

What if I take away B?

Same thing.

And so on. Any of those questions getting some real thought would have resulted in what NerdHaven is now rapidly deploying to the field. Switches to enable the functionality dependent on A.

Don't have A? We'll shut that off for you.
No B? We'll turn that off, too.

The rest will still work.

That's how it should have been designed from the get go, but in my naiveté thought "Of course, they'll all be sending us this information. How could they not?"

 And they're not. Or rather, I wish they just weren't - that would have been easy to spot.

When we did beta sites, no data would have resulted in obvious failures. But that didn't happen. We had data flowing into our UI, and the dependent features worked as expected.

Did we ask users to go through our report line by line to ensure accuracy?

We did not.

Did we ask our internal experts to crawl around under the hood of our beta sites?

We did not.

All of this, every new expression of the problem, slams home into whatever professional pride I'd managed to save up. Three weeks ago, Runner and I were heroes. Now, I'm being forwarded emails from our SMEs where they are describing Arwafn's failings in scathing terms. I'd have hoped I would have been included in those messages when they were sent, but I get them secondhand. After they've been routed through management.

Atlas has been unfazed by this - they point out we've had data issues in the past, and the scope of the issue is being overblown. I feel genuinely ill. Atlas and Gumby finished up my performance reviews before this all blew up. I came out really well in their eyes. I was proud.

And now this. The folks who sang my praises are now being hauled in front of the executive leadership team.

And there is something else. Something that goes beyond a customer sending us crap data.

Something I'd heard about and went after.... just way too late.

Circular Firing Squad

I'm on the phone with Data, our in-house BI expert - talking about a feature of Arwafn that utterly blew up when we met with the SMEs.

It's not going well.

I've let Data down - again. This seems to be my lot in life. I'm told to move the ball forward, with the understanding that a first attempt will not be perfect - but we will improve as we go.

This is the opposite of what Data wants from me. Data wants me to have all of my sh!t together before I ask them to do their bit.

And I understand this. But UXDirector has given me explicit instructions to not to wait until everything is perfect. UXDirector is tired of waiting for perfect - and they want movement. Now.

They are the boss. So, I do what they say - only to end up utterly letting down Data.

Data has conviction. They are principled. "We cannot fake this. We have to get it right."

And I agree with this. I just believe that we will get it right, after a few revisions. We do not know what we do not know. So we will go forward, take some beatings - and learn.

Data doesn't want to take beatings. Right now, they are dishing them out.

I've often joked that a big part of UX is taking the beatings. So I lean into it until they are done.

"Do you know this stuff? Really know it?"  They are talking about Arwafn.

I hedge a bit - which is stupid.

"I don't have it memorized, but I believe I know it."

Data can sniff out BS like a bloodhound. "Because we cannot get this wrong. This has to be right. Customers won't go through the misery of setting this up if they don't see the value."

I'm trapped between two competing design strategies. UXDirector and Data are not on the same page. And there seems to be no way to make them both happy.

Somewhere in the beating Data drops a bomb.

"The Professor is leaving."

What?

The Professor is Data's partner on a big chunk of our current project. They both share the "first, get it right" philosophy of design - and have been collaborating well.

"Yeah, their last day is a week from Friday."

I do the math. It's Wednesday, which means if the Professor gave two weeks notice, the UXDirector has known for two days and has not told anyone.

What the what?

I like the UXDirector. But if they have a major weakness, it is in their communication skills. In person, you will get all you need to know - but only if you seek them out. If you are waiting for a bulletin from them - don't hold your breath. Once, they emailed us the day before they left the office for two weeks. Nobody knew a thing about it. "Bye department, I'll be gone until..."

And now, mum on the departure of a team member.

*   *   *

Bit of background is in order here: The Professor is someone I have a good deal of professional respect for. They clearly have UX and research chops.

But here's the thing: they flat out suck at working with people like me. I've never had a meeting with the Professor where I didn't feel like I was getting lectured.

Here's what I did... and here's the background on how I approached it and here's the proper technique...and-

"I have a question"

Let's table that for now. Now you can see here that..."

"What is that pattern?"

I would push back on the term 'pattern.' This is clearly an expression of a design language. Now, as I was saying...

And so on.

Hours of this.

We used to refer to some of the meetings with the Professor as "Watch Professor Type." They'd show up with stuff they wanted to show off, and brush off anyone else's material until they'd lovingly walked through every last facet of their design. At which point, any questions or alternate designs were swatted aside until the Professor would conclude that their design had carried the day.

It's just a strawman.

Strawman. They said this so often that it became a joke with Runner, Noddy and I. We actually had a drinking game where each of us would take a drink every time the Professor said the word.

Being in the office the drinks were usually sparkling water, but it made us all smile.

And I don't think the Professor is a bad sort, they just had no idea how to collaborate. At one point I got into an email rant with them about a particular design choice they'd assumed we'd all adopt. I proposed a compromise and - they took me up on it.

The ice was broken - somewhat. And I'd hoped this would be the beginning of better things. The Professor had a good sense of humor and our meetings usually had more than a few good laughs.

So, right after Data tells me the Professor is leaving, they invite me to a technical review of the work Data and the Professor have been doing. This, I consider a win. Data would like me to be there. They would like Runner to be there as well, but not Noddy. As they put it "I don't want them to screw it up."

So, Data and I are on the same page about Noddy.  Really, how could we not be? Noddy is a total tool.

Anyway, I go into the tech review and sit back while the Professor launches into another tour of their grand vision.

I've seen this part before - and I'm wondering what the Hell the Professor is up to. A technical review is basically "I want to build this. How many technical hurdles do you see at first blush?"

A rapid description of the features would suffice. But this is the Professor: He begins with his persona research. Then his task patterning. About three more abstract visualizations later, the developers are checking their smartphone email. Then the Professor starts talking about their prototyping tool. How it works, what their initial approach was - the problems they encountered - and why the performance of the tool was currently sub-par.

If the Professor had any empathy for their audience (aside from me, all developers) they would realize that absolutely nobody gave a sh!t about what they were talking about.

Some 45 minutes into the verbal barrage, the Professor finally arrives at showing page mockups and discussing the data requirements. This - devs care about. Questions begin flying in earnest, but there are so many unknowns that the meeting ends 15 minutes later with the devs as mystified about what was required as they were when the meeting began. Eight high-priced developers burned an hour to get a UX theory lecture and walked away with very little new information.

Awesome.

And there was a niggling little detail in the presentation that I couldn't manage to forget. In the past, the Professor hasn't been shy about lacing his documents and communications with snide nicknames for people and things he has little respect for. They'd referred to the Marketing Department's branding guidelines as "the art project" and I suggested we stop calling it that - lest one of these folks get wind of it and take offense.  This was my attempt at being diplomatic.

The Professor laughed it off - like it was silly to even worry about it - and just left the term in their documents. And proceeded to forcefully use the term in our subsequent meetings. It struck me as tacky - not a huge deal, but evidence that the Professor didn't easily turn off their scorn.

This is in the back of my mind, when I see the Professor's summation of our UX team's current projects.

Next to the entry for Arwafn - under the column that indicated who was working on it - the Professor had written 'the three Amigos.'

Meaning Runner, Noddy & I. In the eyes of the Professor, we're the three Amigos.

Now, I'd seen this 'cognitive walkthrough' of the Professor's before - only this part hadn't been in the tours I'd seen.

And I wasn't supposed to be in this meeting - Data had invited me at the last minute.

Nice. Way to belittle your peers in front of the Devs.

I mean, Runner and I are making fun of the Professor on a regular basis - we're just not documenting it and showing it to folks outside our team.

Okay. I see how it is.

*   *   *

So, the Professor is quitting. Taking a job for less pay, because they want to get out. They've tried ("and tried.. and tried" they say) to win UXDirector over to their design philosophy. No traction.

Hmm... maybe it's your delivery.

And they're going to - in their words - "a rockstar shop." So be it. If they find an environment that suits them, they are better off. Frankly, I think we will be, too.

I mean, I've been in a lot of pointless meetings - but the Professor had a way of describing things that they were "going to do" - and then not do them.

This is perhaps the reason that UXDirector is not embracing their design philosophy. Because it is so slow.

*   *   *

Which still leaves the question as to why the UXDirector hadn't bothered to tell anyone that the Professor is leaving the company. Given the UXDirector's communication style - I can't say this omission carried any special significance. You don't get much from UXDirectory unless you ask for it. Nobody asked them if the Professor was leaving the company - so, they hadn't said.

*   *   *

So, it's today. I'm still smarting from the week's beatings. I've recently acquired a new set of standards for Arwafn - and I can see it will require changes to its basic function. This will go over with Data like a lead balloon.

I remember Noddy talking about this particular function and find an email from them from March. They are asking about this function based on another document. They email basically everyone on the project to say "look what I've found." Product weighs in and says "make this change." A SME weighs in and says "we must do this."

I remember talking with Noddy about it - I was trying to figure out how big a deal this would be. I had no concept of how big of an issue this was - it seemed like an edge case. I wasn't eager to make changes, but I wasn't opposed to it. And Noddy had been greenlighted by Product.

Noddy does...nothing.

A month later - I'm looking at new specs that tell me I need to make this change

Hooray. I'm looking for ways to break this to them and opt to go to another person in Data's field - Heater. Heater instantly knows what I'm looking for and starts the machinery to make the necessary changes.

Heater is thorough - so they copy the UX team - which means Data. Data is clearly irritated at this new discovery. Clearly I'm not doing my job well - otherwise I'd have known about this.

My attitude is that making fixes as we go forward was always part of the plan. UXDirector has said we'll put our code into an environment and throw actual production data against it to see where the holes are. This strikes me as a great next step.

I've mentioned this to Data and while they are clearly on board with this - test and make improvements. But this new change of mine is still heresy.

*sigh*

UX is all about taking the beatings.

Later, I'll go tell the devs that we'll have to change working code.

Noddy stops by to tell me that he knew this would be a problem, that'd he'd asked for these features a long time ago and "...nothing happened."

Gee, wonder why that was...?

*sigh*

*   *   *

It's the afternoon. I'm looking at a farewell email from the Professor in amazement.

I've seen my share of awkward goodbye messages - but the Professor's is on a whole new level.

I mean, what do you usually say in a goodbye message? "So long, it's been great. I've learned a lot. Here's my contact info. Keep in touch."

Not the Professor. Their message has something else.

It has a chart.

A timeline illustrating the projects the Professor has been involved in - what the goals were - and the (Totally awesome) success each of them ended with. There are at least three swim lanes in the data table and...

...skip it. It was ridiculous. A victory lap for someone who saw their every action as triumph. 

I'm deleting it when I remember that I have another meeting with them.

The Professor is having their last meeting about the style guide. The style guide has been a recurring lecture series where the Professor tells everyone to do what they say.

To be fair, the sessions had improved from the first few sessions - but we hadn't met in recent weeks because we were all too busy.

Now the Professor wanted to have one last session and we couldn't really find a reason to turn them down.

We started out cordial enough. The Professor asked if anyone had some items for the group and I pointed out that everyone else in the room would still be around the following week to discuss things - but if the Professor wanted to say something, they should probably say it now.

"Fair enough," says the Professor - and they proceed to walk us through "their process."

Again.

I've seen this document before. At least three times. And now four. This matters not at all to the Professor and they replay their earlier lecture as if it were hot off the press.

They detail personas and affinity diagrams. And how they "informed their early iterations" and how this led to "an integrated feature set." How meeting with users had allowed them to "move forward with confidence."

At this point, I've had it.

I interrupt. "Are you showing us these things because you think they are new to us?"

I mean seriously, pal. Everyone in this room works in UX. You are talking to us like we are schoolchildren. 

AND I - FOR ONE - AM SICK OF IT.

The Professor seems surprised. "No. Not at all."

Then why the F*#k are you lecturing us on this stuff like you've just invented it?

The Professor just wants to share their design philosophy with us, they say. They want to point out how they've managed to do all this research AND still deliver stories in a timely manner.

*   *   *

Need to step back a bit here - and I appreciate you for hanging in there on this one. It's ramblier than usual because this stuff just happened a few hours ago.

The Professor and Data have been working on their project for as long as Runner and I have been working on Arwafn. We have a number of accepted stories and a bunch of stories Ready for Development. RFD, the coveted status of UXers in our company.

RFD = Devs don't go hungry = points on the board.

And we have stories that are in progress - and more on the way.

The Professor? The one saying they were able to "deliver stories in a timely manner?"

They have zero stories that are RFD.

TWO DAYS AGO, they dropped 40 stories into the queue and got them estimated. This means they are not RFD, not about to be RFD, but about to be worked on so they will eventually become RFD.

And the Professor is leaving in two hours. These stories - whatever they eventually become - will owe precious little to the Professor, since Data and Sprint will be stuck doing the work to actually make them happen.

And quite possibly Runner and me.

Professor? I CALL BULLSHIT.

*   *   *

So, knowing this - hearing all this, I've stopped being patient and started to call out the competing philosophies in the room. Up front vs as you go.

If I had a choice, from a standing start - with room to breathe - I honestly can't say which of these I would reach for first. Each of them have their advantages.

But there was no choice. UXDirector spelled it out. We are an as-you-go shop. We'll move stuff forward, make mistakes - and then make things better. The Professor has basically ignored this and has gone their own way. UXDirector has let this happen, under the hope/assumption that good stuff will eventually come down the chute. And - to my mind - the Professor has landed a big pile of maybe and is trying to rub our noses in it on the way out.

"I'm frustrated." I say. I point out how I'm told to write a simple story NOW - then make it better. And my reward for that is to drive Data into a near fury.

"I'm not trying to drive you crazy. I'm doing what my boss has expressly told me to do."

And then all kinds of sh!t starts letting go. Data takes issue with my version of RFD. The Professor asserts that our amount of rework will be less than theirs. I'm incredulous.

"You think you won't have rework?"

"Not as much."

The Professor is shoving 40 pigs through the python at once. Or, they would be if they were sticking around to make them RFD. Instead, Sprint and Data will try to make these pieces flow through the system - all interconnected - all co-dependent - and minimize the rework.

Good.

Effing.

Luck.

A lot of the stories are clones of one another, so you build one, you can easily build the other. But if you start them at the same time and one dev finds a problem that another doesn't...?

The devs were saying as much after the tech review. All that interconnectivity being built at the same time ups the risk substantially.

Sprint, bless them, stands up for me. I get the sense that Sprint and UXDirector are on the same page. Sprint lets go with some stuff that had been bottled up for awhile.

And Runner joins in. "We are not an effective team."

And we aren't. Runner nails it. Three of us are in one office and three (soon to be two) are on the coast. We used to have regular meetings as a team and now it's just impromptu phone calls and email.

And stuff gets missed. And then we get angry at...everything.

It's like therapy. Soon people are apologizing and we're agreeing to have regular check ins. Data volunteers to have regular work sessions with Runner and me on Arwafn.

It was horrible and beautiful all at once.

But I'm so glad it happened.

I end up wishing the Professor well - I do hope they are happier in their new shop - but I am glad they are moving on. I suspect I am not alone in that. I want to work in a team and (with the exception of Noddy) everyone else on the UX team is somebody I like and respect.

We just need to get past the awkward and the awful and move forward.

And I think despite - or perhaps because of - the Professor, we took a big first step.

Huzzah!