Key Position: Sr. UIE Manager for our Wallet team

I have discussed in the past that we have been on a mission to change the culture, technology, process and experiences at PayPal. 15 months into my adventure here I have never been more excited.

Starting last year we moved away from Java & JSP for rendering our UIs and instead went to JavaScript templating (dust.js), using LESS for our CSS pre-processing, require.js for module dependency, jQuery, Twitter Bootstrap and bunch of other open source goodness. In addition, we have been using node.js as the underpinning for building our user experience code in a rapid, high iteration fashion. And even more exciting we are working on getting node.js to the point of production ready to build our app stack on top of it.

In addition, we have been pioneering Lean UX as a working model that puts our user interface engineers in the room directly with product & design to help lead our new experiences.

And we have been hiring some great talent.

Speaking of talent, I need to find a great manager for one of our most important teams -- the Wallet team. All of the consumer experiences fall under this area and cover desktop, tablet and mobile. We are also leading the charge on mobile first and the wallet team has many exciting opportunities to rethink the consumer's wallet across these channels.

Here is a link to the job description:
http://jobs.ebaycareers.com/silicon-valley/user-experience/jobid3066378-sr-uie-manager-wallet-paypal-jobs

What am I looking for? You should be passionate about all things front end. You should have a good solid history of writing and delivering front end applications in JavaScript and have a strong understanding of all of the industry best practices as well as the industry trends and key open source projects. Some experience with node is a plus.

What do I need you to do? Since the team is about a dozen in size, I don't need you coding on a daily basis. What I want you to do instead is to take this great team to greater heights. Inspire them. Grow them. Mentor them. Help instill great engineering into the team (continuous integration/deployment/social coding). I also need you to be passionate about experience. And passionate about delivering this experience to multiple channels. Ensure that we are utilizing responsive web design in every possible way.

You will need a strong working relationship with our product team, middle/backend engineering teams, and user experience teams. You will set the example for how this team gets stuff done. I need you to be a leader!

If you are interested in this exciting challenge then ping me right away. I am on twitter @billwscott or same handle for my email at gmail.com.

Indispensable Principles for Debugging - Book Recommendation

Don't judge a book by it's cover (or it's website... or it's poster). Especially true in this situation. David Agan's book "Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems" is a great find, chocked full of simple wisdom on how to find and fix bugs. Some of you will be turned off by his use of Comic Sans (see his note at the bottom of his website for his funny comment on why he sticks by his comic sans guns).

What it is not.
It is not a tutorial for any debugging tool. It is not a primer for debugging in any specific language. It is not an exhaustive tome on debugging. It doesn't have specifics on debugging for the web.

What it is.
Short and sweet. It contains 9 principles that are timeless and can be applied to any system you are trying to debug. Timeless aspect.

Why this book?
I have often wondered why some engineers seem to be able to debug and fix issues and others just create a mess when they try. Of course some minds work in a more systematic manner than others and some have more insight. This book teases out the principles that underly finding and fixing issues. The principles are dead simple and completely obvious when you glance at them. But I promise you that a lot of our colleagues don't practice even a portion of these.

I also like this book because it is a little older and it doesn't try to tie itself to the current trends. One of his first "war stories" is about debugging one of the original Pong games. Love it. First published in 2002, and then again in 2006, it is kind of hard to find. I bought the last 7 copies from ebay today but you can get it from the kindle bookstore.

Nine Principles

1. Understand the system
2. Make it fail
3. Quit thinking and look
4. Divide and conquer
5. Change one thing at a time
6. Keep an audit trail
7. Check the plug
8. Get a fresh view
9. If you didn't fix it, it ain't fixed

Do you have other suggestions for teaching the basics of debugging? Comment below.

User Interface Engineering Disciplines & Skills

One of the first things I did when I joined PayPal was rename the "webdev" to "User Interface Engineering". Now while there is nothing wrong with the title web developer, at PayPal webdevs were considered one step below a "dev".

