Web Directions 2014 – day 1

This week I’m attending Web Directions South 2014, a conference for people who “design, imagine, create or build digital products, web sites and applications”. I’m excited to be part of this event. I’ll blog about my take-aways from the sessions I attend, and anything else that comes to mind.

Day one started with an excellent keynote by Matt Webb. Now for some notes from other sessions I attended.

Lean Engineering, by Bill Scott

Bill Scott is the VP Engineering, Merchant | Retail | Online Payments at PayPal. His talk was about his journey from Netflix to PayPal, and how to make engineering a full lean UX partner. The concept is for the design team and the engineering team to work closely together, in tandem. Build, measure, and learn. Here are some snippets that I jotted down from this talk.

Any technology you use should be “Googlable”. When you hit a problem or want to learn something, you should be able to search for and find the solution.

When you want to make a change or pursue something innovative, decision turn around must be fast, so that you can “build, measure, and learn”.

Prototype in real time, with engineer and designer working alongside. Do sketches on a whiteboard and take them to regular design meetings, such as once a week. Make sure prototyping is enabled in the engineering stack. Your technology choices must reflect this methodology. Not everything that’s built has to be delivered to the customer. Bill talked us through the bits of tech that he and the team implemented at PayPal.

Create an engineering organisation that is partner to learning, and that encourages failure. Etsy does this well. Shift from celebration of delivery to celebration of failure and learning. Provide the framework that makes this happen.

Make delivery a non-event. A good way to do this is with continuous integration. Deliver all the time.

Engineer for volatility and throwaway-ability. Things will change. Design for that. Think of the UI as the experimentation layer. Choose a technology that allows you to control the experience and learn from it. Bill talked about choosing HTML 5 at Netflix for this reason.

Democratise innovation. Bill gave GitHub as a shining example here. Keep your teams small. Two pizzas should feed a team. Use a repo that democratises the code – no-one owns it. Get involved in and learn from external open source communities, such as in the JavaScript world. Use an open source model internally.

Bill sees the Lean methodology as a way of putting the customer into the Agile equation. Giving Agile a brain, where the brain is the user.

Unpacking technical decisions, by Sarah Mei

Sarah Mei is Chief Consultant at DevMynd. Her session was about finding out how we make technical decisions, with a mind to getting better at programming. How do people make decisions about code?

One of the biggest questions in webapp development today is, which JavaScript framework should I be using? There are so many choices. In the backend world, the question is: which datastore should I use? There’s a lot of information out there, but no easy way to make a decision. Making the wrong decision can have bad to disastrous consequences. What’s more, if you’re using an outdated technology you can be dragged to a standstill, yet changing to a new stack is expensive especially in training your team.

This type of decision is one we don’t make very often. So it’s hard to learn from previous decisions. One thing we can do is analyse the way we make other technical decisions, and then apply that process to the bigger ones. For example, you might ask an engineer, “Why did you name a variable as you did?” The answer might be, “experience”, or “it feels more natural”. That’s not useful data. So Sarah wanted to analyse the data that goes into these decisions.

Sarah considered an example of a decision between two pieces of code to be included in a project. One thing you may do is search the Web for information about the libraries involved, and read the READMEs. But those don’t give enough information. Sarah asked people what else they do. They look at recency and completeness of the docs, GitHub, StackOverflow, what people think of the maintainer of the library, what are people saying on forums… and so on. The way we collect and use this data is complicated. And most of the information is social rather than technical. One outlier was code analysis – how familiar does the code feel, how comfortable am I with it – you can summarise this by asking, how accessible is it.

Sarah took us through a four-quadrant analysis of the above findings. The quadrant had these poles: internal, external, project, people. She then had a go at applying the quadrant to a more complex problem: Deciding which JavaScript library to use.

We looked in particular at the code familiarity (accessibility) aspect to decide between AngularJS, Ember and Backbone. Accessibility falls into the internal/people section of Sarah’s quadrant. The feeling of accessibility depends on either what you’ve used before (such as Java) or what type of projects you’ve worked on. Everyone who develops a framework bases the design on their own bias. This is why a particular framework may or may not feel right for you.

Then you need to decide which of the quadrants is most important for you and your project. Is your team ready to move on to something new, or will they be better working on something similar to what they’ve used before? This will help you decide, for example, whether accessibility is an important factor for you.

An Internet for humans, too, by Dan Hon

Dan Hon is Content Director at Code for America. His role is making digital government easy to understand and easy to copy.

Looking back at the previous sessions of the day, Dan promised to break the pattern by adding some dissent to the mix.

Some of the best brand design is working out the emotional contact you want to make, and then making it. He showed us an add which he affectionately called “weaponised emotion”.

Dan is excited about the future, but also angry about the present. Over the last 40 years, computing and communication technology has become cheaper and faster. Now we’re talking about the Internet of Things. But at the same time, there’s a shift in the way Silicon Valley is developing technology and governments are legislating it. We’ve lost the human factor.

We should be building an Internet for humans. Dan is worried there’s a gap between how we build services and how they’re used. We need to understand this gap. It comes down to the need for an organisation to understand its audience. We need to empathise with what people are going through, and then use technology to make things better. In a possible dystopian future, inflexible software breaks the world. An example would be a car that refuses to start if you’re not up to date with your payments. What if you really need the car at this moment, to take a sick child to the doctor?

Dan discussed some recent technology products. This was a humorous and fairly ruthless look at current innovations. Some of them don’t “feel” quite right. Others don’t handle data well, in that they show data but don’t necessarily tell us what it means or what we should do with it.

Dan says it isn’t hard to design for people. It’s just a matter of empathising. It’s not new, and doesn’t rely on new technology. Dan gave some examples of good practice, such as Dropbox and Zappos for great customer service. Dan also thinks the UK’s Digital Government Services is providing great customer service as well as saving money. It turns out that when you do things properly, it saves money.

The future we wanted to grow up in, is where things work. To make that happen, we have to care about it and take the time to do things right. We need to do the user research. The more time designers and product owners spend with end users, the better the products get.

About the rest of day 1

I attended a few more sessions today, but haven’t blogged about them – chiefly because they were just before my own session so I was totally stressed out.🙂

The opportunities to meet people and chat with old friends at Web Directions are great. We had morning tea, lunch, afternoon tea, and an opening party in the evening. The food was yummy and the people were awesome. I met a bunch of ex-colleagues from Atlassian. And tonight I’m attending the speakers’ dinner.