Month: October 2017

I like design sprints. In Alan Cooper’s mind, I’m now a fake designer.

Right now thousands of faux designers are trying to find ways to justify the existence of design sprints. Can’t do it. https://t.co/kbiGSGl4oH

— Alan Cooper (@MrAlanCooper) October 24, 2017

But I like them, when used correctly, in the correct context. Design sprints package up the business and design thinking in a larger process and exposes a cross-functional team to them. They also lay bare holes in research, team expectation misalignment, and organizational problems. Design sprints are great at driving alignment.

They’re not so good at making sense of messes for users. During a poorly-prepared sprint, the user may be left out of the equation, especially if the research brought into the sprint is too sparse or relient on personal opinion.

In both cases, it comes down to what a sprint does well — help the people in the room move fast, learn fast, and drive to agreement.

Designers need tools, methods. We need plays in our playbook. Some work better for driving business alignment, others work better for making sense of a mess from the eyes of a user.

The problem rises when you treat design sprint not as a tool or a method but as the whole of your design work for a product. Do this and your clean view of the world will slam hard into the cold, difficult, and messy reality of humans using your product in ways you never expected.

I’m not one who likes the idea there’s a “bright line” between designers and the rest of the world. It’s like saying only scientists can practice science. We’re all designers, just as we’re all scientists. Some of us do it professionally, with rigor and tens of thousands of dollars invested in our names and degrees. But designers are not the holders of all the Great Design Ideas Of History. We are designers because our knowledge and experience allow us to make great ideas happen more often than bad ones.

What you take into a design sprint is important to the ultimate outcome of the method. Bring your research and domain knowledge and you’ll stand a good chance of making a prototype that sends you in the right direction. Go in without research or with strongly held but untested beliefs and you will be spending five days doing self-design, the surest way out there to guarantee you’ll create a Homer Car.

I don’t like the term “design sprint.” It’s neither “design” nor a “sprint;” rather, it’s a highly compressed discovery and prototyping session. Sprints are built to break up work into deliverable chunks; they’re not one-off deals. As for design, without research it’s just five days of wild guessing.

But I also don’t like this desire for purity in the design process, either. I’d love for design to get all the time and resources it needs, for all design to work like agencies with unlimited expense accounts and all the time in the world. But, to paraphrase Hamilton, “Welcome to the present, we’re running a real design organization.” In a time where UX is still, still fighting its way into companies and evangelizing more than a Baptist tent revival preacher, none of us can just sit idly by and wait for organizations to just “give” design what it rightfully deserves. We have to win the right to be heard, show business value, and continue driving towards truly design-centric thinking in organizations.

So. I don’t hate design sprints. I’ve used them (and similar discovery practices) to get design a beachhead in skeptical organizations. If you treat them as a play in your playbook and understand their advantages and limitations, you will get value out of them.

Don’t treat them as miraculous. They’re not. Silicon Valley loves to hype its newest one-solution-for-everything. But it’s just hype. Like a playbook or a toolbox, take the things you need, understand what they’re useful for, and leave out the useless things.

And that’s what “real” designers do — they understand their tools and methods, their power, their limitations. And they are always open to new tools and methods. They also don’t believe in miracles. They only believe in the effective, rigorous drive of delivering to the user everything they need to get their jobs done.

Want to know why everyone over a certain age gets mad when they have to buy your software?

When I was 13 I bought software (mostly games and the occasional writing application) from a stand at the farmer’s market, on 3 1/2 inch floppy disks wrapped in shrink wrap. It ran on my dad’s Tandy HX 1000, which by the way, didn’t have a hard drive.

When I was in my late teens I either bought my software at CompUSA on a CD or downloaded shareware via a 56k modem onto the Performa 5200 CD I bought with a personal loan so I could go to college… a year before cat 5 wiring came to our dorms, and the same year that the Mozilla Navigator browser started showing pictures. We were students, so Mozilla was free.

I paid for most of that shareware, by the way, on this brand new thing call the Internet that started taking credit cards about halfway through my undergrad degree.

I remember when the IT industry got rid of the floppy disk. I remember when we adopted the Zip Disk, and then got rid of it. I remember when we adopted first the CD drive, then the DVD drive, then the Blu-Ray drive, and abandoned them all.

Back in the day, I could register my software if I wanted to, but I didn’t have to. It was enough that I bought it, had the registration code on a sticker on the back of a CD case on the bookshelf in my folks’ basement. Could I get cracks? Sure if I felt like spending a gazillion years surfing scary looking websites from the campus library (the only connection fast enough) but I was poor and my computer couldn’t hold most of the really good software anyway because I couldn’t afford a decent sized hard drive.