Changing a title in itself is fairly meaningless. But at the same time names are powerful. Over the last year I believe we have been really growing into the title. Recently I started sketching all of the engineering disciplines as well as web development skills needed for this role. Here is the diagram I created.

Here is an accessible version of the diagram above.

One of our next steps is to flesh out curricula that ties to the diagram above. We are calling this courseware "Bring Design to Life University" since our job as UIEs is to bring great design to life.

List of Mockup/Prototyping Tools

Started keeping a list of these tools. No particular order.

Creately

http://creately.com/

Axure RP

http://axure.com/

InVision

http://www.InVisionApp.com

Mockingbird

https://gomockingbird.com/

Balsamiq Mockups

http://balsamiq.com/products/mockups

Ratchet

http://maker.github.com/ratchet/

Justinmind

http://www.justinmind.com/

HotGloo

http://www.hotgloo.com/

FlairBuilder

http://www.flairbuilder.com/

Mockflow

http://www.mockflow.com/

mocklinkr

http://www.mocklinkr.com/

Mockabilly

http://www.mockabilly.com/

moqups

https://moqups.com/#!/

AppMockupTools

http://www.appmockuptools.com/

WireframeSketcher

http://wireframesketcher.com/

JustProto

http://www.justproto.com/

Napkee

http://www.napkee.com/

ForeUI

http://www.foreui.com/

Jumpchart

http://jumpchart.com/

Protoshare

http://www.protoshare.com/

iPhoneMockup

http://iphonemockup.lkmc.ch/

Lumzy

http://www.lumzy.com/

Pidoco

https://pidoco.com/

Proto.io

http://proto.io

AnteType

http://antetype.com

AppSketcher

http://appsketcher.com

MockupBuilder

http://mockupbuilder.com

PowerMockup

http://powermockup.com

AppCooker

http://www.appcooker.com/Overview.php

Tiggzi

http://tiggzi.com/home

iPlotz

http://iplotz.com/whatisiPlotz.php

Serena

http://www.serena.com/products/prototype-composer/index.html

fluidIA

http://www.fluidia.org/

FrameBox

http://framebox.org/ECIN

Naview

http://www.naviewapp.com/

DENIM

http://dub.washington.edu:2007/projects/denim/

UIreframe.com

http://uireframe.com/app/

GUI Machine

http://gui-machine.com/

inPreso Screens

http://www.inpreso.com/inpresoscreens/

UXPin

http://uxpin.com/

SoftAndGUI

http://www.softandgui.co.uk/

Notism

https://www.notismapp.com/home

MockupScreens

http://www.mockupscreens.com/index.php?page=Screen-Prototypes

MockupTiger

http://www.mockuptiger.com/

JotForm

http://www.jotform.com/

Keynotopia

http://keynotopia.com/

Handcraft

http://handcraft.com/

Added after original publishing of this article:

LucidChart
http://www.lucidchart.com

Twitter Bootstrap
http://twitter.github.com/bootstrap/

JetStrap
http://jetstrap.com/

Lean UX & Agile Development. Rationalizing the Two Methodologies

I really enjoy Silicon Valley Code Camp. Lots of speakers, lots of local attendees. Very informal and always a good crowd. No different today. Really engaged audience.

One topic I covered was how Lean UX and Agile work together in harmony. Here is a diagram I shared that I have been using at work to explain how they are related and how they are different.

Agile focuses on iterative delivery. It is by nature engineering-centric (though it has been applied to non-engineering tasks) as it produces software meeting specific acceptance criteria. It has numerous ceremonies instead of heavy process like waterfall methodologies require.

Lean UX focuses on refining the experience through collaboration, shared understanding and continuous customer feedback. While agile finds its roots in engineering, Lean UX stems from work borrowed heavily from Eric Ries in the Lean Startup and applies it to refining customer experience. Lean dispenses with agile ceremonies but like agile also dispenses with extraneous documentation. Lean UX gets its cadence from getting prototypes or mockups in front of customers regularly while agile gets its cadence from delivering working software released at the end of each sprint.

