Linnea Ann Williams's Blog Posts

This last week I attended the Habit Summit, a day-long conference here at Stanford where industry leaders in software and app development get together to talk frankly about how to make engaging customer experiences and get people hooked on their tools and games.

The amount of research and philosophy, buzz words and metaphors presented was very impressive. It was a fascinating (and sometimes scary) glimpse into the enterprise and start up world. This post outlines some of the ideas and trends that I witnessed.

Interesting Models and Psychological Research

Nir Eyal and "Hooked"

Nir Eyal opened the day with a quick overview of his Hooked model. According to Nir Eyal we can get people "hooked" by ensuring that we are monopolizing on internal and external "triggers" (emails, desires, emotions, tweets, etc) by giving people "actions" to take (tasks, links, calls to action) which create "rewards" (likes, reposts, mastery, competency, resources) that lead into future "investments" to loop them in and reload the next trigger (storing value or content, building followers, pinging someone else so that they respond) Check out this image of the hooked model to get a better idea of how this all works. Nir wrote the book Hooked: how to build habit forming products that outlines the ideas above in great detail. He was also the MC for the day. 

Kintan Brahmbhatt of Amazon and "Friction"

Kintan Brahmbhatt, the Head of Products for Amazon Prime spoke about reducing "friction" in user experiences by discovering where people are struggling and how to smooth those places out to make better experiences. He described friction as anything that comes in the way of a user's ability to achieve his/her objective. When a new user has a new toy (your app or tool) and things are going well, they're delighted, which is always the goal, BUT delight + friction = disappointment. For instance, a new toy (delight) + no batteries (friction) = disappointment.

The three types of friction he called out were:

1. avoidable effort needed to complete a task
2. unnatural context switching
3. count and complexity of decisions

Minimizing these will maximize people's satisfaction with your product and decrease the likelihood that any habitual use will ever be broken, meaning they won't switch to a competitor. Kintan emphasized that discovering and prioritizing which fiction points to resolve is the hardest part.

Natalie Nahai and Psychological Principles

The very fast talking Natalie Nahai, covered a series of psychological principles that could be used to override people's conscious thought and build habits or product addiction. It was slightly terrifying and very impressive to hear her discuss all of the consumer psychology standards that have been developed over the years and how to apply them to the web. Her book Webs of Influence comes highly recommended.

Here are a few examples of principles that she outlined:

1. Endowed Progress If something looks partially completed at the outset, the chance of completing it is twice as high. For example, a buy 8 and get one free card works twice as well if it's a buy 10 and get one free with two already punched.
2. Sunk Cost Fallacy We will stick with something if we've already invested in it, even if it's not in our best interest. For example, I'll keep playing this game because my player is so high level, I've put a ton of time into it.
3.  Opportunity Cost We'll trade money for things like time if the cost of waiting is high enough. This is a case where "fun pain" comes in; people playing a game that requires waiting (like training troops in Clash of Clans) will pay to get rid of their fun pain and make the troops train faster. And a great way to remove the pain of purchasing even further is to introduce an intermediate currency.

At the end of this session, a woman asked, "How do we prevent children from becoming addicted via these subconscious patterns?" And the answer was, "You can't!" Learning about these principles doesn't make them not work on you. The best way to keep kids (and yourself) safe from games like Angry Birds is to limit screen time and focus on what the game or app is getting from you, so that you're conscious of the corporate will behind the principles. I've decided I'm going to give myself more slack for being addicted to Clash of Clans.

Know Your Users

User-Centered Design

There were a few of great presentations on user-centered design and user research featuring design and research leads from Twitter (Ximena Vengoechea) and Instagram (Bo Ren). These presentations emphasized starting with research before ever building anything. Asking questions like:

• What are we changing?
• What is our goal?
• How do people feel when they open my app?
• When do people use this tool?
• What does my user's happiness depend upon?
• Where is my user coming from? What in their life experience is most relevant to my product?