Back in the day, when I bought a software license, it was good literally until my operating system couldn’t run the application anymore, and then I could upgrade it for another piece of software that also lasted until the OS was no good.

All this to tell you what I needed to do to buy Microsoft Home 365 tonight because Microsoft 2008 (my current version) has been struggling a bit lately and I thought an upgrade might fix my problems:

1. Register for Microsoft Live, which required my name and birth date, and which I didn’t want to join. I am not a joiner. I do not want to be in your fancy Microsoft Club. I didn’t even sign up for Nintendo Power when I was a kid and I was certainly in the right age group.
2. Provide my Paypal account info for billing.
3. Provide my mailing address even though I’m not getting a physical product, nor do I intend to get shit in the mail from Microsoft, and the whole reason to use Paypal is to not have to give my address out to companies who don’t need to know where I am.
4. Uncheck numerous offers from Microsoft to sign up for the marketing I don’t want because god almighty Microsoft just let me get to the damn software already.
5. Confirm my account registration through a two-factor authentication text message to my cell phone which means the assholes now have my cell phone number even though if they ever call me and text me I will blister their ears with my response. There was absolutely no way around this and if they hadn’t already gotten my PayPal info I would’ve likely told them where to go stick themselves right at that moment.
6. Download a 1.57GB package (which, by the way is 1,570 times the size of my first 1mb hard drive) over my cable modem (which is a gazillion times faster than dial-up) so that I could install the software.
7. Run the installer, which I am glad to say, has always taken seconds for the first 99% of the installer and another 5 minutes for the last 1%. At least Microsoft is consistent.
8. Finally launch the app.
9. Sign in to Microsoft Live, which did I mention I didn’t intend to join? And what if I don’t have an Internet connection? Or block Office from surfing the web? Is this shit even usable if it can’t phone home?
10. Finally launch the app.

That’s too much like goddamned work especially when you already picked my pocket for the software license.

Here’s the thing, wanna-be-software-developers-and-marketers: I don’t want to engage, I want to download the damned software I just bought. I don’t want to sign up for a yearly license so I always have the most up-t0-date version, I want to buy the software that will run until the computer dies. I don’t want to join your network, I want to get my shit done.

You don’t need my name, you don’t need my address unless you’re running my credit card, and you sure as fuck don’t need my birthdate or my cell number. You don’t need to know my username and password unless I want to give you a goddamned username and password.

And don’t lecture me about people pirating Microsoft Office. There’s so many goddamned free software apps that do the same thing Office does in the same file format that the only reason I bought the damn app in the first place instead of using Open Office was because I’m still a little grateful Microsoft funded Apple back in 1997.

I don’t use Gmail or most Google apps, I avoid using Facebook as much as I can, and I’ve cut the number of people I follow on Twitter by something like 75% because I believe that if you’re not paying for it, you’re the product. They’re not building that software out of the goodness of their hearts, and more often than not they’re figuring out how to monetize my eyeballs, my wallet, or my personal information for their gain.

I haven’t upgraded to the Adobe Suite or Microsoft Office 365 for similar reasons – if I only launch a product once every few weeks, why should I pay every month for something I don’t need to upgrade on a regular basis?

The dollar cost average of my let’s-call-it $250 license for Microsoft Office 2008 is about $2.40 a month since I bought it almost 10 years ago.

I only launch Word when the fiction sites I intend to submit to require a .docx file so $2.50 a month seems like a pretty good deal for what is essentially in my life as a file converter. I only launch Excel if someone sends me a .csv so I can convert it to something useful. I don’t launch the rest of the Office apps at all. Half the time I do launch Word 2008 I get told that it needs a security update (Adobe’s track record is roughly the same because apparently PDFs are a goddamned sieve) and the other half of the time I have to beat on it to create the files in a reasonable file size.

Now Microsoft has my name, address, phone number, the fact that it’s a text-enabled cell phone, my email address, birthday (if they believe it’s accurate) and not a goddamned thing explained what they intend to do with it.

But oh I’m sure we’re totally secure and comfortable with that especially what with the Equifax data breach and all.

Get off my goddamned lawn, take your shitty marketing ploys and desperate attempts to cash in on my identity with you. I’ll continue buying until-the-computer-craps-out licenses for cheaper software from your competitors from here out.

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) keep 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.

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.

Results

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.