Lean Front-End Engineering

Bill discusses what he looks for in a front-end engineer and lays out the schedule for the course.

All developers have their own experiences and bring a unique approach toward UX and front-end engineering. Bill describes his journey from his development work in the 1980’s all the way to today. Along the way he learned how to add efficiencies into teams of all sizes. What can we learn from PayPal? Difficulties arise when a company has a culture of a long shelf life.

In a typical organization, walls exist between the product/business team, design team, and engineering team. The product team consists of product managers and business analysts. The design team is typically includes UED, UX, ID, IA, VizDe, content and designer talent. Engineering teams are often front-end and user interface engineers along with web developers. After deadlines are met, these teams typically disband and form new teams on new projects.

A large portion of this course discusses “lean UX”. A lean UX will break down the walls between teams and allow for a more collaborative approach. At Netflix, Bill had a few people possible on each team. The culture was to higher smart, get products out the door as fast as possible and don’t overthink it. At Netflix, 90% or more of UI code was thrown away each year. It doesn’t take much A/B testing to result in a lot of thrown away code. Inuit learned a similar lesson.

Design for volatility. Planning for change can help with code reuse. Developers have to be able to build, test, and learn. Software is always tearing itself apart. Recognize that different layers change at different velocities. Start with experience versus components. Build in rapid experimentation. The UI layer is an experimentation layer. Early rapid prototyping leads to learning.

Q & A discussion around the topics discussed in Part 1. Questions asked by the audience include: - What are your thoughts on prototyping with pen and paper versus HTML? - At Netflix, how did you do usability testing? - What are your thoughts on documentation? - How do you deal with stakeholders’ fear of change? - What advice would you give to someone trying to introduce A/B testing?

Lean UX stems from the manufacturing revolution in Japan. It’s the ideal of shrinking batch sizes and the acceleration of cycle times. The book, The Lean Startup, looks at developing experimentation systems that allow teams to move at the speed of these systems instead of the speed of “Caesar giving a thumb’s up or down”. Being lean means defining your minimum viable product and building it in small batches.

Lean UX helps address the issues with the current UX process. Focusing on deliverables instead of experience results in waste. Even in agile development environments, design is often omitted from the process. A look at lean UX at PayPal.

Shared Understanding – The more understanding the less documentation. Deep Collaboration – Having a strong belief that ideas come from many different voices. Continuous Customer Feedback – This is the lifeblood of the team because it elimitates politics and turns a team outside-in.

Members from each team participate in all phases of the product life cycle starting from discovery and finishing with delivery. This process can still be agile, but unlike a pure agile approach, lean UX focuses on a build/test/learn cycle.

Lean is not necessarily agile. Agile focuses on engineering delivery while lean focuses on learning. See the workshops PDF for more information on agile vs. lean. Co-locate if at all possible. Deeper collaboration and time with the customer increases feedback. Github adds a slight counterpoint but proves cooperation without coordination can work Create a team working agreement and sprint faster so you can deliver to customers as often as possible. Also, sketch to code. Make the spec real. There are many prototyping tools available to create a living spec.

Spotify has adopted many of the lean UX ideas. Spotify uses squads which are similar to a scrum team, but feel more like a lean startup. Tribes are a collection of squads that work in a related area. Chapters and guilds represent horizontal practices within or across tribes. - The Lean UX Advocate: http://www.jeffgothelf.com/blog - Lean UX article: http://uxdesign.smashing.com/2011/03/07/lean-ux-getting-out-of-the-deliverables-business/ - Principle of Shared Understanding: http://52weeksofux.com/post/2403607066/building-a-shared-understanding Q&A and wrap-up discussion about Part 2 - Bill shares some stories about usability testing.

Additional questions and discussions about the lean UX techniques discussed in Part 2 - What’s the best way to validate or quantify customer feedback? - What brought Netflix to the prominent position it owns today?

Bill begins with a brief overview of his journey through software development. He was building games in 1985. Developing a UI was very difficult. From 1985 through 2005 Bill did a lot of proprietary development. Then he moved into the open source world with frameworks like the Yahoo! Design patterns library and work with the YUI team.