In particular, I appreciated that these two focused on the potential positive impact of their work. Bo Ren said, "Good products aren't just delightful, they help you take action toward a goal." As someone who isn't a heavy app user, I was glad that there was more emphasis in their presentations on thinking about people in a positive way by solving a problem they have, rather than just getting them hooked.

Neuromarketing

Roger Dooling presented on all of the wild technologies out there that power companies are using to test the physical and neurological responses of their consumers. He emphasized the fact that 5% of our decision making is conscious, so asking users what they think is not that meaningful. A few processes he called out were fMRI, eye tracking, facial coding, and EEG. At this point, the research is just starting to come in on whether or not these tools can be used as indicators of potential purchases, with fMRI being the best indicator at this point. Today these sorts of studies are very expensive, but with the advent of wearables like the Apple Watch, it may become easier and easier to study people's unconscious responses to your products.

My takeaways

I have to admit that going in I had hoped there would be a little more self-awareness in the community: questions of ethics, presentations on positive habit formation, not just a focus on addictive habit formation, but it was extremely interesting despite that. And there were a few examples of people using these techniques for things like reducing energy consumption. Let's do more of that and get these concepts into the non-profit world! "We planted two trees for you, plant eight more and get a tree hugger t-shirt" That one needs work, but you know what I mean.

I'd also like to further explore how we can use these sorts of tools and principles to relieve friction in the workplace using tools that allow people to come to their work with the unconsciousness that they open their favorite app. Companies like Slack are working in that sphere these days, which is pretty great.

Agile has become a big buzz word recently in the project management world. In this post, I'll try to clarify where some of the lines are being blurred between terms like Agile and Scrum, and what some of these terms actually mean.

Keep in mind while reading this that I am primarly trained in Scrum, so my descriptions of other Agile methodologies are only decently informed. :)

What is Agile Project Management?

From the ever-present wikipedia:

Agile project management is an iterative and incremental method of managing the design and build activities for engineering, information technology, and new product or service development projects in a highly flexible and interactive manner, for example agile software development.

The primary words to take into account here are iterative, incremental, highly flexible, and interactive.

Unlike traditional Waterfall approaches to project management, Agile seeks to build products from the perspective that not all requirements can be fully scoped at the beginning of a project, no matter how fastidious the discovery and documentation. And that better products come from being tested and revised while they're being built.

With Agile, we don't make a plan and follow it to the letter from start to finish; we allow the products we're building to morph into better products along the way.

The Agile Manifesto

The first step towards figuring out Agile software development is to become familiar with the Agile Manifesto. It was written in 2001 by a group of PMs and developers who were successfully experimenting with Agile approaches. Their successes lay in a few primary tenets:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Each type of Agile methodology, whether Scrum, LeanUX,or Kanban addresses these primary tenets in slightly different ways, but they should always remain core to an Agile strategy.

You can learn more about the Agile Manifesto at: http://agilemanifesto.org.

What are some examples of Agile methodologies?

Scrum

Scrum is a system rooted in regular cycles of work called Sprints. Each Sprint has a fixed length of time, a set group of meetings (including the daily scrum, from which this methodology derives its name), and a defined set of work that the team has agreed upon. The work for each Sprint is taken from the top of a carefully prioritized Backlog of features to develop, which provides the majority of the documentation for the project in bite-sized chunks. Work is released early and often and revised as needed. For more about Scrum, you can watch my recent presentation on the basics of Scrum.

Watch my presentation on how Scrum works (there are some small audio glitches)
Read a detailed description of Scrum on Wikipedia

Kanban

Like Scrum, Kanban for software development is based on working from a prioritized Backlog. Unlike Scrum, which sets predefined cycles in which small subsets of the work will be completed (Sprints), Kanban prevents team/process overload by limiting the number of items that can be worked at concurrently. Kanban keeps a constant flow of work in motion, ensuring that everyone is allocated just the right amount of work at any given time. This is called limiting Work in Progress or limiting WIP. Kanban also focuses on process and product iteration with structured feedback loops.

Learn more about Kanban on Wikipedia

