“What was less than extraordinary?”
Kyle Neath wrote a post that has been kicking around in my head these last couple of days, resonating more strongly with each hour. Simple titled Product, it cuts to the heart of both product ownership and user experience. Note the lower-case for both of those terms. I’m not talking about job titles – I’m talking about whether you and I as builders truly care about the products we own and the experiences we craft for our fellow humans. Please, go read the piece. I’d love to hear what you think. Here are a couple of great quotes that I expect to revisit in the weeks, months and years ahead:
Caught up in a race for money and fame, we lost our focus on the important. We talk of venture capital, recruiting tactics, dreams of disrupting industries, stock options, growth hacks, and the superiority of our tools. We do not talk of the bugs, the quirks, the difficulties of using our creations, the exploitation of the public, or the worst secret of all: software is broken, we are responsible, and we’re making a lot of money off it.
We’ve become obsessed with process and tools. We’ve stopped caring about the product.
That hurts. It hurts because it’s true.
I guess it’s not surprising that so much software is terrible. It’s easy to be lazy, and it’s hard to build good product. But we get paid to invent the future. The future! That’s an incredible opportunity that blows my mind every day.
Damn right we do. That’s a pretty awesome opportunity. It’s also an awesome responsibility that we should be much more mindful of carrying.
Today’s belief in ineluctable certainty is the true innovation-killer of our age. In this environment, the best an audacious manager can do is to develop small improvements to existing systems — climbing the hill, as it were, toward a local maximum, trimming fat, eking out the occasional tiny innovation — like city planners painting bicycle lanes on the streets as a gesture toward solving our energy problems. Any strategy that involves crossing a valley — accepting short-term losses to reach a higher hill in the distance — will soon be brought to a halt by the demands of a system that celebrates short-term gains and tolerates stagnation, but condemns anything else as failure.
Neal Stephenson from Innovation Starvation
Every UX professional feels the pain that has driven me down my winding career path, but the next steps aren’t obvious and there is not a clear path to follow. I’m trying to document the opportunities that I see, in the hope that others will drive forward, taking risks in order to have a larger impact.
Admittedly, I miss the days where I spent 10 hours in Photoshop or wrangling code. When I’m finalizing budgets, dealing with internal politics, reviewing contracts or defending a product roadmap, I seriously think about returning to those roles. Those challenges are much more familiar. The role far more comfortable. The results of my effort easier to see.
But my influence would be dissipated. My view of the world narrowed. My ability to deliver a great experience reduced, hampered by the decisions of others.
I would not make the impact that I want.
Every so often I’m asked about my career path: “why the switch from coding and design to workflows and wireframes?”, “what prompted the jump from User Experience to Product Management?” or “why the move to the business-side of the house?”
It took me a long time to realize that my reason is simpler than my lengthy replies, outlining a cycle where I gained more control over the experience with each move, only to find that I didn’t have the final say. There was always someone else who would make the call, or could change something that I felt was in the best interest of the user.
Now, my answer boils down to this: I want the best possible experience for our users, and the only way to do that is to be the person who makes the final decision.
Many companies say user experience is critical, but until there are more of us in true, company-wide leadership roles, UX will not have its proper place at the table.
This entry supersedes my earlier post laying out my take on the career possibilities for UX professionals. With this, I aim to shed light on the differences between the options, the responsibilities of the positions and the steps needed to transition from one role to the next.
This post remained a draft for far too long, held there by my hope that I would find time to fill in all of the job responsibilities specific to the PM and UX roles. I lay out four major levels: the Individual Contributor, the Manager, the Senior Manager and the Executive, which I acknowldege is far from exhaustive. There are steps between and within these levels, which aren’t included and there are branches into independent contractor roles as well as design and engineering paths that go unrepresented. Instead of waiting for everything to come together, I’m publishing this as a starting point for us to discuss the possibilities and realities of the industry.
I would love your feedback and look forward to a wide-ranging discussion.
Anything can be forced to converge, but the problem is about trade-offs, and you end up with trade-offs that don’t please anyone. You can converge a toaster and refrigerator, but the end result won’t be pleasing to the user.
Every single person involved in product management or user experience should read this at the start of each day. It doesn’t matter if you’re working at a giant multinational or for yourself, this applies to every feature decision, large and small.
“Stories put all the key facts into an emotional context,” Rosen said. “The information in a story doesn’t just sit there as it would in a logical proposition. Instead, it’s built to create suspense.” And the building blocks of all compelling stories, whether they’re told in person, in the pages of a book, or via actors on a screen or monitor, are challenge, struggle, and resolution. Here, then, is how you build a story: First … get your listeners’ attention with an unexpected challenge or question. Next … give your listeners an emotional experience by narrating the struggle to overcome that challenge or to find the answer to the opening question. Finally … galvanize your listeners’ response with an eye-opening resolution that calls them to action.
It’s time for another installment of the State of the Hostile Web, a series that I’ve never officially started, yet have many entries examples of user-antagonism to highlight.
I don’t know about you, but for me, I immediately heard Kenny Rogers. Maybe that’s because I was born and raised in Texas, but that’s besides the point. This was a crystal clear opportunity to blast the Internet with a reminder of the awesomeness that is The Gambler.
To ensure I got it just right, I did a quick search for the lyrics, and the first site to pop up is called LyricsFreak (they don’t get any link love from me – you’ll see why), which displays the words in all of whiskey-soaked glory. But when I go to cut-and-paste them (you can call it lazy – I call it efficient), nothing is selectable. At all. The normal click-and-drag to highlight doesn’t work and the right-click menu is taking the day off.
I was perplexed. I was annoyed. But I also know a little bit about these here Web pages, so I figured that I would just view the page source to disable the code that was blocking me, or I might copy the lyrics from there.
…and I stopped dead in my tracks, confronted with this:
On a warm summer 's evenin' on a  train bound for  nowhere,
That’s the very first line of the song: “On a warm summer’s eve on a train bound for nowhere”.
Beyond disabling all of the standard methods for copying a bit of text, Lyric Freaks encoded every single character of the song.
Part of me understands that their goal is to not have other people copy their database in bulk. Assuming they paid for the transcription, it has value to them that they want to protect in order to make some money . I get that. I’m a happy little capitalist myself.
But this practice has instantly made the site useless to me, when there is a sea of lyric sites available. Beyond that, any developer can tell you that this won’t make the least bit of difference to someone specifically scraping the Lyric Freaks site to snag their content. None.
So, the people who actually use their service, see, and hopefully click, their ads and tell others to visit are hamstrung.
Which I used oh so cleverly in under 140 characters:
This is a very long blog post that boils down to the fact that LyricFreaks has lost site of what’s important, hurting prospective users before they even have a chance to turn them into fans. All this in an attempt to protect something, using a method that won’t work, making the Web a little less friendly and a little less usable.
User-hostile practices do not work on the Internet. Your site or service is one among many competitors, and it won’t take long for a competitor to eclipse your work, so do yourself a favor and build solutions that reward the user for visiting instead of making their day harder in an attempt to protect a castle made of sand.
We’re all programmers now. We all have to decide what to post next, what to point to next, what to launch next. Is there a skill in dreaming up Must-See Thursday nights, or in establishing a season of Shakespeare or even in deciding what’s on the special list at the restaurant? I think there is.
This is one of the most important lessons I’ve learned over these last few years working at a high-tech media company. Crafting, combining and scheduling content is just as important as, and not that different from, writing code and designing interfaces.
If your work hits the screen, you’re programming at some level.
When you run a £5 billion company you can’t avoid numbers – but if you start with numbers you’ll never innovate… You have to take the action you think will work and the numbers follow.
We are very proud of our empirical focus, because it makes us humble – we realize that most of the time, we don’t know up-front what customers want. The feedback from testing quickly sets us straight, and helps make sure that our efforts are really focused at optimizing the things that make a difference in the customer experience
Neil Hunt, Chief Product Officer, Netflix
The rest of the response to the question “What types of things does Netflix A/B test aside from member sign-up?” is well worth the quick read.
The idea that there are three simple levers that define a feature or a product is passive-aggressive professional absurdity. There are myriad levers the team can adjust, but to understand them you need to understand the people who are actually building the software.
If you haven’t picked up his book Managing Humans: Biting and Humorous Tales of a Software Engineering Manager yet, you should.
Normally a post describing a site launch doesn’t grab my attention, as they cover the same ground (base level descriptions of the design process, technologies used, how great the client is etc.). But the write-up the launch of Dangerbird Records by Athletics, a design firm out of Brooklyn includes a discussion of their home-grown prototyping methods, which is not something you see every day.
I’m constantly refining the process I follow to create wire frames and prototypes. I’m close to a good solution, but it is continually out of reach. Much like the team at Athletics, I’ve investigated Axure RP and similar products, finding them to be much too large for my needs. They’re great for complex, enterprise apps, but they aren’t built for Web apps and sites (they are trying to shift, but I think that will merely lead to larger, more complex apps). I have tinkered with straight up comps and even light weight Web sites, but neither quite meets the need. For the moment I have settled on building wire frames in Visio, followed up by conversations that arise to discuss small details and interactions. No matter how many notes and call outs I add to a wire frame, questions arise.
Wireframes are not ideal for describing the richness and possibilities that are inherent in a Web application.
Prototypes on the other hand are great for conveying placement and interactions without implying design, but they can be time consuming initially as components need to be built and actions and results must be wired together. The Athletics team appear to have found a good method – using Flash plus a little bit of ActionScript to produce fully interactive and informative prototypes. It still requires some of that up-front work, but it is balanced by the ability to quickly revise the prototypes, and more importantly reduces misunderstandings and questions.
If I can carve out some time I will explore this method to see if it’s feasible for my work, but at a minimum it has placed Flash into the toolbox as a possibility for future prototyping projects.
The Task Analysis Grid is an interesting alternative to the standard requirements doc. I think I may give it a whirl at my next opportunity. As noted on the site, it’s a “single document allows anyone looking at it to see the entire scope of a project, figure out what’s in this release (1) as well as what we’re planning for future releases (2, 3, and 4). It’s an extremely effective artifact for getting everyone on the same page.” The numbers (1 – 4) map to priority levels assigned to each requirement.
From Lost Garden comes Software Development’s Evolution towards Product Design a great explanation of how software development should flow, with an excellent, tongue-in-cheek illustration of the entire process.
With a great flourish, I whip out my gold nibbed pen and draw a little diagram on a napkin that explains concisely how modern software development works. In the grand finale, I circle one of the little scribbles buried deep in the entire convoluted process and proudly proclaim “And that is what I do!”.