The location was amazing, the organization was also up to the game and overall I’m satisfied of the event. There was a good variety of talks, and even if there were a couple of them that I noticed were difficult for the crowd, being a bit too high or abstract, overall these played well in the balance with the more pragmatical ones.

Unfortunately I have also a criticism: while the event was indeed good, in the end basically nobody talked really about emergence with the exception of Jamie Brassett. Most of the talks were either referencing to it in an incredible loose way or using the term with a completely different meaning — giving me the uncomfortable impression that some of the speakers weren’t even knowledgeable about emergence at all.

I’m not really good in doing reports afterward, but as I did during dConstruct 2011, I sketched a PDF book during the event with all my notes. You can download it here (I hope it’s readable).

A few interesting concepts or quotes:

• Michael Wolff: “People tolerate pretty terrible behaviours” and on the other side “People will never forget how you made them feel”.
• Jamie Brassett: “The challenge is to articulate an open space with simple rules, like a flock”.
• Richard Seymour (video): “Why did you write something in the back of the clock where nobody sees it? — God can see it”.
• Anais Nin (cited): “We don’t see things as they are, we see things as we are”.
• Tom Hulme: “Our ability to plan is disappearing”.
• Misha Glenny (video): “Certain disabilities turn in incredible skills with a computer”.
• Julie Jenson Bennett: “We should stop looking for the new but look for the better”.
• Nadia Berthouze: “Our body speaks to others as it speaks to ourselves”.
• Barry Buzan: “Individuals today can achieve relatively big power”.

You can see all the videos on the event website.

This is not how things work, right?

But it’s exactly how it works on the web. You have to type a password before using your laptop.You have to login before you can access Twitter, you have to login before ordering anything on Amazon, you have to login before using Facebook. And then, if you work in an office and don’t like to mix your job and your personal life in a single identity, you need to log out of all your accounts and log in again to your professional ones.

This is because the web today is based on logins. We are more then 10 years into the internet age and still we are identifying ourselves with usernames and password, a method that has already demonstrated to be incredibly difficult to manage for everyone, because the “good password policies” are too hard to apply for a normal person that just wants to send a photo to his grandmother.

Is the login paradigm a failure? Yes, and you’ll find plenty of evidence online. One of my favourite is this report form Trusteer (PDF) that shows how 73% of people share the critical banking username with other online services and 47% of them share both username and password. From a completely different perspective there are recurring discussions on where’s better to put the registration, because that boring detail hugely influences adoption. Check this excellent presentation by Joshua Porter on this very topic. Of course, this model served us well up until now. But this is not enough anymore.

I believe we should move away from logins, and embrace identities. Or, without getting too philosophical, move towards an interaction paradigm that looks more like real identities and less like cypher codes from Mission Impossible.

I’m surely not the first person thinking and talking about this, and even more there are lots of people out there working directly on this specific topic, taking one stance or another on how to solve the problem. There are products like 1Password and Passpack and there are also big companies like Google trying to push forward solutions, plus efforts like Mozilla BrowserID that are headed in this very direction.

This indicates two very interesting things: first this is a huge problem that’s felt by almost everybody; second, there are a lot of problems to solve before reaching our end.

What I’d like to do here is to connect all these different approaches together under a single umbrella, to help everyone head in the same direction. And this vision is excatly the shift from logins to identities.

Identity

How could we do that? Well, one step at time. The first step is quite simple, and requires an incredibly simple interface in your browser. That’s what I want to propose today, and I’d love to start a discussion, in order to create a better web for everyone. I don’t have all the answers, but I believe that this is the right way to go.

This is how I think identity should appear on your future browser version:

Did you notice the top-right corner?
This browser window, knows who I am.

There isn’t much more to add, that’s what the user has to do to login. Nothing. This browser window is logged in with your personal identity and will instruct any websites you visit accordingly.

It’s so simple that the part about the basic user experience ends here. It just works.

What’s great about this way of managing identities is that you can easily switch from one to another. Plus, you can have multiple windows open, each one with a different active identity.

Private browsing will be just another identity, not a special mode anymore, giving a clear signal that you can still browser without disclosing anything at all.

Switching from one identity to the other might be locked with a password, and it might be possible to add an option to automatically logout to Privacy mode after some inactivity time.

For convenience, let’s use a name for this identity-based approach. Identity 2.0 is taken by OpenID. So, instead of Identity 3.0, let’s use the more meaningful Seamless Identity.

How does Seamless Identity work?

As it often happens with transparent interactions like this, there is a hidden complexity underneath. There are technical challenges that connects with two topics: privacy and security.

While I know a bit of both, I’m not expert enough to have a definitive answer for a service that could potentially work for every person in the world. That’s why I’d love to have feedbacks on the model I’m describing here and build together a solid standard.

One of the API could be a JavaScript API, and could work like this:

1. By default, it exposes a low security identity token generated for a specific domain. So any website will be able to associate data with you and you alone, without any risk to lose it, since that token will be stored with the identity. I imagine that this token will be generated with a cryptographic algorithm in order to be both secure, unique and not sharable between multiple domains. In this way, nobody will be able to track your movements even if your identity is active, because each token will be unique and different (and possibly, revokable).
2. If the website wants to know more about you, it has to ask. It’s not much different than a waiter asking your name to take your booking, and it will be available at the push of a button. I think that the next level up is “email”, since too many services right now need it for things like notifications. Notice however that there could be a service attached to this identity module creating special emails that could be invalidated, protecting in this way your real email address.