Lean software development

While Scrum comes with a lot of very specific team members, meetings, and mapping workflows, Lean is more of a group of principles and tools for building your own processes. These tools and tenants were derived out of manufacturing approaches developed by Toyota. Lean development can be summarized by seven principles:

1. Eliminate waste: Any wasted time, unnecessary steps, manual testing, unused code, etc should be eliminated.
2. Amplify learning: Speed up cycles and feedback loops by using automated testing, user testing, etc.
3. Decide as late as possible: The further along you are in a project, the more you know. So decide later, when you know more.
4. Deliver as fast as possible: The sooner you've delivered something, the sooner you can get real feedback into making it better.
5. Empower the team: Find good people and let them do their job.
6. Build integrity in: Make sure the code is clean, and everyone feels good about it, from developer to client.
7. See the whole: Carefully define relationships between collaborating teams, and different software components

Learn more about Lean development on Wikipedia

Extreme Programming

Extreme programming (XP) is rooted in frequent releases and short development cycles, interspersed with opportunities to adopt new customer requirements. The idea is to take the healthy aspects of software development and taking them to the extreme!

Some features of Extreme Programming include:

• programming in pairs or doing extensive code review
• unit testing of all code
• avoiding programming of features until they are actually needed
• a flat management structure
• simplicity and clarity in code
• expecting changes in the customer's requirements as time passes and the problem is better understood

Learn more about Extreme Programming on Wikipedia

Scrum, one Agile approach

