“Simplicity is not the goal of Lean UX Branding. It is the by-product of a good idea, modest expectations, iterative executions and ruthless cutting.”—Will Evans & Thomas Wendt, Lean UX Branding
“Lean is about being an athlete, not a skeleton.”—Unknown
We don’t have a logo.
I recently received an email from one of the organizers of LAUNCH Festival 2013 in San Francisco. If you haven’t heard, LAUNCH was where Dropbox and other notable startups have made their debuts and subsequently secured funding from investors. The LAUNCH organizers proposed a generous offer to Lean UX SF: 50 free LAUNCH tickets for community members. All we had to do was help promote the festival. They also asked us for a logo so they could in-turn promote our community’s participation in the festival. Problem: We didn’t have a logo.
Tap the community.
We also don’t have a budget. But we do have community. Within community an ecosystem of innovation thrives. Through inquiring the community about a logo, we were able to discover elements about our identity. We applied a classic technique from Lean thinking, mathematics, psychology, and the arts called “fully exploring the potential space”. I quickly sent a message out to the Lean UX SF mailing list:
Subject: Logo Contest!
p.s. No parameters or constraints.
That last part “no parameters or constraints” was not lackadaisical, it was quite intentional. In order to “fully explore the potential space” we had to leave the door open for the Lean UX SF community to explore their identity rather than the organizers exerting their own vision and assumptions. In other words, we were operating in the absence of a clear hypothesis about what a Lean UX SF logo might look like. Rather, we operated under a different hypothesis altogether: The community will guide us toward the best logo.
Modest expectations, iterative improvement, and ruthless cutting.
The email went out to over 1,500 members. About 20 submitted logos. A few people submitted multiple ideas. The more the better. Within a couple of days we had over 25 logo submissions to explore and (unfortunately) 24 options to “ruthlessly cut”. It was easy to see a wide range of symbolism and metaphor expressed in all of the ideas, and each one represented a potential expression of the community’s identity. I expressed gratitude and provided feedback to each person who submitted a logo, and the diversity in ideas exceeded my wildest expectations. Each person’s willingness to iterate based on constructive feedback reflected the maturity and professionalism of the community.
We don’t have a budget for branding. The LAUNCH festival date was fast approaching. Two factors drove the initial selection process: Execution and Appropriateness. The execution mattered—a lot—because good execution would mean fewer iterations to discover the final logo, which would have to look polished: Being “Lean” doesn’t mean we’re perpetually stuck in sketch mode.
Appropriateness mattered a lot too. While Lean UX might be described by some as a process, that’s not entirely true. The logo would ultimately serve as a signature for a community based on a shared set of values, not a prescriptive or one-size-fits-all process. Also, the logo had to be versatile: it could one day be placed on websites, placards, t-shirts, frisbees, hoodies, etc.
We put it to a vote. The results were too close to call. We put it to a “final” vote, still too close to call. It started to seem like voting served more as a vehicle for conversation about the ideas rather than making a decision. We decided to hold an “electoral vote” (gasp!). I asked my most trusted design critics to choose for us from a set of four finalists. Finally, with a tie-breaker vote by a smaller group of people there was a clear winner.
And the winner is…
The winning logo design was created by Zac Halbert, a recent transplant to the SF Bay Area and Lean UXer. When Zac submitted the idea he said:
“My thinking is that this is a clean look that is representative of a bay area design sensibility, reminiscent of larger organizations like the fire department. A field as new as ours can always use a little bit of borrowed credibility.”
Other than just “liking” it, we also felt that it fits within the criteria of every good logo:
It’s a circle enclosing one of the most recognizable landmarks in North America, The Golden Gate Bridge.
A clever integration of the letters UX and the bridge might cause a person to pause, look, and inspect it: thus imprinting the logo into their memory (cue evil laughter).
Zac’s inspirations for the logo (a stalwart organization such as the SFFD, and the resilient Golden Gate Bridge) plus his typographical choices build “timeless”-ness directly into the DNA of the logo.
The logo can be printed in one color, it is vector-based, and it can also be printed or displayed in reverse—light foreground, dark background—hoodies, frisbees, placards, etc.
Again, Zac’s inspiration came from larger, more “credible” organizations. Lean UX SF is a community organized by UX practitioners and Lean enthusiasts. Zac’s concept echoes the sense of belonging and camaraderie our community nurtures.
Check out some of the other fine logo designs here:
Lean UX SF Logo Ideas – Finals
Come to a meetup!
Through the pursuit of experimenting with real-time digital collaboration, I’ve been exploring server-sent events (SSE) with a Ruby web development DSL called Sinatra, backed by a lightweight web server called Thin. Check out a live demo at sinatra-drinks-coffee.herokuapp.com (open it in multiple browser windows to see the full effect). Then, explore the code on github. It’s very straight-forward, but feel free to ask questions in the comments.
People are more likely to stay engaged in digital collaboration if they can observe each other’s actions in real-time. In order for people to observe each other’s actions, objects and their states must rapidly synchronize across all connected and authorized clients. This need has traditionally been a complicated problem given that the internet is stateless. The internet protocol (IP) was designed to treat data as independent pairs of requests and responses; not as continuous bi-directional streams. However, the perception of persistent connections between servers and clients are necessary for real-time collaboration.
Even more fun than twisting the original architecture of the internet is the need for reconciling conflicts that arise when more than one person changes a document’s state. If you have ever used Google Docs, you have used a web service that supports real-time collaboration using operational transformation control (integration) algorithms.
In spite of the challenges and limitations of real-time collaboration, I anticipate that people will expect these tools to support an ever-expanding range of activities in the next few years. Especially in engineering, design and architecture.
Here’s a good explanation of how Google reconciles conflicts in Google Docs:
Server-Sent Events Vs. Web Sockets
On November 9, 2012 I dreamt I was designing with the aid of artificial intelligence (AI). In this dream my hands and arms were deep inside two large, translucent, and blue extensions of my body. Through these large virtual gloves I could manipulate an equally large, translucent, and blue object. The object was shaped like a torus and within it were several concentric rings. As my hands guided the general manipulations and sculpting of the object, the computer’s AI handled the more delicate operations. Utilizing dozens of kinematic armatures extending from my large virtual arms, the AI manipulated numerous intricate facets protruding from all across the object’s broad animate surfaces.
As the computer and I worked together in this sort of symbiotic waltz, a far off voice uttered the name “Kerzwyle”. At this moment I woke up. I immediately searched for the name “Kerzwyle” on the internet. The search engine recommended Raymond Kurzweil, author of “The Singularity is Near: When Humans Transcend Biology” and inventor of text-to-speech technology. I had no recollection of hearing or seeing that name prior to my dream. I can only imagine I must have read something in the past that referenced the author and his book within some inconsequential context.
Even more perplexing and freaky than the dream: While I was looking to purchase “The Singularity” I discovered that his next book “How to Create a Mind: The Secret of Human Thought Revealed” was due to release in just a few days.
Have you ever had an experience like this? One where a subconscious dream leads you through a sequence of events in your waking, conscious life?
The purpose of the single user story gets lost in the flow of work
As most Agile and Kanban teams know, user stories can help teams collaborate around bite-sized chunks of work. The single, trackable user story allows teams to measure and sustain a constant flow of work. And yet, I have noticed that as teams become more proficient at establishing a flow, the usefulness of the user story as a way to communicate customer value diminishes severely.
As Jeff Patton says in The new user story is a backlog map:
Arranging user stories in the order you’ll build them doesn’t help me explain to others what the system does. Try handing your user story backlog to your stakeholders or users when they ask you the question “what does the system you’re building do?”
At the top of the [backlog] map are “big stories.” I call them user activities (borrowing the term from UX people like Larry Constantine and Don Norman). An activity is sort of a big thing that people do – something that has lots of steps, and doesn’t always have a precise workflow.
On my teams we have taken the idea of applying activity-centered design to the backlog and extended it to the entire product development cycle; end-to-end and continuously.
Activity maps help you track progress toward delivering customer value
Activity maps are a simple and lightweight artifact that help you track progress toward delivering customer value. Through the creation of an activity map, your team will create a precise and elegant lexicon that will sharpen your understanding about what you are trying accomplish.
Activity Map: Activity, actions, and operations
- Activity: The most basic unit of analysis defined as any collaborative, goal-directed, and purposeful human endeavor
- Actions: Activities consist of a chain of actions that represent an immediate, specific, and conscious human goal
- Operations: Actions consist of a chain of operations that are habitual, automatic, and routinized
Simple, repeatable, and useful
Intentionally simple, activity maps may be re-purposed easily in digital and physical form. In ThoughtWorks’ Mingle, activity maps can be set up in a matter of minutes. With added power from Mingle’s query language “MQL” you can easily track the progress of individual user stories in the context of their corresponding operations.
Activity, actions, and operations in ThoughtWorks’ Mingle
Tracking user story progress in the context of an operation using ThoughtWorks’ Mingle
Don’t make people do the grunt work
In activity theory, the operation is the smallest unit of analysis of an activity. Any analysis beyond the operational level will put you squarely in the realm of making people do grunt work, negating any intention of using technology to improve people’s lives.
My favorite example of how technology can remove menial work from our daily lives is the GPS feature found in Apple and Google’s map applications. When you want directions to a destination from your current location, you don’t have to know anything about your current location: No physical address. Nothing. It just works.
How do I get started making activity maps?
The best place to start is with your customers. Talk to as many as you can and as often as you can. It also helps to first understand your customer’s perspective through the lens of an activity system.
How do I know if I am doing it right?
It comes down to creating an elegant and precise language about the activity your product supports. For the activity, keep it high level yet meaningful. Remember, an activity is a purposeful human endeavor that is inherently social and outcome-focused.
Examples of activities:
- Following people and conversations (with Twitter)
- Keeping up with friends (with Facebook)
- Photo sharing (with Instagram)
For actions and operations, avoid using terms like manage, create, document, and user. Instead, combine meaningful verbs and nouns such as “get directions”, “invite friends”, and “take a picture”.
Do you want to make great products and services for your customers? You need to integrate design into your culture. Here are 10 principles to live by:
- There will never be enough professional, specialist designers
- Anyone can be a designer if their process is design
- Create design environments
- The object is the outcome
- Make design tacit
- Focus on solving problems from a people perspective with the knowledge that humans are innately social creatures
- Ask questions; don’t assign objectives
- Expect rework
- Generate many viable options and then converge at the last responsible moment
- Hire artists
Just about every conversation we have on ThoughtWork Studios teams revolve around two questions: “How might we encourage and enable team collaboration?” and “How might we enable teams to focus on customer value?” We also filter all of our decisions through a clear and precise language about the activity a product supports. These questions and the precise language about the activity add up to the single most important question: Who do we want our customers to become?
Henry Ford didn’t just facilitate “mass production;” he enabled the human capital of “driving.” George Eastman didn’t just create cheap new cameras and films; he created photographers. Sam Walton’s Walmart successfully deployed scale, satellites and supply chain superiority that turned shoppers into higher volume, one-stop everyday low-pricing customers. Steve Jobs didn’t merely “reinvent” personal computing and mobile telephony; he reinvented how people physically touched, stroked, bumped and talked with their technologies. Google’s core technology breakthrough may appear to be “search;” but the company’s algorithms and business model is contingent upon creating hundreds of millions of smart “searchers” worldwide.—Michael Schrage
So, I am asking you this question: Who do you want your customers to become?
“How often we neglect to address the purposes of those who are in the system and those of the environment.”—Béla Bánáthy
“No man is an island,
Entire of itself.
Each is a piece of the continent,
A part of the main.”—John Donne
Design for Activities, Not Individuals
Most products support activities underpinned by collaboration and sharing. Designing for individuals may actually be harmful because these activities reflect ongoing transformations of artifacts, individuals, and social interactions. Focusing on individuals might improve things for one person at the cost of others. As Donald Norman says in Human-Centered Design Considered Harmful:
The more something is tailored for the particular likes, dislikes, skills, and needs of a particular target population, the less likely it will be appropriate for others.
Activity-Centered Design (ACD) focuses on the activity context in which individuals interact with your product. Instead of analyzing specific goals and tasks, ACD focuses on the analysis of meaningful, goal-directed actions supported by tools and artifacts in a social world. The Wikipedia article about Activity Theory says:
The goal of Activity Theory is understanding the mental capabilities of a single individual. However, it rejects the isolated individuals as insufficient unit of analysis, analyzing the cultural and technical aspects of human actions.
Limitations of Personas
Persona documents have become the de facto design artifact for human-centered design. Personas are a proxy for a real customer when teams lack customer participation. Don’t get me wrong, I understand the value of personas as a way to build empathy for customers. A designer will typically create a persona document to bring a human perspective to the conversation. Sometimes, this is a callow reaction to a team overly focused on technical implementation. Most of the time, the persona document contains inert data. Through the process of modeling the ultimate customer, the persona becomes too general to represent any real-life customer.
Personas Increase Risk of Feature Bloat
Many companies boast about their human-centered approach to design and their use of personas, yet they still manage to design complicated products characterized by bloat, infrequent improvements, and a set of features that no single customer fully utilizes. A product team that bootstraps their design process by identifying several individual personas doom themselves to create a bloated product. Obliged to partition the solution across a set of features for each persona, this approach results in an incoherent product difficult for people to adopt and use in their daily lives.
I believe persona documents emerge for several common reasons:
- The customer is missing or does not actually exist
- A preference for analyzing personas through the myopia of roles, job titles, and demographics
- Unreasonable paranoia about engineers making decisions without empathy for customers
I am not saying that personas are “bad” and that we should ignore decades of progress in human-centered design thinking. On the contrary, I believe products which metastasize with limited focus on real human needs can improve with human-centered methods like persona documents.
Activity Systems: Participants and Activities
An activity system is a community of people interacting with each other through tools and artifacts in the social world. As Béla Bánáthy says in Characteristics of A Human Activity System:
Purpose, process, interaction, integration, and emergence are salient markers of understanding … we should think about and define human activity systems always at three levels: (1) A system serves the purpose of its collective entity. (2) It serves the purpose of its members. (3) It serves its environment of the larger system in which it is embedded.
The people in the system are affected by being in the system, and by their participation in the system they affect the system. People in the system select and carry out activities—individually and collectively—that will enable them to attain a collectively identified purpose.
The process by which these relationships are maintained is the system’s regulation—the rules of the game—and the limits within which these rules can be sustained are the conditions of the systems stability through time. It is here where commitment (to shared purpose) and motivation (to carry out activities) play such an important role.
People are affected by their participation in the activity system, and through their participation they affect the activity system.
Instead of analyzing individuals as personas, you can analyze from an activity perspective using a human activity diagram. I typically create a human activity diagram in collaboration with my team so we can quickly develop a shared understanding of the new activity context we are working in. The diagram’s simplicity makes it easy to share, redraw on a whiteboard, and easily transform as you learn more about the activity. Professor Yrjö Engeström from the University of Helsinki in Finland invented the human activity system diagram to facilitate his own research into organizational and workplace learning.
HUMAN ACTIVITY DIAGRAM
I recommend redrawing this diagram and filling it in with an activity context familiar to you. Then, try filling in another one with an activity context less familiar to you. Many questions will arrive in your head as you try to fill it in. Your questions will become hypotheses to validate by talking with people and immersing yourself in their activity context.
From left to right the eight categories are:
- Participants: Actors engaging in the activity
- Rules and Rituals: Conventions and guidelines regulating the activity
- Community: Social context shared by all participants engaging in the activity
- Activity: Any purposeful human endeavor
- Tools and Artifacts: The means for the accumulation and transmission of social knowledge in the activity
- Division of Labor: Social strata and hierarchical structure of the activity
- Objective: A shared goal obtained through the interaction between participants, tools, and artifacts within the context of the activity
- Outcomes: The participant’s motivations for obtaining the objective
CASUAL CARPOOL – HUMAN ACTIVITY DIAGRAM
As a resident of Berkeley and an employee at a company based in the financial district of San Francisco, I am very familiar with the activity of casual carpool. As a new casual carpooler, I started brainstorming ideas for a product to solve two problems I observed: A long queue of passengers, and a long queue of drivers at peak times (from 8 – 9:00 AM). I assumed an imbalance in either queue was an indication of impeded flow: A problem to fix. I immediately envisioned app ideas that I was certain no one would willingly adopt; certainly not in the morning and not when they’re in a hurry to get to work.
Instead of wasting my time throwing a solution at the problem, I opted to improve my understanding of the activity by looking at the casual carpool as an activity system. As I observed the rules and rituals of casual carpooling and the behavior patterns that the participants displayed, I realized that the queues actually worked fine. Any imbalance between the flow of the passenger queue and the driver queue were fleeting; average wait times were well under 10 minutes.
By analyzing the whole system, rather than individuals, I came to the realization that the objective for drivers and passengers to carpool with minimal coordination was already happening. In the casual carpool pickup spots rituals and norms naturally emerge with readily available tools and artifacts. Namely, vehicles and queues. What about other issues like lost-and-found items? The system has already compensated: If someone forgets to take a purse or a phone when they get out of a vehicle, the driver can simply post “found” signs at the head of the passenger queue. Any other solution I can think of would require another layer of coordination between drivers and passengers.
Casual Carpool represents an emergent system influenced by external forces such as state laws and our disdain for congestion on roadways. Any solution in the form of a tool like an iPhone app or even a human agent like a “Carpool Coordinator” would undermine the overall objective of “carpool with minimal coordination”.
In the next example you will see how you can use a human activity diagram to generate an entirely new tool in an emerging activity system context.
What are we making?
At ThoughtWorks Studios I work with teams who create products used in software development environments. I often help these teams develop narratives that frame product decisions from a customer perspective. In order to develop these narratives, the depth of understanding of the human activity context must be deep, and the customer’s language common to the team.
One of these teams, Luau, provide a measurable way for customers to improve their software development processes through evidence-based experimentation. In the past, when I would ask the team “Why is your product important?” I got slightly different answers from each of them. The common term they would use was “cycle time”. Cycle time is the measure of the amount of time it takes for an idea to go from doing to done. The team was certain cycle time was important to their customers, and it was their job to make a tool to convince customers it was the right measure for process improvement.
The team had to figure out how they would present cycle time to their customers, and how their customers would define their workflows. The Luau team also had to figure out a solution which would integrate with their customer’s daily lives. To help them discover possible solutions I used Engeström’s human activity diagram. I introduced the diagram in a workshop setting and encouraged them to try to answer the following questions:
- What is the activity that your product will support?
- Who are the participants in the activity?
- What objectives do participants achieve through this activity?
- What are the tools and artifacts these participants already use in their daily lives that are relevant to this activity?
- What are the outcomes of this activity?
The product team members had about five minutes to fill in Engeström’s diagram. Then, they each took turns presenting their diagram and receiving feedback from each other about their assumptions. Within the first thirty minutes of the workshop, I witnessed a common language develop about the activity their cycle time product would support. In turn, a new set of hypotheses formed that they could go out and validate.
You can see the result of the workshop in the diagram below. They actually displayed it in their team space and referred to it whenever they were vetting ideas for features or formulating questions they would ask during interviews with customers.
SOFTWARE PROCESS IMPROVEMENT – HUMAN ACTIVITY DIAGRAM
What are they making now? A product that helps teams continuously improve by providing visibility into the health of the team. Using indicators like cycle time, the product helps teams identify work that is slow, stuck, or churning, and potential bottlenecks in the workflow. Their customers already rely on information radiators for continuous visibility into the health of their projects, so the product team’s product works as an information radiator. The product “radiates” in a team room on a LCD display, providing customers with the ability to drill down and see which of their work items are slow, stuck, churning, or a potential bottleneck.
As an aside, the team found that the activity diagram and the business model canvas converged in interesting ways. As they performed customer development activities, they kept the “Software Process Improvement” activity diagram in the back of their mind. The activity informed the top-level goal for their product (help customers who want to continuously improve) while the business model canvas reflected how they would garner customer attention, acquire customers, and retain customers for their solution.
Can you think of other examples about how activity systems have affected product decisions?
Donald Norman shares his thoughts about Activity-Centered Design in these articles:
- Logic Versus Usage: The Case for Activity-Centered Design
- Human-Centered Design Considered Harmful
- HCD harmful? A Clarification
Also, anthropology professor Bonnie Nardi has written a book called Acting with Technology that explores activity theory as a framework for interaction design. Bonnie and Donald were once colleagues at Apple.
Ever since Facebook and GMail began misusing the grip icon as a navicon, countless UI frameworks and websites have started to mix the icon metaphors as well. Here are the differences, and why it’s important to be consistent…
The difference between gripping then pulling and tapping then navigating
The grip icon has the affordance of gripping and pulling a UI object in a direction perpendicular to the position of the lines composing this icon (see gription). Most commonly, the grip icon provides a cue for rearranging items vertically in a list:
Tapping the list icon should reveal a list of actions:
Incorrect use of the grip icon
Facebook and GMail incorrectly use the grip icon. You can tap the grip icon and reveal the main menu. You can also drag the left edge of the screen with your thumb and pull to the right to reveal the main menu.
Facebook’s incorrect use of grip icon
GMail’s incorrect use of grip icon
2 options to correct the usage
Tap the list icon then Navigate
Drag the grip icon (rotated 90°) then Navigate
Consistent use of the grip icon can go a long way to teach people about touch interface paradigms. It also helps your app stand out as a polished and respectable citizen on the mobile platform.