It’s interesting to note however that most online services will be able to provide most of their features with just the first level token, since the important thing is to uniquely identify you. The need to provide an email address is in many cases just a byproduct of the login paradigm and its compulsory registration. Think about it: you would still be able to access the whole of Twitter, Facebook or Flickr even if they didn’t have your email, right? The important thing for these services is to know that you are really you, in order to grant access to your data.

PROS:

1. Transparent user experience.
2. Increased safety against phishing: since you never have to type anything or disclose twice your credential to a website, they can’t ask you twice without looking suspicious.
3. Your data will be inputted only once in the Identity Manager provided by the browser, and you’ll never have to type this information again. So, nobody could steal your password, email or credit card, since you’ll never type these details again. This would also allow automatic detail change the next time you visit the website. The browser runtime will protect the data for you (this is an important point of course for the browser implementation).
4. A new class of services will be enabled, and the adoption barrier will be lowered to almost zero. There will be no registration process to slow you down: you’ll open a website and you’ll be able to start using it immediately.
5. Facebook, or other identity providers, won’t be the gatekeepers of your data anymore. They could instead be cloud services offering more services on top of this identity mechanism.
6. It will allow peer-to-peer authenticated exchanges, since the identity is now in the device and not in the service you’re registered with.
7. No website will have to store your credit card data anymore, since it will be provided ad-hoc by the Identity Manager when needed.

CONS:

1. You will still have one password, the one protecting your device(s).
2. The identity will be a cryptographic information stored somewhere: if you lose it, it’s gone with all the accounts you ever created, and you’ll have to retrieve them with site-specific requests.
3. The identity needs to be transferred to every device you own.
4. If you don’t have your identity with you, there’s no way to login by default. Exactly like if you don’t have your identity you can’t buy alcohol, or you can’t get on a plane.

However the cons aren’t so bad and can be easily mitigated:

• Points 2 and 3 might be mitigated by a backend based on a standardized cloud service to store the identity. Data would be encrypted before being stored so that not even the company providing the service could access it (see Passpack as an example of how this has already been done transparently). The service would allow retrieval in case all your hardware is lost. If you think about it, it’s in some way what already happens with Android/GoogleAccounts and iOS/iCloud.
• Point 4 might be a problem for some users, but it might be less relevant since there’s a growing number of users that uses smartphones, and well, a feature like this could be ported to non-smartphones as well.
• Point 4 can also be mitigated by the services themselves, enabling different login mechanisms to allow non-identity based authentication (i.e. sending you an SMS with a token). This isn’t new, and it’s usually well developed in the best password recovery systems.

It’s worth noting an interesting detail: a lot of people are already using the browser built-in feature of Saved Passwords, or systems like 1Password. WIth these you get basically all the cons above, with a minimal advantage compared to what would be possible with Seamless Identity.

Use cases overview

What’s even more interesting is that while SeamlessID is intended and works as a replacement of logins, certain services such as banks might still require additional security systems and ask for nonce passwords. Also, the “password recovery systems” of today, will be “identity reconnect systems” just in case you need a one-time access from remotely or reset your identity connection. These will be provided as today by the services, because they will store different data (a recovery for a bank will be different from a recovery for Twitter).

That’s entirely fine. This is just a first step.

This diagram shows at a glance different use cases and how SeamlessID solves the problem easily.

As it’s now probably clear, there’s no way logins can help you in having the very first level of identity. That’s missing, because it’s too slow. It’s also one of the reasons why a lot of systems like Facebook are closed gardens: once you’re in, that first sight identity is granted. Once you’re in.

All the middle ground of identity is covered by logins as well, however SeamlessID will be simply quicker, by providing information at the click of the mouse and in a more secure way.

Seamless Identity API draft

This is a draft I thought that might enable this kind of service. It’s worth noting that while this is a JavaScript API, it’s possible to suppose that the browser could send the token inside the HTTP request header as well, thus providing this feature on systems without JavaScript. But that’s an advanced topic for another time.

It’s also worth noting that there are a lot of similarities with the Session API from Mozilla BrowserID, even if the Session API is still based on a login model instead of an identity model and seem still delegating the identity management to the website.

window.id.token

This property will provide the unique token to initiate the first level of identity exchange. As said before, this is unique within a domain.

The token could be an alphanumeric string like a md5 hash.

If the domain is blacklisted, or the user is in Privacy mode, the token property will return false.

As you can see this is similar, technically, to what already happens today with cookies, but the difference here is that now is the browser that generates the token from a private key and not the website.

This is huge, because it means that the identity doesn’t expire and the user has control over that identity.

Effectively, it means that you can trust any data created with the token, because it’s already you, and you can at a later time decide to keep that data, reset the token, upgrade the registration with the website or else.

window.id.get(<required>, <optional>, callback)

This will be a function to request the user to explicitly disclose these information. The application can request one or more fields, each one identified by its name.

For example:

window.id.get(['name', 'nickname'], callback);
window.id.get(['name', 'nickname'], ['avatar', 'country'], callback);
window.id.get(null, ['avatar', 'country'], callback);

When this request is issued, the user will see an overlay generated by the window chrome (not the page – for security reasons) asking if they want to allow that domain to access these details from that moment on.

window.id.getOnce(<required>, callback)

This function works exactly like window.id.get, with the same ability of ask for one or more fields from the Identity profile, and the same popup.

The difference is that these informations are returned to the web app only once, and every request needs to be authorized again.