There are lots of different methodologies (certainly more than I've listed here) that are considered a part of the Agile family and each addresses the Agile Manifesto in slightly different ways. Scrum is just one type of Agile software development in suite of many. I hope that helped to clarify things for folks.

And keep in mind: because the world is a complex and messy place, many of these methods get adopted in part and mixed and matched. Our team currently alternates between Scrum and something resembling Kanban.

What are you currently using and how is it working for you?

Imagine you're an academic department or program and you're starting on a project to revamp your web presence. The first thing you'll need to do is figure out who should be on your internal web team that will see the project from inception to launch. This might be some combination of your staff, faculty, and students. But who exactly?

Choosing the right web team is really important to the success of your project. To reach your launch in a timely fashion, you'll want detail-oriented and tech-savvy folks to get things moving and collaborate with your web developers, and regular check-ins with stakeholders to make sure you're aligned with their vision.

Stakeholders vs. web team

There are two primary groups of people that you need to keep in mind when embarking on a web project: stakeholders and your web team. Stakeholders are the primary people who will be viewing, represented by and/or effected by your new website. Your web team is the group of people in your program or department who will work hard to complete your project.

It's easy to accidentally conflate these two groups and think that your stakeholders are who should be on your web team. I've heard, "We are guaranteeing that everyone is involved so that no one can be unhappy at the end of our project!" But I'd like to assert that doing so can compromise the success of your project, especially once it's time to get to work.

Stakeholder goals

• The site does everything I need and want it to.
• I like how my pages look.
• The general look and feel of the site represents us well.
• We are sufficiently on budget.

Web team goals

• All content has been ported and is consistently worded and formatted.
• Images are well chosen and properly formatted.
• The site looks good.
• The site has sufficient functionality for this phase of the project.
• There are no broken links anywhere in the content.
• Everything is tagged correctly, if relevant.
• We are on budget and focusing on highest priorities to maximize value.
• Stakeholders are happy with the end result.

As you can see, though there is some overlap between the goals of the two groups (the site looks good), they aren't aligned. Stakeholders are often more interested in making and prioritizing requests for functionality in a website. Whereas, the web team is primarily interested in getting the site to a successful and timely launch, and willing to do the work to make it happen. Both groups are critical to the success of a project, but each should be asked to do tasks that are aligned with their goals, to keep things moving forward smoothly.

Stakeholders in a web team-led project

Stakeholders should always be involved in the major decision-making for a project because they need to be really satisfied with the site after launch. However, stakeholders often aren't interested in the hard work piece of putting a site together, such as:

Web team tasks

• Quickly learning new technologies
• Regular meetings with web development team (often these happen weekly or even twice a week during peak development)
• Reviewing and revising existing site content
• Collecting, cropping, and uploading images
• Copying and pasting old profile information
• Gathering quotes, news articles, publications, etc.
• Creating categories for events, news, people, etc.
• Tagging imported content
• Checking every link on the site to make sure it isn't broken
• Communicating requirements and bugs to web development team

If stakeholders aren't the right people for the tasks above, how can you keep you keep them involved so that you deliver a site at the end of your project that is well-received? There are lots of great ways!

Stakeholder involvement

• Engage in stakeholder discovery to uncover website functionality requirements/needs before the project kickoff. This may take the form of a couple group meetings or individual "interviews" with your stakeholders.
  • What are stakeholder expectations for the project?
  • How would they define a successful outcome?
• Regular check-ins, especially at key junctures, which might include:
  • Short presentations at monthly faculty meetings
  • Welcoming direct feedback on design comps or wireframes at sign-off stage for these deliverables
  • Inviting feedback a few weeks to a month before launch, especially in regards to content and wording
  • Requesting feedback after the site has been live for a few months, to help you plan for future improvements

If you've been on a project, you've had to think about stakeholder involvement. How do you keep your stakeholders involved? Feel free to leave a comment below!

Earlier this year, I wrote a blog post about using Menu Block module. In this post, I'll talk about how Menu Block integrates with Stanford's Drupal 7 themes to create dropdown menus.

To properly leverage the dropdowns in Twitter Bootstrap with Drupal, there are a few things to keep in mind...

Note: This post pertains to these Drupal 7 themes:

• Open Framework
• Stanford Framework
• Stanford Wilbur
• Stanford Jordan

Menu Block module to wrangle dropdowns

If you've been following the Menu Tricks blog series, you'll know that I'm a supporter of placing all menu items into one giant menu, which sets you up to have a dropdown menus (and many other great things that you can see in the Menu Tricks series), but puts you in the position of having additional pop-ups for items that are three levels down in your menu or more.

Here at SWS, we think that in most cases dropdowns should only ever display one additional level of menu items. Otherwise you risk what I like to call Navigation Overload: things like flyouts, with which even the handiest mousers struggle.

To constrain your menu items to just the top navigation and a single-level dropdown, you can use Menu Block module. Here are the settings your Menu Block will require:

• Use the Main Menu to build the block
• Start at the primary level in the menu
• Make the maximum depth 2
• Place this new menu block into your Navigation region

Configuring menu items to expose dropdowns

There is an additional step required to make your dropdowns work. Dropdowns use javascript to hide the sub-items in your menu until someone clicks on the top level item, which means that those items need to be expanded in the code at all times. Otherwise the dropdowns won't know that there are any items to display.  

To expand all of your top level items to make those links available to the dropdowns:

• navigate to your Main Menu list of links (/admin/structure/menu/manage/main-menu).
• Edit each of your top level menu items
• Check Show as Expanded

Dropdowns on click, not on hover: Top-level items are no longer pages

Historically, it's been very common to see dropdowns on hover, meaning that the menus expand when a mouse hovers over the top-level menu item. However, because it's very common for people to visit a website on a mobile device or tablet, it's becoming standard for dropdowns to open when someone clicks (or taps) on the top-level menu item. Dropdowns on click/tap is how the Stanford Drupal themes have been configured.

The primary ramification of dropdowns on click is that top level items are no longer pages. There are various ways you can work around having top-level items be links only and not navigable pages. The way Web Services is now configuring our websites that use dropdowns is thus:

Blank pages that redirect to the first subpage

Because Web Services likes to use pages to automatically build our URLs, we like to build pages for our top level items and then redirect them using the Redirect module to the first page in the second level of the menu. You can see that in action at undergrad.stanford.edu.

If you have other ways you've worked around top level items being links not pages, feel free to leave a comment about your approach!