PayPal is using technologies like Twitter Bootstrap and Backbone.js. Using an internal Github revolutionized their internal platform. Every developer is encouraged to experiment and generate repos.

A portable UI can be delivered continuously and run on either the client or server. Their lean UI stack is a combination of Node.js (for prototyping) and Sparta 2.3 (for production).

Implementing a portable UI across two different systems is the tricky part. Bill continues his PayPal example and describes how the two stacks were unified. A lean stack must be independent of the backend language and flexible enough to run on either the client or the server. It should be good at building websites as well as web applications.

The first thing to remember is prototypes are not one-size-fits-all. Paper prototypes or a white board might be the right answer. However HTML is also great for prototyping. Using frameworks like Twitter Bootstrap maintain the right fidelity and create a fast, good-looking UI. - List of prototyping tools: http://bit.ly/SfWygk Use Google Chrome for prototyping. Ask your users to do the same. Also, Node.js is great for application prototyping even if you aren’t using it for production.

JS templating because it makes all of your UI bits be based in JavaScript. This makes them portable to either the client or server and even deliverable by a CDN. CSS can be a powerful tool for prototyping. Keep your CSS clean, though. Consider using something like LESS or Sass. Bill suggests a number of other tools and techniques to make rapid prototyping easier and more effective.

Which is better: client side or server side? It depends. For a page-to-page interaction, server side is typically better. Client side is best for an app or single-page design. Twitter is a good example of this argument. The server-side or client-side argument also appears in discussions around application vs. page or native vs. web.

When creating an omni-channel experience, RWD is implemented with CSS media queries and made to adapt. The downside is the potential for too large a payload on devices. Mobile first does not mean designing for mobile device in isolation. A mobile first approach is designing for an ecosystem of form factors through the prism of mobile.

Questions asked during the Part 3 Q&A session: - Is your mock data hard-coded or pulled dynamically from somewhere? - How can you take a responsive server-side mentality when rebuilding a desktop application? - For responsive web application, are you including anything like jQuery Mobile?

Bill defines many different anti-patterns in lean UX and how to avoid them. You can avoid the Genius Designer by keeping their inspiration but focusing on your minimal viable product. With small teams, many members work across disciplines. Tribal Groups form as the team grows and tribes form around each discipline. It may be assumed that a Newcomer will automatically adapt but teams must be patient, answer questions and teach vocabulary to any new member. Recognize early if they are the right fit.

Team members can be Addicted to old/bad habits. New habits must be performed enough to ensure they are internalized. The Naysayer can kill collaboration. If someone is not on board with the process, they may not be a good fit. A Visitor can give crucial input during development. But watch out. A visitor can bring the same issues as a newcomer. Magic Tools allow for easy prototyping and ideation. They can, however, cause people to work in isolation and ruin collaboration.

If a developer, product manager, or designer Goes Dark for more than a day or two, collaboration can be crushed. Limit isolation to short periods of time. A Change in Cadence is good. However prepare your team for any rhythm changes to keep productivity loss to a minimum. If work is not divided properly, you may end up with Too Many Cooks in the kitchen. Be sure to have clear decision makers. Not Enough Pizza means the team is scaling faster that it can handle. Keep your team 2-pizza size.

Lean UX relies on shared understanding. The Tower of Babel arises when knowledge is assumed. Ask clarifying questions to make sure everyone is on the same page. If You’ve Got Mail, your team has reverted to email for collaboration. Keep the collaboration high-bandwidth. If engineers are driving design, then the Inmates are Running the Asylum. Make sure the front-end engineers are working with the product and design teams.

At trap easy for a designer to fall into is the Perfectionist. Iteration will help; so will a collaborative approach. A team will stumble on the Weakest Link. Talent acquisition is the key and a team must of the freedom to replace talent. The Wall between teams can happen. Smaller teams and collaboration keep the lines of communication open and the walls down. A messy tech stack becomes Tangled-up Technology. Keep the services and UI separate.

Bill wraps up his presentation and fields questions from the audience. - Steve Jobs was very combative in his approach. Can you contrast this mentality with lean UX? - How do you handle version control? How would you like to handle version control? - Do you have any tips for deployment?