Certain class of values, like credit cards, might only be available under the “getOnce” call. It might also be that this function will work only if the website is under HTTPS.

window.id.<field>

Once requested at least once with window.id.get(), each of the details will then be available directly at API level. This is useful also to handle updates: if for example the nickname changes, the system will be able to lookup it and verify it changed, updating its internal value automatically or after a confirmation.

This works well because we are talking about identities, and when some detail about you change you expect anyone you are in touch with to automatically get that update, or at least ask if you want that update to happen.

Notice also that I used “window” instead of “navigator” because the idea is that each window can use a different identity and this would make it cleared. However this is really just a detail managed by the browser engine itself. It could be “navigator” as well.

Native support

Another important thing about this approach is that identity will switch from being just multiple logins to memorize to being an operating system level feature, like the KeyChain feature in OSX.

In this way, once ready, Firefox, Chrome, Explorer, Safari, Opera and the other browsers could just provide an interface to that identity system.

This is even more relevant because for security reasons it is important to have all the interactions with the Identity Manager to be outside the website part of the screen: in this way they couldn’t fake any interaction with it (even if, as stated, you’ll have to push just one button, not type private data directly in the website).

This last thing is easy on a computer, but it’s hard on a smartphone where most of the screen estate will be used for the website. In this scenario, it will probably need to slide away like happens with the multitasking bar of iOS, in order to show the controls outside and maybe showing an image that you setup, and that a phishing website couldn’t know.

What will it mean for developers

Think about what happens today: you are developing an idea to help people do something. Today, you can’t really start if you don’t have a registration system of some kind. Even if you use a library, you have to take it into account.

Even worse, you will have to find ways to motivate enough your user to overcome the registration barrier and use your service, or create a smart system to allow your user to demo the system before registering, with all the complexity that it might mean.

With Seamless Identity the registration barrier disappears.

For your earliest prototype, you might even just take the token and work with it, without any registration or any additional detail. You will be able to test the platform and build only one code path. There’s no split between app and demo, it’s all app, working, without any barrier.

And all of this will cost you a single call to window.it.token.

Wouldn’t that be amazing?

Could you imagine all the services that could exist thanks to this?

Adoption

While I was writing this article Google published a very similar idea to handle multiple Chrome users. You can see their solution here. This is a good early confirmation that this approach is good, even if I’d put the login on the right corner because it’s where we usually expect it to be and I don’t want it to be confused with the app itself. However Google Chrome’s solution vision is limited to Chrome. What we are talking here instead is a new layer for the open web.

I think that Mozilla has the right culture, technology and freedom to move forward this shift to identities and create a standard that will be adopted by all the other browsers… and hopefully operating systems as well.

Mozilla is already working on BrowserID, and this could potentially be the backend for this kind of identity shift, and after reading this article by David Ascher now I’m even more sure of this.

There’s of course a risk: the risk that each browser manufacturer will try to create walled identities, forcing users to use only one browser forever, with no ability to switch. You can clearly see that this will basically kill this concept, and will delay the adoption of an improved identity system for more years.

It’s important, if not critical, that the identity is easily transferrable, with a one-click way to do it: “Do you want this browser to use the Identity X?”, done. Even better if it will be a OS-level library. And BrowserID is again already trying to solve this problem by federating the concept of identity.

Otherwise… it will be just a way to trade one kind of fragmentation for another. Let’s work together. This should be a standard foundation for the future web. Identity must be in your hands, not in the hands of some external entity.

Even if I believe that Seamless Identity is the correct next step, I’m not focused on this specific implementation, just on this specific user experience and the fact that the code usability needs to be excellent, but even that is open for discussion. I believe that identity needs to make a step forward in being seamless and transparent, and that’s what I want to see. If it’s delivered in a different way, that’s still great.

~

If you think about this, the switch from logins to identities will also close another gap between native applications and web applications. Today you don’t have to login to an app you downloaded on your Android or iPad, and why should you if it’s local?

Moving from logins to identities on the web will allow this seamless experience for web apps as well, everywhere, on mobile and desktop. And on mobile it will be even more powerful.

I see a huge potential.

Do you know any browser developer? Participate in the discussion (on Twitter we are using the #seamlessID tag), link this article to them. I’m sure they will be interested, and you’ll help to change the web. ;)

Updates from the comments

1. Storage: what wasn’t clear enough probably is that this system by default stores everything in a secure space on your device. There’s no need to sync or put it on the cloud, you are in complete control. This already happens with Password Managers. If you want to think about this in a different way, SeamlessID simply makes transparent and more secure your Password Manager.
2. Device-less access: on the completely opposite side, there might be situations where you either don’t have your device, or you can’t access one. In this scenario, it’s also simple, because SeamlessID doesn’t mandate any restriction on the fact that the account might also be synced remotely. You might be able to log-in temporarly with a remote account, like a special privacy mode. The stress point here is that the browser should handle this layer of complexity, not the user. This already exists: OpenID logins, Facebook logins, Twitter logins, Google Account logins are all doing this.
3. Is it a replacement? No, not at all. Yes, this idea is designed to completely replace logins for normal usage, but logins will still be available as an alternative. Consider also that with SeamlessID in place you might still need a way to access a service without your authenticated device with you. The way will be the equivalent of the current “password recovery”, with the difference that will generate a one-time access instead of resetting the password.
4. Identity vs Identity certification: the fact that today we are using logins means that when someone says identity they often refer to “identity certification”. However, that’s a different thing: one thing is the neighbour that knows you by sight, another thing is the airport check-in that asks for your passport. That’s why SeamlessID has different access levels and doesn’t mandate any certification: it might be added, or not. The important part is automating the task so it’s not anymore the user that needs to remember that, but the Identity Manager in the browser or operating system.

Even if I was speaking mostly about design, I added some elements of business, strategy and change management as well, because I thought they were relevant.

I admit, this is a quite dense presentation, I would have probably taken out some topics in hindsight at least for UX Conference, trying to be more focused. However, on the plus side, from the feedback I got it was really successful and lots of people asked more. I probably need to do more workshop and less speeches in the future. :)

