Make no mistake: you must always speak with your users. As much as I'd like to celebrate my awesome software once we ship, the users get the final say in just how awesome it is, and users don't like software that doesn't fix their problems.* The only way you fix problems is by understanding them, so yeah, talk to your users.
The problem, though, is that users aren't engineers. The same attention to detail they exhibit with their daily tasks is the same attention to detail that derails most demos and leads to four hour excursions into "well can that be a radio button instead of a picklist because it's only ever a select one and never a select many or select all." Your users don't know how easy or hard it is to change things, and they should never (never!) be forced to sit through a technical discussion with an architect to learn the finer points of configuration versus code.**
Worse yet, these discussions typically result in a very slick, very expensive system that effectively reproduces the Excel spreadsheet you're trying to replace. Yes, absolutely let your users help define their own future workflow. Understand, though, that they will always be predisposed to doing things the way they've always done them, and that usually means something like "copy this data to this spreadsheet, move that cell there, and then run the macro."
What can you do about this?
First, pick a use case. At the start of your meeting, mention that you are going to do a quick walkthrough of the new process before you get into details. Execute the steps in your wireframe/comps/demo as if you were the end-user of the system. Gloss over details like button placement and instead show the benefits of your new process: reduced time, reduced complexity, reduced duplication, and increased automation. If you do a good job, they'll stop trying to replicate Excel and start identifying MVP requirements and changes to your process.
Next, have your user walk through the same steps but ask for feedback along the way. If they start talking about trivialities, direct them back towards what;s important. YOU know what's easy to change and thus undeserving of your user's time. THEY have the business context. Trade valuable information, not errata.
Make sure to ask the right questions. You're iterating, so you need to know whether something is truly part of your MVP requirements or not. Don't ask whether they need something, ask whether it's something they do 100 times a day or once. Ask them if it's truly painful or just an annoyance. Figure out what they're willing to trade for this feature that covers an edge case; I personally love the "buy a feature" exercise*** because it highlights priority to users.
Regardless of the quantity and quality of user feedback, business analysis still needs to be done by business analysts. Use your technical knowledge to apply the business context to your solution and everyone drinks champagne on launch day. Otherwise, invest in scotch.
* This isn't always true. iTunes is a classic example of bad software with adoring users.
** When should they be subjected to this? You have two choices:
1. Never
2. The day before they complain to their manager about how annoying/confusing/rude the PM from Tech was.
*** Give your users a list of features and $100. Tell them they can spend the $100 on whichever features they like, but they only have $100. If you want to make it really interesting, you can price the features (where $100 represents the total development capacity of the team) to give a sense of scale. Maybe the big feature isn't as important as fifteen little ones. With a representative sample, you'll have an indisputable prioritized list of features to hand to your product manager. Out of the mouths of babes...
Wednesday, November 28, 2012
Sunday, August 12, 2012
Uptime matters more than almost anything else
Image courtesy of this guy.
Although the meatspace event ended hours ago, those of us on the west coast are just now watching the Spice Girls drive around on LED-encrusted London taxicabs while singing hits from elementary school. Or rather, West Coasters who don't have DirecTV are watching the Spice Girls. I'm watching the error message above that describes a solution but does not enumerate said solution in a way which precludes the need for additional Googling. The "no need to call us" is particularly cute.
The abrupt failure of high definition television services for the west coast, notably Los Angeles, inspired some strong feelings on Twitter. When the error message appeared, I immediately opened Twitter with a search for "directv." The results were...well, take it away, Nima:
You and me both, friend. Of course, some people felt the need to politicize the issue:
I had no idea President Obama had such a tremendous influence on television broadcasts from space. Guess I'm voting Republican. Meanwhile, Crystal made a statement of truth, followed by a statement of questionable veracity:
There's two things I'd like to note from this.
- Before Twitter, how did we all whine?
- Uptime matters. Five nines is not sufficient. In a world where we're looking to save nanoseconds of latency in financial transactions, dropping rovers onto Mars with rocket-powered skycranes, and driving around in LED-encrusted London cabs, there's no reason why every enterprise application shouldn't have 100% uptime. It's time to step messing around.
Wednesday, July 18, 2012
Yet another reason why I'll never be rich
My desk at work is at the far end of the office and mostly obscured by the other cube walls. With goaltending being pretty rough on my knees, I like to sit very low so that I can keep my knees bent when I'm sitting or easily straighten them out by slumping in my chair. This means that people can't see me until they get all the way to my desk. This annoys people.
Were I somebody else, I would default to one of these options:
1.) Deal with it.
2.) Increase the height of my chair and get a box on which to put my feet.
But since I'm not somebody else, I started using this sytem where I placed an index card on the wall behind me to indicate to others whether I'm at my desk, away from my desk, or at home. This was an intuitive, low-tech solution, but failed to address the laziness problem. See, cycling between three index cards requires that I pay attention to what I'm doing and remember to change the cards.
I don't.
So instead of a reliable indicator of my presence, the cards were serving as public reminders of my laziness. They were lying to my coworkers' faces.
The one thing I don't forget to do, courtesy of college roommates, is forget to lock my computer. So I started thinking about having my machine toggle a light on and off when the computer gets locked. Further analysis revealed that this would probably be a lot of work,* so instead I decided to build a light that I could actuate manually.
A little-known fact about my day-to-day interaction with objects is my liking for a good button. Elevators, street crossing signals, keyboards, and anything else with buttons stands to make me much happier with a good, responsive button. Toggle switches are particularly desirable because they've got a solid mechanical feel and a decidedly retro feel.
I go to Radioshack, buy two project boxes, a spool of wire, a package of 68 ohm resistors, a giant LED, a toggle switch, and a roll of solder. We have broken the $20 barrier to build a light. With a broken keyboard donating a usable USB cable, I set to work building the simplest circuit known to man. I can sheepishly admit that replacing a battery with a USB power source in this circuit required the repeated humiliating refactoring of my design as I found myself continually building a circuit whose sole function was to short circuit a USB port.
I swear, I am actually a fully degreed and educated engineer.
So now I have a complicated solution to a simple problem, and all I had to do was spend $20 and a half hour at Radioshack.
.JPG)
*The Googling required to find a piece of software that will turn a light on and off was feeling onerous.
Were I somebody else, I would default to one of these options:
1.) Deal with it.
2.) Increase the height of my chair and get a box on which to put my feet.
But since I'm not somebody else, I started using this sytem where I placed an index card on the wall behind me to indicate to others whether I'm at my desk, away from my desk, or at home. This was an intuitive, low-tech solution, but failed to address the laziness problem. See, cycling between three index cards requires that I pay attention to what I'm doing and remember to change the cards.
I don't.
So instead of a reliable indicator of my presence, the cards were serving as public reminders of my laziness. They were lying to my coworkers' faces.
The one thing I don't forget to do, courtesy of college roommates, is forget to lock my computer. So I started thinking about having my machine toggle a light on and off when the computer gets locked. Further analysis revealed that this would probably be a lot of work,* so instead I decided to build a light that I could actuate manually.
A little-known fact about my day-to-day interaction with objects is my liking for a good button. Elevators, street crossing signals, keyboards, and anything else with buttons stands to make me much happier with a good, responsive button. Toggle switches are particularly desirable because they've got a solid mechanical feel and a decidedly retro feel.
I go to Radioshack, buy two project boxes, a spool of wire, a package of 68 ohm resistors, a giant LED, a toggle switch, and a roll of solder. We have broken the $20 barrier to build a light. With a broken keyboard donating a usable USB cable, I set to work building the simplest circuit known to man. I can sheepishly admit that replacing a battery with a USB power source in this circuit required the repeated humiliating refactoring of my design as I found myself continually building a circuit whose sole function was to short circuit a USB port.
I swear, I am actually a fully degreed and educated engineer.
So now I have a complicated solution to a simple problem, and all I had to do was spend $20 and a half hour at Radioshack.
.JPG)
*The Googling required to find a piece of software that will turn a light on and off was feeling onerous.
Tuesday, July 17, 2012
What UX Is
User experience design has spiraled wildly out of control since the release of iOS with the iPhone a couple years ago. Menus have become passé. Navigation is supposed to be touch friendly. Hell, even Microsoft is getting rid of the ubiquitous Start menu, having already eliminated (or at least hidden) the File and Edit menus.
These changes are not improving usability. Changing usability, yes, but not fundamentally improving the usability of an application.
Usability is not a measure of how easy something is to use, although that is often an important factor. Rather, it's a measure of how effectively something helps you complete your work.
Software isn't usable because very often, what we do with software isn't possible in the real world. Unfortunately, we keep trying to create digital representations of physical things in a futile effort to make things easier to understand, more "intuitive*."
Why are we doing this? Why do we keep forcing users into arbitrary folder structures to store files? Aren't there cases where a single file makes sense in two locations? Does a user care where a file is stored as long as he can find it? Does it even make sense to require users to save files?
These are the types of questions an effective UX designer will ask.
It's unreasonable to expect that every user will sit down with an application and instantly understand how to complete their work. In some cases, I'd argue it doesn't even make sense to try making an application instantly understandable. There will always be an upper bound on the number of functions an application can perform before it becomes necessary to start stashing things in menus. And that's okay! Users will put up with questionable UX if the software improves their lives. They will not put up with beautiful UX and no functionality.
There are some obvious things to avoid. The California DMV provides a particularly egregious example:
Outside silly problems like this, though, good UX is achieved through an understanding of user goals. Understand your users, understand their goals, and you'll construct an interface that gets out of their way.
*"Intuitive" is a word whose incessant use in IT leaves me confused and angry. The word has no meaning because it results in no action. Ask a user "is this intuitive?" and they'll say yes or no, providing absolutely no help and forcing you to ask the better question, like "what about this tool makes it easier or harder to accomplish this task?" "Intuitive" is not a quality of software. It is a buzzword.
These changes are not improving usability. Changing usability, yes, but not fundamentally improving the usability of an application.
Usability is not a measure of how easy something is to use, although that is often an important factor. Rather, it's a measure of how effectively something helps you complete your work.
Software isn't usable because very often, what we do with software isn't possible in the real world. Unfortunately, we keep trying to create digital representations of physical things in a futile effort to make things easier to understand, more "intuitive*."
Why are we doing this? Why do we keep forcing users into arbitrary folder structures to store files? Aren't there cases where a single file makes sense in two locations? Does a user care where a file is stored as long as he can find it? Does it even make sense to require users to save files?
These are the types of questions an effective UX designer will ask.
It's unreasonable to expect that every user will sit down with an application and instantly understand how to complete their work. In some cases, I'd argue it doesn't even make sense to try making an application instantly understandable. There will always be an upper bound on the number of functions an application can perform before it becomes necessary to start stashing things in menus. And that's okay! Users will put up with questionable UX if the software improves their lives. They will not put up with beautiful UX and no functionality.
There are some obvious things to avoid. The California DMV provides a particularly egregious example:
Outside silly problems like this, though, good UX is achieved through an understanding of user goals. Understand your users, understand their goals, and you'll construct an interface that gets out of their way.
*"Intuitive" is a word whose incessant use in IT leaves me confused and angry. The word has no meaning because it results in no action. Ask a user "is this intuitive?" and they'll say yes or no, providing absolutely no help and forcing you to ask the better question, like "what about this tool makes it easier or harder to accomplish this task?" "Intuitive" is not a quality of software. It is a buzzword.
Wednesday, July 11, 2012
Stop thinking strategically
My first day in post-graduate corporate America required a dramatic and unsettling change in my decision making. No longer was it enough to merely accomplish the goal - I had to think "strategically."
My problem with words like "strategic" is that they're rarely used in a way which corresponds to their English definition. I learned quickly that "strategic" meant "in a way that's unlikely to solve our problem but also unlikely to offend executives." And while there are valid reasons to make decisions classified as strategic or tactical, this insistence on being strategic overlooks the obvious: do the right thing.
Many hyper-dysfunctional IT departments become paralyzed by unexplained business decisions made years before. Having endured years of failure as a consequence of shortsighted management and a generally inept staff, they revert to the risk-averse approach of avoiding short-term fixes. Why bother fixing one defect if there are ten more? Wouldn't it make more sense from a strategic standpoint to just refactor the whole thing and fix them all? Let's form a tiger team! We can hire some consultants to introduce a new stack and let the stack fix everything! We won't even need developers because EVERYTHING WILL BE CONFIGURATION!
Meanwhile, the users are sitting around wondering why some critical piece of software has had an obvious bug hampering their work for months, the engineers are shaking their heads, and the corporate overlords are ten minutes from firing their third CIO in two years.
The right decision is to fix problems. Tolerate hacks that improve the user experience . Of course, yes, I understand, individual fixes may often create a hostile user experience in aggregate, and yes, you need to reinforce the need to pay down technical debt or incur an unmanageable tax. Sure, go for the whole-enchilada refactor when you must. But the correct solution to a pressing, time-constrained problem very rarely includes things like tiger teams.
Just like developers who pair program effectively surrender ownership of their code, effective project managers should surrender the desire to put their personal imprint on the project. Commiserate with your users and prioritize accordingly.
My problem with words like "strategic" is that they're rarely used in a way which corresponds to their English definition. I learned quickly that "strategic" meant "in a way that's unlikely to solve our problem but also unlikely to offend executives." And while there are valid reasons to make decisions classified as strategic or tactical, this insistence on being strategic overlooks the obvious: do the right thing.
Many hyper-dysfunctional IT departments become paralyzed by unexplained business decisions made years before. Having endured years of failure as a consequence of shortsighted management and a generally inept staff, they revert to the risk-averse approach of avoiding short-term fixes. Why bother fixing one defect if there are ten more? Wouldn't it make more sense from a strategic standpoint to just refactor the whole thing and fix them all? Let's form a tiger team! We can hire some consultants to introduce a new stack and let the stack fix everything! We won't even need developers because EVERYTHING WILL BE CONFIGURATION!
Meanwhile, the users are sitting around wondering why some critical piece of software has had an obvious bug hampering their work for months, the engineers are shaking their heads, and the corporate overlords are ten minutes from firing their third CIO in two years.
The right decision is to fix problems. Tolerate hacks that improve the user experience . Of course, yes, I understand, individual fixes may often create a hostile user experience in aggregate, and yes, you need to reinforce the need to pay down technical debt or incur an unmanageable tax. Sure, go for the whole-enchilada refactor when you must. But the correct solution to a pressing, time-constrained problem very rarely includes things like tiger teams.
Just like developers who pair program effectively surrender ownership of their code, effective project managers should surrender the desire to put their personal imprint on the project. Commiserate with your users and prioritize accordingly.
Tuesday, July 10, 2012
Dogma
Note: This wasn't really what I planned for my first post here. I have this whole "anti-business speak in IT" thing I've been thinking about for months, but I felt the fire last week and went here instead. Boom?
There's a groundswell of support for pragmatism in agile software development. And why not? There's definitely a compelling argument that agile principles necessarily promote pragmatism, and I'm not going to hammer away at my keyboard denying this. The problem is, though, that in every organization I've seen, pragmatic turns into sometimes, sometimes turns into never, and never is amongst the dirtiest words in software.*
My organization was engaged with an agile-leaning software consultancy for about two years, with most of that time coming before I joined this noble band of nerds. Upon their departure, I made my best effort to appear receptive to feedback and had a chat with an extremely intelligent and extremely proficient software engineer to discuss my job performance and other Things That Are Important Now That I'm An Adult. I was surprised by his comments. Rather than criticizing my sardonic management style or penchant for accidentally scheduling meetings in the wrong time zone, he made a plea.** Excuse the misleading quotations; this is not a direct quote, but I nevertheless wanted to make it appear conversational, because that's apparently how I am:
The aforementioned consultancy is frequently accused of being dogmatic to a fault. And, perhaps, it's true. The PMs who trained me insisted on biweekly iteration planning meetings, showcases, and retrospectives. They demanded dev huddles, daily standups, and thorough acceptance criteria. They added ACs like "Given that I am a developer who cares about quality, when I am working on a story, then I will write JS unit tests."
But they also defended core hours. They impressed product management. Most importantly, they delivered. And delivered. And delivered. Where our department had previously failed our clients, again and again, we started delivering high quality, high value software. We moved engineers between teams without sacrificing velocity or quality, we adapted to scope and requirements changes, and we got along. We sang karaoke. We drank beer. We watched the Kings win the Stanley Cup (well, I did, at least). Because we embraced the ideas behind the dogma, it stopped feeling religious and started feeling right.
"Pragmatic pairing" and "as-needed retrospectives" are a bad solution to an inevitable problem: every software shop is understaffed. Yes, it is absolutely possible to increase velocity by reducing the amount of time developers spend pairing, and yes, reducing meetings like IPMs and retros will increase the amount of time your devs can spend in Visual Studio. But the process has proven to be unreliable and unsustainable. Knowledge will be lost when your senior engineers wander off into the weeds to solve a problem while junior engineers implement the same feature toggle they've implemented 100 times before. Personalities will grind when the retrospective prime directive is not recited and retros, when actually held, will turn into performance reviews rife with ad hominem attacks and, yes, existential angst.
So when your team starts talking about pragmatism, address the underlying cause and move even further towards the dogma. Your clients will thank you and your devs will...well, they'll get it. Eventually.
*The dirtiest phrase, of course, is "scope creep." The horror!
** He also told me to start acting more seriously when people come to me with problems. Apparently, my flippant attitude isn't particularly comforting for the techies, although the business folk seem to enjoy it. I'm still an engineer, I guess, and the years of losing to math exams have created a coping mechanism in cynicism.
There's a groundswell of support for pragmatism in agile software development. And why not? There's definitely a compelling argument that agile principles necessarily promote pragmatism, and I'm not going to hammer away at my keyboard denying this. The problem is, though, that in every organization I've seen, pragmatic turns into sometimes, sometimes turns into never, and never is amongst the dirtiest words in software.*
My organization was engaged with an agile-leaning software consultancy for about two years, with most of that time coming before I joined this noble band of nerds. Upon their departure, I made my best effort to appear receptive to feedback and had a chat with an extremely intelligent and extremely proficient software engineer to discuss my job performance and other Things That Are Important Now That I'm An Adult. I was surprised by his comments. Rather than criticizing my sardonic management style or penchant for accidentally scheduling meetings in the wrong time zone, he made a plea.** Excuse the misleading quotations; this is not a direct quote, but I nevertheless wanted to make it appear conversational, because that's apparently how I am:
"Your organization has achieved success. But the success has brought laziness. Your developers are avoiding pairing. The business analysts are writing stories without QA input. Your QAs are rejecting stories without talking to the devs. At least one team hasn't had a retrospective in over a month.
All of the success the department has had over the last two years has been predicated on knowledge, whether it's knowledge shared between pairs or knowledge shared across the business. Do not allow "pragmatism" to infiltrate your teams. Be the person who upholds agile principles with conviction because success will minimize the organization's value of retrospectives, of showcases, and of pair programming. You always talk of how wonderful your mentors have been. What would they do? Be them now."
The aforementioned consultancy is frequently accused of being dogmatic to a fault. And, perhaps, it's true. The PMs who trained me insisted on biweekly iteration planning meetings, showcases, and retrospectives. They demanded dev huddles, daily standups, and thorough acceptance criteria. They added ACs like "Given that I am a developer who cares about quality, when I am working on a story, then I will write JS unit tests."
But they also defended core hours. They impressed product management. Most importantly, they delivered. And delivered. And delivered. Where our department had previously failed our clients, again and again, we started delivering high quality, high value software. We moved engineers between teams without sacrificing velocity or quality, we adapted to scope and requirements changes, and we got along. We sang karaoke. We drank beer. We watched the Kings win the Stanley Cup (well, I did, at least). Because we embraced the ideas behind the dogma, it stopped feeling religious and started feeling right.
"Pragmatic pairing" and "as-needed retrospectives" are a bad solution to an inevitable problem: every software shop is understaffed. Yes, it is absolutely possible to increase velocity by reducing the amount of time developers spend pairing, and yes, reducing meetings like IPMs and retros will increase the amount of time your devs can spend in Visual Studio. But the process has proven to be unreliable and unsustainable. Knowledge will be lost when your senior engineers wander off into the weeds to solve a problem while junior engineers implement the same feature toggle they've implemented 100 times before. Personalities will grind when the retrospective prime directive is not recited and retros, when actually held, will turn into performance reviews rife with ad hominem attacks and, yes, existential angst.
So when your team starts talking about pragmatism, address the underlying cause and move even further towards the dogma. Your clients will thank you and your devs will...well, they'll get it. Eventually.
*The dirtiest phrase, of course, is "scope creep." The horror!
** He also told me to start acting more seriously when people come to me with problems. Apparently, my flippant attitude isn't particularly comforting for the techies, although the business folk seem to enjoy it. I'm still an engineer, I guess, and the years of losing to math exams have created a coping mechanism in cynicism.
Subscribe to:
Posts (Atom)