In the above diagram I call out this separate stream of work -- the Lean UX stream. It is separate from the agile streams, but does not replace the agile streams. It runs ahead of the agile streams like Sprint 0 methodology but it does not stop with sprint 1 (nor is it confined to starting one sprint ahead). It continues to run in parallel with the agile tracks. What gets learned in the LeanUX stream (essentially a continuously evolving living prototype) gets fed into the agile streams and becomes some of the user stories. Its cadence may change (we usually start with weekly usability testing and then slow down to every 2 weeks or so) but its purpose does not. Separately I have noted the technology changes we have introduced that allow us to have seamless movement between Lean UX streams and Agile streams with respect to software delivered. This is an essential ingredient to making this work well.

Lean UX & Agile work together well. And while they share lots of common principles they are distinct work streams. Lean UX & Agile aren't the whole picture on how to create great products. You also need to be able to gather customer insights, define customer problems, refine solution concepts, deliver & test solutions and then rinse & repeat these steps. Lean UX is one tool to help us refine & test solution concepts. Agile helps us deliver solutions. A/B testing helps us test what we deliver. Customer driven innovation (pioneered at Intuit) defines a broader methodology that Lean & Agile fit nicely inside of.

Ok, so with that context here are the updated slides from the talk I gave earlier today on Anti-Patterns for Lean UX. You can see an earlier version on slideshare.

Are you using Agile & Lean UX methodologies? How are you approaching innovation & experience delivery in your organization?

Three Key Principles to Operating as a LeanUX Team

Coaching teams here at PayPal on what it takes to operate like in a LeanUX manner. I have typically boiled it down to just 3 key principles.

Three Principles

1. Maintain a Shared Understanding at All Times

This was key when I was at Netflix and I see it even stronger now. A lack of a shared understanding means you will have have to lots of documentation. Having documentation that is predictive in an iterative environment is problematic. It is not realistic since you need to be able to change assumptions and solutions early in the cycle. Historical documentation becomes more necessary as teams downstream need them.

A good way to alleviate much of the documentation normally needed is to pull the teams that are normally downstream (like QA, Localization QA, Localization, etc.) and bring them up further in the earlier cycles. Additionally you can create tools earlier in the process that proxy for these teams and reduce the number of those representatives you will need. Tools downstream should be automation driven as much as possible.

In a recent LeanUX project I kept referring to a/b testing. At some point it became apparent that not all the team understood what I meant by a/b testing (remember this is what I ate, drank & slept at Netflix). It was an easy solve to get us a shared understanding, but the mistake was assuming we had one already on all topics.

2. Collaborate, Collaborate, Collaborate

Walls between teams get erected whenever teams get big, become overly specialized and work in isolation. Agreeing to work as a team, trust each other and make collaboration the underpinning of the team's ethos will ensure the walls will come down.

It's not easy. We like to retreat back to the comfort of going solo or dictating to another the way things work. How can you tell where the walls are? It will be at those hand-off points that happen across disciplines. Collaboration is the opposite of this toss it over the wall mindset.

It's ok for teams to take time to work separately or have sessions to reflect. But if you are doing this to avoid working as a team then watch out. Trouble is already at your door.

3. Build/Test/Learn -- or Get to the Customer Early & Often

This is the secret to getting rid of team politics, getting rid of the prima donna, getting rid of analysis paralysis. Getting to the customer in usability tests, research, a/b testing and so on and doing it on a weekly or bi-weekly basis if at all possible keeps the team pure. It is the difference between a stagnant pond or a clear lake fed by streams. User data & user feedback will keep the team focused on the customer and the real goals of the product. 

Believe me this really works. It is astonishing to see how much ownership takes over the team when they sit in all the usability sessions as a team and watch the successes and failures of their work. I have seen the full team time & again go out of a session that didn't go so well with a renewed determination to nail it next time. Customer feedback is the elixer to what ails you (now I just have to mention that all of the standard practices of how to gather this feedback and what to do with it still apply).