One method, two tools, three business tips. This is how I organized the presentation, in order to be not too unbalanced toward design, even if that was the focus, but also not being too high for more hands-on people.

One method

The most important part of Social Experience Design is that it can’t be done without a shift from traditional, deterministic thinking to the different Theory of Complexity thinking. This shift is critical because it’s the only way to deal with complex systems, such as people and social dynamics.

That’s why I talked again of the Dot Loop, because it contains all the factors that needs to be built-in in any design – well, in any company – to be really effective. The Dot Loop is an effective abstraction to deal with complex systems without a banalizing approach to them. Every successful company work that way – even, of course, probably they don’t call it Dot Loop, even if I’m starting hearing about it more often. :)

Two tools

The first tool is the Motivational Diamond, a very simple comparative visualizations that helps anyone working with social dynamics to focus on the four Relational Motivations (Competition, Excellence, Curiosity, Affection) and compare different services or parts of the service.

The second tool is the Social Usability and its Checklist, prepared to simplify the approach to it and provides an easy mnemonic. Social Usability works on four factors, that are Relations (the other), Identity (you), Communication (the channel between you and the other) and Emergence of Groups (all the emergent dynamics, again a complex system behavior).

Three business tips

These are very simple, but are also a very important part of a real change management process:

1. Be in-the-flow. This is critical in any good design tied to any change management process, but also for startups that are launching a new product: you have to understand that the day of your user is already
2. Be a double-pyramid business. This is a very important aspect, and might be an article by itself. Luckily it is: I wrote about the double-pyramid some time ago. This means that social businesses needs to engage in a different structure and find a balance between hierarchy and socialization, because the solution is in that balance and not in building a full hierarchic company or a full flat company.
3. Be a double double-pyramid business. Plus, you can’t be really a social business externally if you aren’t internally. You might have a unit that does customer service or social media operations, but if the whole company isn’t aligned, the users will get that, and the rewards are going to be lower (not zero, but lower).

The workshop

The extra part I prepared for Digital Accademia’s workshop regarded a couple of exercises to allow people focus a little more on how to use actively Relational Motivations and Social Usability.

I prepared two exercises to stimulate thinking and discussions:

• In pairs, draw a Motivational Diamond
  This is very interesting because it helps clarifying the four Relational Motivations by discussing it with a peer, and then the public discussions allow to clarify even more. As often happens in workshop, I learned something also this time: I have to clarify better that we are talking about traits that trigger relational aspects. For example, when we talk about “excellence” we aren’t talking about an excellent content, but about how we are promoting people’s excellence… and narcissism. :)
• In isolation, pick an item from the Social Usability Checklist and design an interface for it. Then, merge it with your partner to create a new UI with the two you prepared.
  I liked this one a lot because it shows how very simple solutions and interface can trigger more complex behaviours. One of the participants was worried because her solutions looked “too simple” but actually… that was the value of it! :)

A small joke

At UX Conference I was the last one of the day, so I had to think of something. That’s why I started with a small design practical joke… but I won’t tell what it was, and I removed it also from the presentation above. You’ll see the next time, maybe. ;)

Debunking the bullshit

Do you remember in high school that poor kid that constantly had low grades in math but brush in hand will be able to blow your mind by drawing? And do you remember the kid that has excellent grades in math, but was incredibly awful in drawing anything, even just a straight line? And the other kid that looked all the time annoyed and had overall low grades, but everyone listened amazed at their stories? And that kid that everyone knew, that talked with everyone, all the time? Have you ever seen the difference between the kind of people that follow an Engineering class and an Art class? And between a nerd and a jock?

Do you know Howard Gardner? It was 1983 when he defined his Theory of Multiple Intelligences. He was able to define in a brilliant way that there are different kinds of intelligences, identified by their brain localization, their place in our evolution, the susceptibility to symbolic expression, a distinct developmental progression, the existence of savants and so on. The intelligences he found are:

• Spatial
• Linguistic
• Logical-Mathematical
• Bodily-kinesthetic
• Musical
• Interpersonal
• Intrapersonal
• Naturalistic

Then for the last 28 years, we read things like:

A designer who does not write markup and css is not designing for the web, but drawing pictures.
— Andy Rutledge (2011)

My short answer is “Learn code.”
— Frank Chimero (2011)

Honestly, I’m shocked that in 2010 I’m still coming across ‘web designers’ who can’t code their own designs. No excuse.
— Elliot Jay Stocks (2010)

Designers must have a solid working knowledge of at least one modern programming language (C or Pascal) in addition to exposure to a wide variety of languages and tools, including Forth and Lisp.
— Mitchell Kapor (1990)

Do you get what’s wrong here? Coding and Designing tap into two very different kinds of intelligence – it’s even more complicated than this, and Gartner is just a widely understood example, but let’s simplify for a second. We even have different stereotypes and jokes to identify the two categories lifestyles!

