Page Integrity Testing

Call it “Page integrity testing” (or PIT), call it the UX Review part of QA, call it just “testing”, but every UX Designer whose work gets through a team will eventually get asked to validate the project’s work.

(Note: if you are not being asked to validate work at the end of a sprint that you did detailed design for at the beginning of the sprint, this is a BIG RED FLAG. Seek alternate employment.)

We’re about mid-sprint and I’ve taken on the work of 3 extra teams this sprint, so I’m doing a lot of testing.

Here are three things I do to a) make my developers more successful and b) see them from sending me shitty code to test.

1. Make it clear in the wireframes what I expect.

I regularly call out on my wireframes what is:

  1. Mandatory. I put a ton of thought in it so you’d better be “to the pixel” especially if I’m the one who gave you the CSS for it. If I took the time to put an “H1” label on a wireframe to tell you it’s an H1, and gave you the CSS block for an H1 or a link to where to find it in the style guide, don’t come back to me with a manually-styled div.
  2. Optional. I worked through this most of the way so it’s solid but not as solid as it could be… and it’s also not something that if it slides to next sprint I will scream about. It would be nice if we redesigned the paginator to meet this wireframe this sprint but if you can’t please use the old paginator.
  3. Not thought out. Sometimes I throw something into a wireframe explicitly to get a reaction from your tech leads or your business on what could be and I have no expectation these will make it into the sprint. Wouldn’t it be cool if the encryption field’s interactions worked like this instead of that? No? Not this sprint? Ok, throw it in the backlog.