It's Pretty Simple

Fragile is often the name given to agile projects that are busted. I have used the term "Lean-Fall" to describe that ugly mix of waterfall & LeanUX. When I talk with teams that are struggling to work in an agile manner it could be a host of issues. There is a lot of machinery from an agile practice standpoint that might need tweaking.

But frankly, over and over I have seen it come down to one or more violations of these three principles. If you don't have shared understanding, collaboration and continuous customer feedback, no amount of scrums, scrum of scrums, agile coaches, etc. is going to make a difference.

View what you are doing as a team in light of these principles and see if it doesn't give you a fresh perspective on acting like a startup.

If you like this article, you might want to check out my Anti-Patterns for LeanUX presentation.

The Who, What, How of Satisfaction for Frontend Engineers

This is an over-simplified view. But I was thinking about what really matters to frontend engineers in their jobs (besides money).

It matters who they work with

• They want to be challenged by people smarter than themselves.
• They want to work for someone who gets it and values what they do.

It matters what they work on with who they work with

• The experience must matter. It must not be an afterthought.
• The technology stack must be industry standard and make development fast.
• The work must be relevant to our customers.

It matters how they work on what they work on with who they work with

• They want to partner early & often with product & design.
• They want to work in a lean, collaborative environment.
• They want to have customer feedback integrated throughout the lifecycle.
• Some parts of their work must be given back to the open source community.
• They must be valued for the unique contribution they make.
• They must be able to grow in their job to reach new heights.

What do you think?

Forming a new Accessibility Team at PayPal -- Welcome Victor Tsaran & Srinivasu Chakravarthula!

I am excited to share that we are formalizing the already ongoing effort at PayPal in Accessibility by forming an official Accessibility team.

And to kick things off right, I am thrilled to announce that Victor Tsaran will be joining PayPal on Monday 9/10 to lead this team. Many of you know that for the past 7+ years Victor has been the face of Accessibility at Yahoo (along with the excellent Alan Brightman) And if you were reading my blog back in 2005 you will also know that I wrote a piece about Victor's impact on my views about accessibility. I was just 2 months into my career at Yahoo! Here is a snippet from that article:

Confession

Ok, I'll start with a confession.

I think accessibility issues have always been an abstract concept to me.

It usually was an afterthought, something that the usability folks dinged us for. You know the text wasn't dark enough or the font was too small. It seemed to me that every experience I had with accessibility was from the negative perspective.

You see, I love rich interfaces. I love visualizations. I enjoy pushing the envelope. Somehow in my mind I just saw accessibility and richness as mutually exclusive.

Conversion

This all changed over the last two weeks. It happened almost the first time I met Victor Tsaran, Yahoo!'s Accessibility Evangelist/Manager. Victor is an incredibly bright engineer who happens to be non-sighted. If ever there was an evangelist and champion for accessibility, Victor is the man.

Victor does not come at accessibility from the negative aspect. Not at all. He approaches it with an enthusiasm, a sense of humor, and a challenge to create rich interfaces that are richly accessible.

My thinking hasn't changed. That's why when I started thinking about forming this team there was only one person in my mind -- Victor.

Here is a great intro to Victor and his work at Yahoo!



In addition, I want to call out an equally incredible hire by our QA team in Chennai, India -- Srinivasu Chakravarthula. Vasu was the Senior Manager, Inclusive Design at Yahoo! Bangalore. Vasu is well known in the industry (like Victor). You can follow Vasu on twitter @vasutweets.

We are stoked to have these two great advocates for accessibility on the PayPal team. We look forward to bringing Inclusive Design to the fore on all of PayPal's products & services.

They will join together with the excellent work that Cathy O'Connor, Dennis Lembree and Nawaz Khan have been doing to bring accessibility to the fore at PayPal to form this multi-disciplinary team (design, engineering & QA).

Welcome Victor & Vasu!