So, please stop: this recurring debate is harmful to both professions.

It’s harmful because since it tries to create hybrid professionals, that by themselves are good, but maybe there were just exceptional specialist professionals. Because it forces young designers to learn coding, when they should study for example cognitive psychology and social psychology. Because it slows down designers in becoming excellent in what they are paid for. Because it creates the expectations that “designers should code, so I don’t need a frontend developer” (harming also frontend developer specialization).

So, please: stop this bullshit.

The ratio

But wonder what? It’s more complicated than that. People that suggest that designers should be able to code are suggesting a solution to a problem they see, before analyzing the problem itself. Once we look at it, we notice that there are two components of the problem:

1. Know what code does
2. Know how to code

Knowing what is very different by knowing how. This takes us to the usual questions: do architects need to know how to build a skyscraper? Do car designers need to know how to build an engine? Do a movie director need to know how to act? Does a surgeon need to know how to build a pacemaker? Of course not.

But yes, they need to know what these things do. How they perform. What are their limits.

And yes, learning to write code is able to build both these knowledges.

But not both knowledges are required for designers and that’s why the whole “designers should code” is bullshit. The sentence should be: “designers must know the capabilities and limits of their media”.

And wonder what? That’s exactly what happens in other kinds of design! A print designer that has never seen a type foundry will still be able to create wonderful prints. An industrial designer that has never seen a lathe will still be able to create wonderful objects. It happens every day.

And here we’ll reach the second point: teamwork.

Because how should a designer learn the limits of his media? There are two ways: use it and collaborate with people that build it.

The digital team

Let’s see what happens in a near industry. Around 1960, William Bernbach had an interesting idea: instead of having art directors and copywriters in two different departments, with huge difficulties to communicate, let’s create creative teams: one art director and one copywriter together working on the same design at the same time. His company went from $1 million to $40 million thanks to his creativity and these structural changes. Today there are almost no agencies that split art directors and copywriters. They are teams.

In this digital world – no, I’m not just talking about the web – there is another kind of team, and if you have ever met a situation when this team was able to live you know how well it works. The team of the digital era is a designer / developer team — well, not exactly, but let’s stop here for now. Also, the missing copywriter here is a huge problem in my perspective, but I’ll talk about teams and creativity another time.

The reason is simple: in this way they talk and collaborate. They learn the limits of each other’s profession without knowing anything about how actually do it. Because it’s not a requirement for either of them. It’s more efficient, and well… it’s healthier as well to have someone to talk with and get a different perspective.

Is it all wrong then?

If you read so far you should know my answer. Yes: it’s more complicated than that. ;)

There’s still a good point in suggesting that designers should code (“Why, it isn’t possible to do that? I’ve seen it done by Facebook!” – argh it looks simple but it takes ages with this platform here!). Exactly as there’s a good point in suggesting that developers should learn some design basics (“Stop asking me to do it pixel perfect” – argh it’s not pixel perfect what I’m asking!).

The reasons are simple:

• It’s way easier to learn the basics of how to code than learning how to build a skyscraper.
• It’s one of the ways to balance over-specialization and be a better professional.
• In small teams or startups it surely makes the difference if you know both.

And the reverse is valid for developers too.

In any field, if you expand your view to know all the ecosystem around you it’s beneficial. You can’t know everything, because even in a single discipline there is enough knowledge to fill a couple of lifetimes, but knowing a little bit more helps a lot. And I’m not talking just about designers and developers, but all the things that happens in a project. Knowing about budgets, timeframes, clients, market, advertising, SEO, health, food… all things that are able to increase efficiency, satisfaction in the client and quality in the final product… and satisfaction for yourself as well.

So: you don’t have to learn a bit more outside your discipline, but you could.

However, please, please, please: before coding learn some cognitive and social psychology! It’s more important for your profession!

If you want to read more, there’s a great post from 2009 by Lukas Mathias about this same topic: “Designers are not Programmers” (I told you it’s an old and recurring topic), and thanks to Mark, Chris and Mike for the excellent discussions we had on this topic. Thanks also to Sean McCabe for a nice infographic to explain better the concept above about know what/know how.

Once understood the difference between “have to” and “could” the next step could be then a good explanation by Mike Rundle on the values of both generalists and specialist.

Q&A from the comments

• “HTML/CSS is not coding” or “Neither markup nor CSS are exceptionally difficult to learn” [1]
  I know that formally HTML/CSS are a different thing from a language like JavaScript, Ruby, Python or C++. But it is only in the eyes of someone that knows code already. It’s a distinction that goes missing to someone that doesn’t get it. Here, please, you have to understand that there are different people, with different mind, skills, and talents. Sure, there are designers that could code and aren’t doing that, but there are also designers that won’t be able to code at basic level in any way. There are people that can be wonderful specialists, and people that can be excellent generalists or T-shaped generalists. We are different, please, try to understand that before getting into a crusade.
  You might also want to have a read of this article by Jeff Atwood from 2006, describing a research paper about a test to separate programmers from non programmers: “Most people can’t learn to program: between 30% and 60% of every university computer science department’s intake fail the first programming course.”, or event better: “the act of programming seems literally unteachable to a sizable subset of incoming computer science students“. It’s a little superficial because the problem probably lies in the way the subject matter is taught, but it helps contextualize a bit this problem.