I don’t like to over-document my stuff because it takes too long, but just the steps above can cut 20 phone calls in-sprint. They also make it clear where I’m very open to feedback (#3) vs not particularly looking for your mind-boggling new design approach because I already did three rounds of user research and testing (#1).

2. Publish my testing steps

I test at the page level. I have a frightening checklist I follow to confirm that a page is correct. Is the right masthead displaying? Is the footer displaying? Is the right global nav displaying and is the right tab highlighted? How about local nav? Does every icon have the proper alt tag?  Are form fields defaulted to the right values? Can I tab through all the fields? It goes on from there.

This is a google doc — in the last company it grew to about 85 lines because every time a developer invented a new way to break something, I’d add that scenario so I’d remember to check for it in the future. (“Are paragraphs in paragraph tags?” by the way  is hands-down the most popular error.)  The current one is only about 35 lines because we’re breaking things in fewer ways here.

Spreadsheet of examples of PIT questions. Across the top: columns for the question, the browser I'm testing (internet explorer, edge, firefox, etc.) and a notes column. Down the side questions like the ones specified in the article. Contact me if you want a copy.)
An example of the first set of lines from a Page Integrity Test I recently ran

I pointedly and sometimes loudly publish the checklist where all my developers can access it.  If you know I’m going to be checking to make sure that big ole block of text at the top is an H1, you’re less likely to roll your own <div style=”font-size:28px”> and see if you can slide it past me.  Some devs use this as their own quick-glance checklist, and some QA folks like to look at it to see how many things they can catch before they get to me.

3. Openly encourage communication.

Want me to look at your screens mid-sprint to make sure you’re on track? Yes I will do that.

Have a question about the wireframe? No question is too stupid if it means you’ll pass QA on the first round.

Think my interaction sucks and will confuse the user? Please, tell me more! I could be wrong! It happens all the time!

You hate the color green? Sorry, for this I will probably laugh at you but at least I’ll tell you that you weren’t the first one to whine at me about green (and I don’t actually like it either but it’s in the brand standards and I’m not here to wage that war when we have an app to build.)

I will set up office hours daily for developer questions.

I will monitor slack after hours if I know you’re working on a tight deadline.

I will work in email, gmail, asana, Jira, and slack simultaneously to answer your questions (though I’d really prefer if you’d consolidate them).

I’ll use four different processes for four different teams in the same sprint if it means your tests will pass on the first try. (I will also grumble about it. Deal.)

If there’s a lack of communication, my goal is to ensure I’m not the cause of that problem. I’m not setting you up to fail, I’m setting you up to succeed.


The vast majority of developers and teams I work with, once they figure out how to communicate and where to ask questions, ensure their code passes PIT on the first try 90% of the time. They want to write good code, I want them to write good code, QA wants them to write good code. The customers want them to write good code too, which is why all this matters.

Also, they want me to make the design decisions so they don’t have to, I want to make the decisions, and QA just wants consistent decisions which is easier when I do it. Funny thing, the customers want a consistent usable experience too, so as long as I’m doing my data-driven, heuristic-informed, usability-tested job, we all get what we want.

There’s always That Guy, or That Team. The one(s) who can’t code a front end no matter how well the code is spelled out for them, how strong the style guide is, and how many examples their tech lead gives them.

But hey, I set clear expectations, I provided open communication, and I kept a spreadsheet of what I tested and when it passed and which Jira it was recorded in… you don’t think that’s coming back to bite me in the butt do you? Let’s just go with “probably not”.

Everyone who’s not That Guy, though, even during crunch time, is getting what they need and giving me what I need, and there’s not much more I can ask.

Twitter must change or die

(This is an expansion on a set of tweets I posted on September 30th, 2017.)

The hideous abuse of Twitter’s users and the lack of strong response from leadership is striking, but Biz Stone’s FEELS got hurt, so here we are. The libertarian mindset of the web, the belief that you own your own words and the best idea may win, is being subverted and abused. The answer is not to use your team as an emotional shield.

There’s this movement on to get Donald Trump banned from Twitter. Mike Monteiro is a troublesome leader of this movement, namely in that he’s shouting over the voices of the many who’ve suffered from Trump’s abuse and Twitter’s wishy-washy response.  That said, there wouldn’t be a movement if Jack Dorsey and Biz Stone CARED ABOUT THEIR CLIENTELE.

I get it. They need to get this business solvent. But the consequences of ignoring users in the name of advertisers is dangerous. They are making one of the biggest mistakes in product management: Focusing on the money, not on the product and users.

Instead of putting the energy into answering the HARD social questions they’ve uncorked, they just release features and whine when pushed. They can’t afford it. Doxxing is just the “cost of doing business.” They flaunt anti-abuse mores just as large corporations flaunt safety and privacy regulations. (I once had someone from a large telecom admit to me that they didn’t care about being 100% compliant with privacy because the fines were just considered “cost of doing business.”)

But Twitter cares, they say. They try, or at least put up a show of trying. But end of the day, Gamergate is just a PR nuisance compared to features the Wall Street people and advertisers like. Twitter is like every company that cares about quarterly results and not about the long term. The cost of abuse is lower than solving it.

It all comes down to the great comment on MetaFilter: “If you are not paying for it, you’re not the customer; you’re the product being sold.” Mike can yell at Jack and Biz all he wants. But stoking abuse and fomenting war only matter if it hurts Twitter’s customers: Advertisers.

All of us Twitter users are the product, the eyes Twitter sells to advertisers who are their actual customers.

Jack and Biz suffer from the same Silicon Valley myopia that brought us Uber’s hideous behavior (harassment, hard-driving PR campaigns, win-at-any-cost, flaunt the rules if it means winning.) And they can’t see that. Silicon Valley is a gravity lens like that.

I want to be an optimist, but until they hire someone who truly speaks for the abused in their boardroom, they won’t change. Until there’s a drive from the C-level down to end Twitter’s bad record on harassment, Trust and Safety are just window dressing.

So it doesn’t matter how much Mike yells. They’re fucked until they get some revenue from the people who fucking care about ending abuse.

I still like Twitter. But I no longer love it. And I can do nothing about it with my 10 years and 3,000 followers because I don’t matter. I don’t generate revenue for them. None of us do.

We’re not the customer. We’re the product. And if you have a problem with it, Biz thinks we should just ignore it and keep scrolling. Don’t like 280 characters? Keep scrolling. Don’t like the treatment of women and people of color on Twitter? Keep scrolling. Positivity!

Twitter must change or die.

And I have little hope they’ll change now. Not as long as we, the users, don’t matter to the bottom line.