• “I think there is a semantic issue here on the definition of ‘designer’.”
  Yes. I kept the article vague, because that is a completely different argument, and I thought – but I might be wrong – that would have diluted the argument above. But YES, that’s another good point. There are very different kinds of design, but the overall criticism usually is triggered against any designer that works on the web, and that’s why I called bullshit. Working on the web doesn’t mean that you have to code, just that you could code, and that is valid if you are a “web designer” or “graphic designer” or “ux designer” or “ixd designer” that works on the web.
• “Gardner”
  A few people started arguing about the theory I cited. Yes, there are criticisms, but it’s not the point, it’s just a starting concept to frame a little better the article with the support of a quite widely known theory. As Domenico correctly suggested me, you can have a look at other researches as well, like the CHC Theory, the WAIS, the Hebbian theory or a more widely known author like Daniel Goleman. It surprised me that this was the central problem for a few people. :)
• “to really take art to the next level, you really have to learn to code.”
  Yes. To really take to the next level. Exactly like a painter can paint, but then can start creating his own paints, in every profession you can benefit for digging both deeper and wider in nearby fields. I can also argue that to take it really to the next level, you should learn cognitive psychology,  social psychology, gestalt theory, marketing, copywriting, information architecture, usability, economy, statistics, science of materials, architecture, and so on. Yes, all these things will benefit a designer. Actually, since we are talking about designers and not developers, I prefer to suggest first some of these other things than coding – some of them are HUGELY missing from design skillsets – but as you can see, there are lots of things that could take you to the next level. It just depends what next level are we talking about. The point of the article, however, isn’t that there are no “next levels”, is that you aren’t less of a designer if you can’t code. You are just choosing something else (hopefully!).
• “some example showing why designers should code”
  Most of the people that are using examples are showing problems in teamwork, collaboration and communication. It seems that lots of people think that by knowing better you’ll solve the problem of having “an arrogant designer telling you what to do”. Such a designer is bad, but if he learns coding it just get worse. Such a designer is bad because he doesn’t have the correct teamwork skills to cooperate properly, and the same problem could exists in the developer as well. So, improve teamwork skills before coding skills, and without such an ass in the team, the overall mood and productivity will increase for everyone. ;)
• “So, in the end, they should or shouldnt?”
  The summary, is that there’s no answer to this question. As I said repeatedly: it’s more complicated than that. The answer isn’t “yes” and isn’t “no”. The answer is “choose”.

I started thinking about how to organize my Google+ Circles very early, around 9 years old. It was the first page of my first try to keep a diary, and I thought it would have been nice to represent all the people I knew in a nice graph (you can say that I was pretty much destined to be a designer). I did a first sketch, but the connections weren’t right. Then a second. A third. Yes, I was very close to Tommaso, but actually my relation with Gianmaria was more rare, but stronger. A fourth sketch. And what about… A fifth sketch. Well, there was no way. Any criteria I tried failed to be accurate, and being a perfectionist without enough experience to handle failures I got frustrated quite a lot. I gave up… and with that I failed the first time to keep a diary, but that’s another story. While I never tried again to represent my relations with people, I kept thinking about these failures a lot, and years later I understood that this is actually a very hard task that is usually solved by simplifying it drastically, like for example counting the degrees of distance.

With the release of Google+ I wanted to use its hype to understand a little bit better how people were using Circles and try to help others to understand that too. So I started a small survey, that got a quite big response, with 176 people completing out the survey and more than half of them helping also to spread it.

The data is interesting in my opinion, so before entering in a few interesting details, here’s the now traditional graphic, feel free to share it:

Let’s see some details about the results:

1. Feature:
   As you can see it’s quite clear that the media perception was right: Circles are definitely the most important and interesting feature of Google+, followed in large distance by the Stream and Hangouts. Every other feature is almost irrelevant, even if they got quite a prominent space on the platform. It’s particularly interesting the position of Photos, that received absolutely zero votes, even if I can guess most of the users are fine in having them incorporated in the Stream itself.
2. Usage type:
   These categories aren’t mutually exclusive, so there is of course some overlap between Talker and Broadcaster, or between Talker and Commenter. However I wanted to make this distinction because I noticed that there are some users that have a more specific usage. For example  Explorers preferred that choice over the combined Talker & Listener, and It’s going to be interesting to see if that number goes up or down if I make a similar survey in the future. However it’s relevant to see that even if existing, there are very few pure Broadcasters, a number overtaken by the pure Commenters. It’s also interesting the difference in choice between Talker and Broadcaster, a subtle detail I used to check if the platform was more perceived as a social tool (Facebook) or as a communication tool (Twitter).
3. Are Circle working? Are you going to use it in the future?
   These two questions are of course different, but are also slightly correlated. For example it’s interesting to notice that there is a minority of people (2%) that while says that circles are working for them, then they aren’t fully convinced they are going to use it in the future. It’s also relevant to see that while the current satisfaction is high is still less then half (44%) and at the same time most of the people, even the ones for which it’s not working at all, have bright expectations from the future, with just a slight minority (3%) thinking it’s hype.

Well, not entirely, and recently I found a good example.

The other day I stumbled on a nice article on Google+, this one:

I might be wrong (please point me to a good source if I am), but I don’t think that any designer in Google ever thought about this. But this nonetheless happened: Google+ (at least right now) is a good platform to publish comics.

Why things like this happen? Because design doesn’t exist in vacuum, but it has to confront daily with the users, and the users, both as individuals and as a group, are complex systems.

So, when you design something you can always predict the end result to a certain extent, and that’s exactly why testing is so important. So important in fact that you shouldn’t design without testing, it’s inherent in it, being that web design, industrial design or else.

This time, the platform turned out to be also very well suited to create online comics, a kind of “discovery” that was found by the users and emerged naturally from an interaction model that was born to support other uses. Things like this happen more often than thought, another recent example was the Facebook profile page pictures hijacking, and not always are good things.

Of course, this specific case might be just an enthusiast user and not a widespread understanding, however, it’s exactly the right kind of weak signals that can be correctly read and acted upon.

The important thing here isn’t to predict these emerging features, but to see that and encourage or discourage them through an iterative design process.

That value was validated by a few observation on human behaviour, since prehistory to our days, and it was confirmed by Bernard and Killworth, even if with an higher result: 290.

While social networks were thought to be able to raise sensibly Dunbar’s Number upper limit, it seems that it’s not the case. A recent research by Gonçalves, Perra and Vespignani (USA/Italy) analyzed 381.652.990 tweets, 3.006.180 users in a time range of 4 years and focusing on the social interactions between people they were able to model an algorithm to identify the most cohesive group.

The result is very interesting:

The data shows that this quantity [the strength of social interactions] reaches a maximum between 100 and 200 friends, in agreement with Dunbar’s prediction. This finding suggests that even though modern social networks help us to log all the people with whom we meet and interact, they are unable to overcome the biological and physical constraints that limit stable social relations.

The number of reciprocated connections saturates between 200 and 300 event though the number of incoming connections continues to increase.

It’s still important to notice that while Dunbar’s Number is constant, this doesn’t mean absolutely that nothing changes with the usage of social networks. As often happens, it’s more complex than that. For example they still support us:

1. in creating new relations,
2. in supporting weak connections,
3. in keeping together a specific cohesive group that might not be that way otherwise.

The understanding of the underlying principle of Dunbar’s Number is helpful to both designers and users to get the maximum possible from these social tools, without falling into the trap of trying to do too much… until we find of course a way to do that. ;)

(via The Physics arXiv Blog: Human Brain Limits Twitter Friends to 150)

I’m going to present you something obvious. Why? I think it’s interesting exactly because it’s so obvious that usually nobody thinks about it, and it’s dismissed easily. But nonetheless, if you start thinking that this concept exists it can help you a lot in many problem-solving activities and you’ll start seeing it everywhere.

Everywhere.

Let’s start with some example. The computer modeled upon Von Neumann’s architecture is basically a black box with a CPU and a memory that processes an input an returns an output, iteratively. The user centered design process in the ISO 13407 standard is a four phases loop: specify context, specify requirements, design solutions, evaluate. The problem-solving approach of Action Research is split in three iterative phases: plan, action and result. Agile methodologies have the concept of sprint, where you start with a sprint planning, you do a few days of development and then you end with a retrospective. Looking at a different discipline, in biology many systems are based on the concept of stimulus, elaboration and reaction, where in an amoeba we have a chemical process while in a cat the whole loop is mediated by the nervous system. The embodied cognition explains that the process of knowing is a loop between behavioural interaction and perception, between the action on the environment caused by a motor system and the perception of that same environment by a sensory system (thanks Gian). In the nervous system you can easily see the same pattern again in each and every neuron, and within the neuron in every synapse and down to every chemical receptor. In cybernetics you have the analogous feedback concept.

Once you start, you can go on with many different examples from different disciplines just looking around you. Are you starting to see the pattern here?

The Dot Loop

From those examples you can notice some interesting common traits:

• they are all loops, no inherent ending
• they can be all synthesized in three phases
• they exist at very different levels, often one inside the other (think about a living being and its own cells).
• every loop is short, in its own context

Hence, we can abstract it and call it the Dot Loop: do, observe, think. This loop exists everywhere you see something that works.

Why is this important? For three reasons:

• It’s a baseline for processes: any process you are going to use or build needs to have those three levels, nothing less than those, like a dot in geometry.
• It’s a validator for processes: if the process you are looking or the one you are building is missing one of those steps, then something is either wrong or hidden behind something. If it’s hidden, it’s better to understand why and make it more explicit.
• It’s the minimal building block: you can’t have nothing less than this, but also if you have something right like this then you need to go deeper, because it’s not enough, it’s too abstract and needs to get practical. For example you can say that one phase is “Design”, but unless you know how you are going to do that (card sorting, wireframes, visual layouts, prototypes) then it’s too abstract to be useful.

It’s very interesting because it’s something that inside a process can be repeated multiple times at multiple levels. Think for example the sprint in the Scrum Agile process: at the top level you have the building of a software: the client asks something, the team builds it, and it gets released back to the client. But inside that very high level (and not very useful) explanation you have a lot of iterations, again matching the Dot Loop, and inside each one of those each user story is prepared, developed and accepted. Again a Dot Loop.

Notice also that the starting point isn’t fixed. You might think that a project starts with the Observe phase, or analysis. But from another point of view, the clients starts with a request, so it’s a Do phase. And usually you can go back the loop more and more, without being able to define a starting point.

Notice also that in every following iteration each phase can do different things: for example the Observation phase at the beginning could refer to the business scenario, in the middle could refer to user interaction testing and in the end it could be the feedback from the users.

The Dot Loops within Agile: Scrum

The Agile Manifesto explains the four core elements of the discipline: individuals and interactions, working software, customer collaboration, responding to change. Even from this point of view, you see that a Dot Loop process intuitively matches Agile.

If we take the Scrum methodology alone we can get into some details and see that a single sprint is exactly a Dot Loop:

• the sprint planning: Think
• the sprint itself: Do
• the sprint review and retrospective: Observe

But also, if we look inside the Do phase, we notice that the developers are:

• designing the solution of each user story: Think
• coding the tests and the solution: Do
• testing the solution: Observe

It’s obvious now, right?

Of course, if you go even more in depth things start getting a whole more complicated, but if you are doing things right, you are still working in different Dot Loops at different abstraction levels. Jacopo Romei, an Agile coach friend of mine, modeled the agile process as a sequence of feedback loops in its Software Feedback Loop, I think that’s an interesting higher-level perspective.

Some other examples

But how can something so obvious be useful for you? You don’t have to be a business engineer to use this simple and basic concept. Managers, designers, developers, and many more can apply the Dot Loop to their own field.

Think about a company starting to deploy a new intranet. In a typical scenario, it’s going to choose the technology, building the service and then releasing it one day with a communication through mail. As you can see, it’s missing a critical step that’s easily spotted once you see this through the Dot Loop: there’s no feedback, no following Observe phase after the release and probably not even tests with final users during the development of the application.

Another good example is made when companies see the new world of social media and start to use them straight away, creating pages on Facebook, accounts on Twitter and starting to push content through them. Even if the loop goes on, it’s missing the Think phase in between, that would have aligned the company strategy with the correct communication.

Think about the typical waterfall model, that leads so often to mediocre products. This basically happens because it’s like making one single Dot Loop, instead that taking the output feedback from the Do part and analyzing it to perform a following new action. Even when the feedback is take into account, often it’s just “check if we reached our objectives” and nothing after that. Instead creating a virtuous cycle is the correct way to both solve problems and evolve existing solutions.

If you want to build or evolve a social network the biggest error is going to be to start developing it assuming a specific behaviour of the users, but this rarely happens. You need to plan a social network in a sequence of iterations where you check what’s going on and adapt each step to the community evolution that surely happens each time.

You probably don’t have to look around much to see companies and consultants that are proposing their own “magic” process. With the Dot Loop you can have a first insight if they are saying something worth listening, or not: is there a missing step in the process? Flawed. Is it not a loop? Flawed.  It stops with the three steps? Too shallow. It has these three steps, or more steps that could be synthesized in Do, Observe, Think and they go in-depth describing what they do in each one of them? Great. They probably have something. The technical term I use in consultancy for this is “bullshit detector”. ;)

Notice also that sometimes this knowledge can be hidden. I’ve seen once a company that was delivering high quality products, but its formal model was waterfall. In the end it was again a Dot Loop – very similar to agile – but placed inside a structured process that in the end was just a logical explanation, not a process by itself.

As you might guess, the list could go on a lot and every one of those problems could be avoided understanding the Dot Loop, since it’s the minimal possible process.

Success consists of going from failure to failure without loss of enthusiasm.
— Winston Churchill

As many aphorisms, what I find interesting here are the thoughts that it could trigger, and of all the possibilities I’d like to focus on the “why?”.
My answer, today, is that the ability to go through failures without losing enthusiasm starts from a passion, or some form of inner fire. If that’s missing, then every failure is going to be a huge blow able to stop you. If you have passion, than it’s going to be a huge blow able to make you stronger.

(Via a Steve Blank post about startups).

I like Apple for the opposite reason: they’re not afraid of getting a rudimentary 1.0 out into the world.

What killed us was “one more thing.” We could have easily done three major releases that year if we had drawn a line in the sand, said “finished,” and shipped the darn thing.

On WordPress.com we deploy code to production twenty or thirty times a day and anyone in the company can do it.
— Matt Mullenweg (2010) 1.0 is the loneliest number

I think that Matt made a good argument, and it’s a nice starting point to move a little beyond and asking the question: “Why?”.

Let’s take the “one more thing” part. That problem exists only if you don’t have a clear vision. If you are just adding features because those are useful. If this is your approach, then you must at some point draw a line and say “stop”, and that part is hard, mostly because of the community pressure (but the same happens inside a company).

So, why code to production in a web service app works? Because you can just release and see if the users like it or not. But, basically, it’s not a very different approach. Instead of putting features in a code base you are putting it in a production server. The only thing changed is that you have an instant, granular feedback.

That’s good. Very good.

But I think that it’s a great solution to the feedback problem, or in other means that just hides the problem I’m referring to: vision. If I have a clear vision in my mind of what a product should look like, you don’t have to “draw a line” anymore. You just have an idea and you work to create it. And that’s going to be the next release of your software, or your next announcement in a web service world.

Because you had a vision and you made it real.

Don’t think that this means that you need a Steve Jobs that decides everything, all in his hands. It could be a group of peers, or a community-driven process. At the same time, don’t forget that in any group or community natural leaders emerge to drive this process. A good leader is a catalyst, not a ruler.

So you’ll understand that the “1.0″ iPhone that Matt is referring to isn’t a “line drawn”, is a step-stone of a vision.

From my point of view, the released product is usually the simplest solution for that vision. Without the correct vision, you don’t have the correct needs, you don’t have the correct objectives, you don’t have the correct context, and you can’t ever design the simplest possible solution, because it doesn’t have any vision to satisfy, just a lot of partial simple designs on smaller pieces.