Truly innovative products solve meaningful problems. That doesn’t mean they require a screen.

In some cases apps that necessitate tap after tap or click after click – experiences relegated to a screen – simply aren’t faster or easier than the solutions they’re replacing. We need to consider how our software can be experienced beyond, or even without, an interface.

To help show us what a world of screen-less software could look like, Golden Krishna, author of the best-selling book The Best Interface is No Interface, joined me on our podcast. Golden’s a design strategist at Google, where he’s tasked with shaping the future of Android. He previously worked in R&D innovation labs at Samsung, where he helped design their first wearables, and later at Zappos, where he explored new lines of business ranging from checkout systems to Zappos Airlines.

My chat with Golden covers the importance of context in great product design, who’s setting the bar for screenless innovation today, the emergence of voice UI and more. If you enjoy the conversation check out more episodes of our podcast. You can subscribe on iTunes or grab the RSS feed. What follows is a lightly edited transcript of the interview, but if you’re short on time, here are five key takeaways:

1. When designing software it’s important to zoom out and look at the entire customer experience. When are they engaging with your product? Why? What are the triggers? What’s going on around them when they’re doing it?
2. Embrace typical processes instead of screens. If the experience you’re creating takes people away from typical process, it might not be the most simple solution.
3. The problem with conflating UX and UI design: it pushes designers to solve problems with screens, which isn’t always the best solution.
4. One of the best ways for startups to consider screenless design options early in the product-building process? Hire a data scientist as soon as possible.
5. Voice UI may very well be the next great tool, but the problem today, as Golden sees it, is that voice provides a command line experience in an environment where users have human-interaction-level expectations.

---

Adam Risman: Golden, welcome to the show. Can you give us a quick feel for your career trajectory and how you got to where you are today?

Golden Krishna: My design career really started when I went to art school at CalArts. I always thought of art and design as this flakey, abstract thing that didn’t really mean a lot but was fun to do. When I was in school, I realized the value and the power of design. It’s an incredibly intense program, actually. I have friends who went to law school or became doctors, but I feel like I slept less than they did. School is a time in which you can get a lot better really quickly, because people really care about your growth.

After I graduated from CalArts, I started working at Cooper, which is a design consultancy in San Francisco, started by Alan Cooper. At the time, I reported to Nick Myers, who’s now the Director of UX at Fitbit. I also did some work with Doug LeMoine, who’s now at Apple.

It’s a fascinating story of how Doug came to be at Cooper. He used to work at the San Jose Tech Museum, and Alan Cooper was asked to speak at a donor’s dinner. Alan was talking about doing user research in the software world back in 1992, so a long time before a lot of other people. I mean, companies like Ideo and Frog have been doing user research, but at that time, they were focused more on industrial design, and less on software.

So at this dinner there are big companies in the room like Adobe, Microsoft, etc. They’re the big donors of the Tech Museum. Alan’s booting up his Power Point presentation, and it just completely crashes. Alan first asked, “Hey, is anybody here from Microsoft?” A couple people raised their hands. Alan then stood on top of the table, pointed at them and said, “You should be ashamed of yourselves!” He was screaming at them.

A lot of people talk about fighting for the users. Alan literally fought for users. He was always pushing things at the company. It was an awesome place to be.

Designers are often getting brought into big companies right away (out of school). The nice thing about agencies is you’re in a designer haven. You get a taste of so many different kinds of projects.

I always enjoyed the projects where we worked with companies on big-picture thinking, the things we could do next, and after working at Cooper for a little over three years I got an opportunity to work on an innovation lab at Samsung. At that lab, we worked on new products and services that could launch in the next 18-24 months. That was fun. Samsung’s a crazy environment. Incredibly internally competitive, and obviously externally competitive, too. They’re the kind of company that throws everything on the wall and sees what sticks – with the wall being in the marketplace. It’s utterly fascinating to see how a hardware company like Samsung has the success they have today.

I went from that crazy culture, to what I think was the best culture I’ve ever been a part of, Zappos. I worked at Zappos Labs, which is another innovation team. I have so many positive things to say about the culture at Zappos. It was a really incredible environment, I got to spend a lot of time with the CEO, Tony Hsieh. We had weekly 1:1s at a certain point, which was awesome. I spent a few years there.

Now I’m at Google, and I’m working on a long-term, similar kind of team, but within the product of Android. Google is huge, so it’s nice being inside one particular product there. What is the future of Android? That is exactly what my job is today.

What hardware can teach us about software design

Adam: Samsung, Zappos and Google are all very different companies. How would you describe the design culture of each? And what have you taken from each of those as your career has progressed?

Golden: Of all the cultures, I think Zappos is the best. Google culture is talked about a lot in positive ways, and I think it should be. But there are some things that happened really early on within Zappos. For example, the first interview that you have at Zappos is not a skills-based interview. I see this a lot when startups are recruiting and trying to find the best fits. They often fall back on things like, “Hey, show us your Dribble portfolio”, or all these nonsensical things that don’t actually amount to whether someone is going to be great.

The very first interview at Zappos is about you as a person. They don’t even talk about your actual skillset. It’s, who are you? Why do you make the decisions that you make? When I was there we were looking for people who were easy to collaborate with. People who were optimistic and had a sense of problem solving, that would continue to go after things. We weren’t looking at their output right away. It was more about their character. And that first character interview is so rare. I’ve never heard of another company that does that.

Only at Zappos did I feel like I wanted to get drinks with everyone in the room afterwards. No offense to any other colleagues I’ve had, many of whom are incredible. But at Zappos it was almost 100 percent of the room. I felt like, “Hey, let’s all continue to hang out, this is such a fun place to work.”

Thinking about me personally, I’ve always been excited about roles and opportunities where I have the ability to run in this open field, and have this chance to push the company forward, as well as work on my personal mission, which is to push the whole field forward. There’s a lot of talk in design about getting the right craft, or getting the right process down. All those things are really important, but the thing that drives me is trying to find opportunities where I can really push the company and the whole field forward.

Going around to these sort of corporate innovation labs has become my niche, because I’ve been kind of trying to find opportunities where I can really take big chances. Some of my work will never be seen, and some of my work will ship in a short amount of time, but it’s hard to say what’s going to happen. I just go after what I think is the best thing for our customers.

Adam: As you said, some of your projects over the years have shipped, while some, like Zappos Airlines, were totally exploratory. Most of our listeners work in software. You’ve designed digital products, and you’ve designed physical products. When it comes to the work you’ve done on the latter, what problem solving techniques or lessons have you learned that can be applied back to software?

When we design software, you just see mockups in rectangles.

Golden: When you work on hardware, or on a general service experience, which is a lot of what we did at Zappos, there’s a big zoom out that happens. Let’s say we’re designing a new TV at Samsung. When you make sketches for it, you sketch the TV in the living room, and you show people watching it. You sketch it in the kitchen, and you show what that’s like in the kitchen.

When we design software, especially because most software is on phones today, you just see mockups in rectangles. You forget about the entire environment in which someone’s using it. A lot of startups are going after some small segments of a potential user base. Maybe they’ll make some app that’s great for accountants. But they won’t draw the accountant’s workspace or their real workflow. They’ll just show what it’s like to go from screen to screen in an app.

That’s really common to see in people’s portfolios, at presentations and in slide decks. It’s, “Here’s a screen, here’s a screen, here’s a screen, here’s a screen. What do you guys think?” That can be good, but it’s also really nice to zoom out and look at the entire customer experience.

I can’t say too much about the Zappos Airlines thing, but that was an incredible project that I got to work on directly with the CEO as we explored that opportunity. We did a lot of customer journey maps. That’s not a new phrase, but it’s so rarely done on a day-to-day basis, where you really see how someone works through a flow. If it’s somebody that’s on their phone, when are they looking at their phone? Why? What are the triggers? What’s going on around them when they’re doing it? Is this the kind of thing they’re using when they’re on the train? Is this the kind of thing they’re using when they’re walking? These are very different kinds of things to think about.

A lot of fitness applications where people wear the phone on their shoulder when they’re jogging or cycling, the buttons aren’t any different in size. The text isn’t any different in size, even though the distance between the person and the phone is different or they’re not trying to be as distracted. Those are huge things that we just completely leave out, that in the hardware world we see a lot of, because we draw out those whole scenes.

Is the best interface no interface?

Adam: You mentioned this idea of designing from screen to screen and drawing rectangles, which leads me to a book that you published two years ago, The Best Interface Is No Interface. When it comes to embracing the core philosophy of the book, how are product makers doing today? Are we still trapped in this world of screen-based thinking? How’s the landscape changed?

Golden: One of the things I talked about when I first started writing this book was looking back to other huge kinds of changes. In the late 1970’s, there was this piece in The Economist about how the office is filled with paper, and we need to dream and live in a paperless world. That was considered crazy at the time, and it was. During the 1980’s the amount of paper used in the American office actually went up.

So here was The Economist saying, “We’re going to live in a paperless world.” And the very next decade, we use more and more paper. But in today’s environment, there’s actually less and less, and starting around 2008, people began using less and less paper in the American office. Maybe we’ll eventually end up with this paperless world.

In a similar fashion, we are inundated with screens today. The average American adult spends a little more than eight and a half hours looking at a screen. Teenagers, who are mostly in school, spend about seven and a half hours a day looking at a screen, which is crazy. Even children under the age of eight spend about two hours a day in the United States looking at a screen.

That’s a lot of screen time for a lot of people. It’s good portion of our waking hours. The book is really about how do we go from this screen-filled world, to a screen-less world? Just like that Economist piece took decades to even start to be realized, although the technology industry moves a little quicker than the paper industry, it will be a good number of years.

When I wrote the book, it was really hard to find examples, but since the book has been released, the number of examples that I’ve been able to find has just rapidly increased. I love to think that’s because the book is out there, but I also know and feel that this is a movement that is going on beyond just the things that I’m saying.

Adam: Speaking of examples, who is embracing this type of thinking well?

Golden: When I first started talking about this, I gave the example of this car key – an app versus a piece of hardware. BMW had released this app for your cars; Tesla has this giant screen in the center console of their car. People were trying to make car experiences better with screens. They thought they could improve on locking your car doors by making an app.

Instead of taking people away from the typical process, bring them
back in.

Think about the actual experience, that whole journey. When someone is walking out of a store or their house, and they want to unlock their car doors, they first take their phone out of their pocket. They unlock their phone in some manner, whether it’s slide unlock or pin code. They swipe through a sea of icons trying to find that BMW app. They tap to launch the app. Then, in the BMW app, there’s a menu they have to look through, and they have to understand that one option is a remote.They tap the remote tab. Then inside that remote tab, there’s a slider that slides between lock and unlock. That’s not easier than going up and using a key.

Alternatively, before we got obsessed with apps, Mercedes Benz worked on a project where you walk up to your car doors, and when you pull the car door handle, a radio signal gets sent out. If your keys are in your pocket or in your purse, the car doors just unlock. That technology has been licensed to a number of other car manufacturers today. It followed the first principle of the book, which is to embrace typical processes instead of screens. Instead of taking people away from the typical process, bring them back in.

I’m seeing a number of startups start to follow some of these models. There’s a startup called Lockitron, which has a door unlocking app you put over the deadbolt of your apartment or your house. In their 1.0, you had an app and you had to take all these steps just to unlock your front door. Never easier than a key. Maybe more convenient because you can rent it out to another person, you can lend unlocking your front door, but that’s a different problem.

Image credit: Golden Krishna. Download his latest slide deck here.

In their 2.0 they answered, “What if we just cut out all these steps with screens?” They put a simple solution in place: Put a Bluetooth radio in the door lock, turn on Bluetooth with their app, you walk up to your front door, and if you’re within a foot, the door unlocks.

Those are really simple, straightforward examples, but some people have been employing data science to do things that I think are far more advanced. For example, there’s this startup called Digit, which tries to help people save money. A lot of people in the United States, in the Western world in general, are pretty horrible at saving money. I think the majority of Americans don’t have savings past two months, so if they were to get fired, they only have money for about two months to hit their bills. Digit is trying to solve this problem.

This is far more advanced than keyless entry. We’re talking about financials, so you really can’t mess up here. When they plug into your checking account, they see the money that’s coming in and the money you’re spending on typical things. They look for little pockets, times in which they can move money from your checking account to your savings account. So when you spend a little bit less, they’re grabbing some money and moving it over. When they see opportunities to do a little bit more, be a little aggressive, they’ll do that. They’re behind the scenes moving some pennies over, and over time building up your savings account. That’s pretty neat. It’s a savings account that works without you ever having to interact with it.

The financial examples are super fascinating because they show that this kind of thinking can be employed in higher risk situations, e.g. your money. There’s another startup called Even, which looks at the problem for freelancers and people who are hourly paid, who have inconsistent paychecks. Every two weeks, these people don’t quite know what they’re going to earn. If you’re freelancing, maybe you got a big project and get a lot of money from it, then you might have a down period before you do your next project. It’s hard to know your financial future. Even looks at money that’s coming in, and instead of you getting inconsistent paychecks, they just average it out and then give you an even paycheck every two weeks. You know exactly what’s going to happen. If you make a little less, they make up some of the difference. And if you make a little bit more, they save that to give back to you later.

What’s so fascinating about these kinds of startups is that they’re not about the number of taps and clicks. They’re trying to solve a problem in what I think the best case of design is, which is to solve it in the most simple and elegant way possible – in this screenless way. That is a very high bar to try to hit, but when you hit it, you get these really crazy, amazing solutions.

Every startup’s big advantage

Adam: One common thread I notice in all those examples is they’re early stage companies that are really shaping the core of how they solve problems, rather than larger companies that don’t have as much flexibility. Larger companies have well baked processes and their teams are already well constructed. For people that are only starting to approach the problem that their product solves, what can they put in place to help facilitate this thinking?

Golden: When you’re a startup you have the ability to shape things that you don’t otherwise. A lot of big companies advertise these UX slash UI roles, and even designers talk about themselves in this way.

They aren’t the same thing. When you’re a UI designer, you’re there to compose a great screen. And when you’re a UX designer, you’re there to understand and solve problems. And when you conflate the two, you make it so people try to solve problems with screens. This causes all sorts of problems within large companies, so it’s great for startups to not be able to repeat that.

I was talking to a designer who is a couple decades older than me. He was talking to me about being a designer in the early 1980’s in technology. A lot of software at the time was command line, and they were shifting towards graphical user interfaces. It was a newer thing. It was first proposed at Xerox in the late 1970’s, but then really came into mainstream in the ’80s, especially when Apple launched their Lisa computer. He was talking about how hard it was to go to a company and say, “Hey, I’m going to be the guy who’s going to be drawing icons and choosing colors.” They’d never done that before, and it was crazy for them to think about actually hiring a designer. In fact, it took many years before having a designer in a technology company became more of a regular thing, and now it’s completely commonplace.

As we make another shift, and we start going away from thinking just about screens and employing all the new kinds of tech that’s available, that’s just sitting on your smartphone and rather unused, you’re looking at new kinds of roles. You’re obviously talking about bringing in a data scientist into your team. You’re talking about potentially bringing in a mechanical engineer who understands how sensors work. In the unlocking example, I talked about simple Bluetooth radio, but there’s all sorts of sensors that exist on a phone, and you can do some fascinating things with them.

Unfortunately a lot of data scientists today are relegated to these analytic roles, where they look at things post-production. They’re asking things like, how many people went to this page, or how many people spent this much time on a page, and looking for patterns after it’s already happened. When you’re in a startup environment, you can bring those people into the creation process, and that’s where you can get these incredible insights that no one else is doing. This is how you can beat the big guys. You can build a team that they can’t, and you can bring in people they didn’t think about when they made their product.

One of the things Google did really well early on is when they launched Gmail, they rethought of the email experience at the time with the available technologies, and introduced conversations and whatnot. But all those products at these big companies were created a number of years ago with different kinds of constraints. If you’re a new startup trying to disrupt the space, you can build it with a new set of people who have different kinds of insights that others would have never thought about. There’s a real opportunity.

The emergence of voice UI

Adam: One of the things that’s really emerged since the time when you wrote the book is voice UI. Do you see this as a better alternative to screens? What role do you see it playing?

When you have an object you can talk to, you create this crazy expectation that it’s like another person.

Golden: There’s a part of voice UI that I completely hate, and there’s a part of voice UI that I think is fascinating. The part that bothers me is that when we went from command line to graphical user interface, we went from guessing, e.g. I have no idea what to type in right now, to seeing a set of options, a set of icons you can tap and launch. When we get to voice UI, it’s just like command line. It feels like we’re taking a step back. You put an Alexa or Amazon Echo in your home – the naming of the products is part of the problem – and you don’t know what to say to it. What is it going to do?

The other day I was listening to music on it, which is one of the few things I think you can use it for every day. I said to it, “I don’t want to hear this song any more.” I thought I was informing it that I don’t like this kind of music, but actually the only thing it does is skip the track. I actually doesn’t have any intelligence there.

When you have an object you can talk to, you create this crazy expectation that it’s like another person. I think it’s at least five years before it can do a few more good things besides play music, just because there’s so much possibility of what someone could say. It can get some things better over time, but that expectation is so high. Perhaps part of that is because we watch science fiction movies where these computers can just do anything our voices say. Part of it is because we interact with other people, and when we interact with them we use our voice and we expect them to respond in a human kind of way.

It’s a huge uphill battle for voice to be done correctly, and it’s not at a great place right now. But good things could happen.

The next big innovation

Adam: Ben Evans recently published a post about the S-curve and that similar to PCs before it, maybe innovation for phones is starting to flatten out. As someone that works on the forefront of that area, do you agree? What do you think will be the next thing to take off? It sounds like maybe voice isn’t there yet.

Innovation comes on an S curve. Smartphones are flattening out at the top, for now. Multi-sensor cameras soon, though, then VR/AR

— Benedict Evans (@BenedictEvans) July 26, 2016

Golden: I don’t know exactly, but I’ll say this, Ben is an incredibly smart person. The S-curve seems like a pretty real thing, although I don’t have any data to prove that it is. I think that my role, or the reason that I was hired, was not to follow that S-curve, but to draw a new one. That sounds crazy, to draw a new S-curve, but that really is the purpose of a role like mine.

In a lot of ways smartphones are rectangles. They’ll get a little bit bigger, they’ll get a little bit thinner, maybe some of the borders will disappear. I don’t know exactly what people can do in hardware. I have some insights, but there’s always surprises. There’s some fundamental things that’ll probably stay somewhat consistent. Maybe we’ll be able to challenge them, and I will fail Google if I can’t come up with concepts that draw a new S-curve.

Now maybe I draw a new S-curve and we don’t see it, because it’s not possible for a number of years, or maybe we see it in a few years. I am in a constant battle to try to figure out what that is. I pull in tons of research and try to do my best. I’m on a team, obviously it’s not just me who’s doing this, but maybe we can figure out that new S-curve, and I really hope we can. I would personally love part of that to be these screen-less experiences.

Adam: To wrap up, where can listeners get more of your insights? Are you speaking anywhere any time soon?

Golden: I don’t speak at too many conferences, but I have three coming up which is rare for me. I’m speaking in Quebec City at a web conference, WAQ. Then I’m speaking outside Detroit at an automotive conference, HMI. And at the end of May I’m speaking at UX London.

To find out more about what’s going on and the kinds of things I’m talking about, you can go to nointerface.com or GoldenKrishna.com, or you can follow me on Twitter.

If you just want to email me, you can at Golden.Krishna@gmail.com. After the book was released I got more than 800 emails, and I replied to all of them – although some of them about six months late. So hold on tight if you email me. My inbox is flooded, but it’s great to be able to connect with people and see their concerns and hear their feedback, because it just makes these ideas so much stronger.

Adam: Thanks again for coming in today, Golden. This has been a lot of fun.

Golden: Thank you so much for having me here.

The post Google’s Golden Krishna on designing screenless experiences appeared first on Inside Intercom.

from The Intercom Blog https://blog.intercom.com/google-golden-krishna-screenless-experiences/

from MarketingProfs Daily https://www.marketingprofs.com/charts/2017/31849/eye-tracking-study-how-consumers-view-google-search-results-for-hotels

from Mental Floss http://mentalfloss.com/article/94054/english-doesnt-have-word-color-japanese-does

UI methodologies like Atomic Design bring logic and structure to individual screens. Now it’s time to extend that thinking to every aspect of your product.

Here’s a little mystery. Why is it that – a bit like hangovers and pop music – most products somehow seem to get worse with age?

You’d think the opposite should be true: that having a great team spend many years iterating on a product should eventually result in some immaculately perfect finished product. Instead after ten years it’s suddenly harder to unlock your phone. Why?

The long, painful answer is ill-discipline. Projects grow over time. More people join, some earlier folks leave, and clarity of design vision deteriorates. The business decides to chase new markets, and new features get tacked on like Christmas decorations. Internal collaboration gets harder and sub-teams develop their own design philosophies. Requests flood in from a more diverse customer base. Competition needs to be kept at bay by adding in more stuff. Sprawl sets in. Before long it doesn’t feel safe to enter some screens alone after dark. Good products degrade. It happens to the best of us.

The shorter answer is most product teams don’t adhere to a solid underlying design system. Something that unifies and guides all aspects of the experience from the conceptual building blocks of the product, to the details of the UI, to how things are named.

So if you’re suffering from the nice-to-have problem of designing a successful, growing product, here’s how considering all aspects of your design as a single system can save you – before the rot sets in.

The TL;DR

Given that this is the internet and you’ve probably got animal videos to watch, I’ll cut to the chase:

1. 50 years ago graphic designers figured out that it’s a good idea to come up with some shared underlying rules when designing a bunch of related things.
2. Digital product designers realized this is also a good way to make sure your buttons always look the same. “Design Systems” emerged as a useful way to build consistent UIs.
3. But most Design Systems are really just Pattern Libraries: a big box of UI Lego pieces that can be assembled in near-infinite ways. All the pieces may be consistent, but that doesn’t mean the assembled results will be.
4. Your product is more than just a pile of reusable UI elements. It has structure and meaning. It’s not a generic web page, it’s the embodiment of a system of concepts.
5. By embodying product concepts in Design Systems designers can go beyond consistent UIs towards creating consistent products.

That’s the nutshell version. If you already get it, godspeed.

Software with structural integrity

Making software isn’t like building a bridge. Construction workers have a clear end goal to aim for, mature methodologies and well-understood materials, and most of them dress better. The majority of industries are far more stable than software development. That’s good — most people generally prefer driving across bridges that weren’t designed using whiteboard markers and engineered by Googling for error messages.

Manhattan Bridge under construction, 1909. © Irving Underhill/Library of Congress

Digital product design is still in its infancy. We’re figuring this shit out as we go. As soon as we do figure something out, things change again – the tech improves, your team grows, competition emerges – and that process that you finally figured out breaks again. Plans are obsolete almost as soon as you’ve made them.

Without a blueprint of some sort to rely on it’s not surprising that so much software eventually buckles under its own weight.

So clearly we need something to set and keep us on course. Something to make the difficult parts of product development easier, make the slow parts faster, and to power us away from the enormous Pit Of Complexity that all products seem to get drawn into over time.

Enter Design Systems.

A brief history of design systems

Design Systems of one flavor or another have been around for quite a while. Simply put, a design system is useful for when you need to design not just one thing, but a whole set of things that you want to feel like a coherent family. If you come up with a template and always stick to it, you’ll get that coherence for free.

So instead of designing one subway sign you might come up with a set of graphic standards that allow you to design a whole set of signs and symbols that work together in concert. Also, can we bring back ring binders please? Old school cool.

New York City Transit Authority Graphics Standards Manual by Massimo Vignelli and Bob Noorda, 1970 source.

Or instead of designing a logo for an organization you might develop a visual system for representing that organization in all sorts of different contexts. Space exploration and classic graphic design, what’s not to love?

The NASA Graphics Standards Manual by Richard Danne and Bruce Blackburn, 1975 source.

CSS frameworks like Twitter Bootstrap dragged these ideas into the world of web development, providing reusable code snippets to easily build consistent UI elements like buttons and dropdowns. Wonderful, even if every website in the world basically looked identical for a while there.

Twitter Bootstrap, originally created by Mark Otto and Jacob Thornton, 2011

Brad Frost’s influential Atomic Design methodology put forward a more structural approach. Rather than a jumble of “atomic” elements scattered across a screen (e.g. a label, an input, a button), Atomic Design suggests that a small collection of UI elements should be thought of as a meaningful component, (e.g. a page footer, a login form). Put a pin in this idea, we’ll come back to it in a bit.

Brad Frost’s Atomic Design methodology, 2013

Finally, Google’s Material Design guidelines pushed the concept further, bringing deeper formal rationality, a bold aesthetic and resources and guidelines for building UI elements across a range of platforms. (I worked at Google and wrote the first set of guidelines for the Android Wear platform.)

Material Design by Google, 2014

Today, many larger companies have built their own custom, in-house design systems in an attempt to stave off the inevitable creep of inconsistency. Airbnb, Salesforce and Uber have built comprehensive systems that keep their own product UIs in check.

The limitations of pattern libraries

Maybe none of this is news to you. Maybe you’ve already got someone maintaining a nice little pattern library on your own team. (If you’re not sure who, just look for the person who can’t stop making Lego analogies.)

So can’t you just check the box and move on? Or is there a difference between a pattern library and a design system?

I mean, sure. But yes there is.

Most Pattern Libraries take the form of a web page that lists the different styles of all your UI elements: all the different sized headings, all the button styles, all the dropdowns that are used to build your UI. If all the designers and engineers on your team agree to only ever use these elements, your UI automatically stays consistent. It also allows you to tweak those styles down the road if you want to make a design change across your app. Not bad at all.

Intercom’s old, now-retired pattern library. Need some buttons? We got ‘em.

But there are a few problems with pattern libraries. Yes, they allow you to keep all of the smallest elements consistent. But they don’t have an opinion about how they should be put together. They don’t know anything about your product or the concepts behind it.

To return to our Lego analogy, simply having a limited pattern library of bricks to choose from doesn’t preclude me from building some really crazy shit.

Impressive, but not exactly coherent design – and that’s just the curtains. Source

Now think about those branded Lego kits you can buy. Each piece is much more opinionated. It knows what it’s going to get used for. There are still generic pieces involved, but when you put them together in a certain way they form something specific, like the leg of an AT-AT Walker. This is a design system.

(Caveat: those highly-prescribed branded kits are actually kind of boring and there’s no Lego better than a giant bucket of bricks and an imagination. Coherence is strictly for grown-ups.)

From Atomic Design to full stack design systems

This approach is not unlike the Atomic Design approach I mentioned earlier. Atomic Design will tell you to take some of your basic elements (label, input, button), stick them together, and call it a molecule. Then you can reuse that molecule again and again. Further, you can stick some molecules together to form a reusable organism.

The problem with every real-world example of a system like this that I’ve encountered is that they remain wilfully unaware of the product being built.

When you’re creating a bespoke Design System for a specific product, you have the opportunity to not just group common UI elements together, but to actually represent your core product concepts at many levels. I call this a Full Stack Design System.

Here’s what a Full Stack Design System might consist of:

• A shared conceptual model of your product. This is the diagram you’d draw on a whiteboard to explain how your product works at a system level. What are the main objects in your product? How do they interact?
• Shared language that everyone on your team uses to refer to your objects. Remember, words matter. If designers, engineers, and support people all use the same word to describe the same thing, so much organisational fogginess goes away. Elizabeth, our Content Strategy Lead here at Intercom, calls this using “the same language from code to customer”.
• Shared design resources to quickly create mockups that accurately reflect our design systems. This often takes the form of a single Sketch file that everyone has access to. The file contains a Symbol for each object, and often multiple variations for displaying the same object at different sizes or in different contexts.
• Shared code components that allow engineers to build these components and their variations, often with a single line of code. There should be a 1:1 mapping of the objects in Sketch and in our codebase.

Most importantly, there’s a unifying thread through all of these levels. A ‘Conversation’ in Intercom – one of our core objects – is the same, very specific thing whether it’s being sketched, described, designed or coded. If we want to change that object in some way, we can consistently change it across all levels. Teams are locked in and ambiguity disappears. In this way the sum of the system becomes much greater than the parts.

Here are examples of possible objects in products you know:

• Facebook: Friend, Post, Message, Event, Page, Group.
• Airbnb: Listing, Host, Guest, Trip, Experience.
• Slack: Team, Member, Channel, Message, Reaction, Thread.
• Intercom: Customer, Teammate, Message, Conversation, Article.

In each case, the objects don’t just describe a UI widget. They mean something very specific in the context of the product.

A Full Stack Design System extends the component-based ideas of Atomic Design to be specific to our product and directly relevant to everyone involved in making it.

A real-life example

To illustrate, let’s look at how we use the Conversation object when building Intercom.

First, we have an overview of the Conversation object in Build, an internal website that explains what each object is and how it interacts with the wider system:

Each object listed in Build has a nifty link that opens that object directly in our Designers’ shared Sketch file:

And another that opens the code snippet used by engineers to implement the object:

Here’s how we describe a Conversation in our publicly-available Glossary:

Our support teams and help doc authors consistently use the same language too:

At all levels of this stack – system model, user interface, implementation, documentation – we aim to capture the structure of our product in a consistent, meaningful way.

Why this works for Intercom

This idea is central to our design success at Intercom. We’re still a fairly small company, yet we’re building multiple products that are used in many different and powerful ways. It would be very easy for us to slip into that The Pit of Complexity. Yet we aspire to swim against the tide and actually make our products more simple and elegant, even as we add to what they can do.

Our strategy for achieving this is to use this small set of core objects that we can chain together into specific workflows. Every time we build something new at Intercom we ask ourselves how we can solve the problem using the materials we already have. New concepts naturally creep in as needed, but they are introduced consciously and we’re diligent about merging concepts whenever we have the opportunity.

The product stays lean and precise despite growing in capability. We can polish the hell out of our core objects so that they get better over time, and those improvements show up in many places across all of our products. Reuse allows us to move faster.

And most importantly, our users don’t have hundreds of concepts to keep in their heads all the time. When they adopt a new Intercom product, it already feels familiar because it’s made up of the same stuff.

The system works

So that’s how to keep your product out of The Pit. Think of what you’re designing not as a series of screens but as a system of objects, and then realize those objects at every level: conception, design, build, marketing, support.

I’ll be honest: I don’t even know if this is going to fully work. I’ve tried, and I honestly can’t think of any products that are both powerfully flexible and elegantly simple – suggestions welcome! Maybe it’s impossible and The Pit awaits us all. But that doesn’t seem like a great note to end a blog post.

What’s more, I don’t want to believe it’s true. This very challenge is what’s uniquely interesting to me about doing large-scale design work at a growing product-oriented company.

The early signs are promising. In all types of complex systems, from codebases to architecture, clarity comes from understanding first the whole as a series of modules, then zooming in to think of each module individually. John Gall wrote in his eponymous law that:

A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

Complex systems can be designed, but to do so you must first sketch the outline. Only then can you start filling in the detail.

Similarly, to evolve and improve a complex system you must keep the overall system in mind at all times. We already know the alternatives don’t work: tacking on new ideas piecemeal, resisting the need to grow the product, allowing many competing approaches to co-exist. We need a technique for holding both the micro and the macro in our tiny human skulls at the same time. Christopher Alexander, who wrote the book on designing with systems, wrote that:

Nowadays, the process of growth and development almost never seems to manage to create this subtle balance between the importance of the individual parts, and the coherence of the environment as a whole. One or the other always dominates.

Growing a product is an eternal balancing act. Applying a Design Systems approach to every level of your product – not just the UI – will help you to maintain control over that balance and prevent any one force from dominating too much.

The post The full stack design system appeared first on Inside Intercom.

from The Intercom Blog https://blog.intercom.com/the-full-stack-design-system/

Somewhere in the depths of Netflix, there’s a team whose primary responsibility is to make sure the bits move quickly. As Netflix serves its customers by streaming video, they ensure that video data leaves the server in a prompt and efficient manner.

This team is all about the performance of the servers and the networks. They talk in terms of bandwidth, throughput, latency, reliability, and efficiency. They are comfortably deep in the weeds of how all the data moves.

The members of this team are performance engineers. They are architecting, engineering, and maintaining the performance of a very complex system. It occupies all their time and then some. In systems engineering, there are few jobs more technical than these.

And yet, at the very moment that a Netflix viewer’s video stream stops and that spinning animation appears, indicating the player is now awaiting more data, these engineers make a dramatic change. They become user experience designers.

They made decisions about the system. Those decisions affected the bandwidth, throughput, latency, and reliability. Those decisions had a dramatic affect on that viewer’s user experience. They didn’t think of themselves as UX designers, and I’m betting no one else in the organization did either, yet, here they are, affecting the UX in a dramatic way.

When someone influences the experience of the user, they, in that moment, become a user experience designer. Their influence may not be positive. Their knowledge of UX design principles may be small, even non-existent. Yet, because they affect the experience of the user, they are a designer, albeit an unofficial one.

Unofficial Designers Are Essential For Most Organizations

Design is hard to define. We know it when we see it. (We certainly know poor design when we experience it.) Yet, describing it has been elusive.

Years ago, I stumbled upon a definition I’ve become quite fond of:

Design is the rendering of intent.

A designer has an intention to change the world in some way. Maybe they intend to help people be more productive, more delighted, more comfortable, or better entertained. When they are designing, they are making their intention real in the world. They render their intent.

Netflix’s performance engineers have a strong intent. Their goal is to ensure the viewer’s watching experience is never interrupted because the network and servers can’t keep up with the video. Every decision they make is to render that intention in their viewer’s world.

Performance engineers aren’t the only folks whose decisions influence the experience of the users. When product managers decide on features or when database developers decide on the data model, they are making decisions that affect how the design will work. Make the right decision and the design will work well for the users. Make a different decision and the design may feel clumsy and frustrating.

While organizations may have a team of designated designers, that doesn’t prevent all these other people from making design decisions. Under the guise of maintaining control, some organizations make a concerted effort to wrestle the design decisions out of the hands of these unofficial designers.

Yet, for most organizations, there are too many decisions and there are too few official designers. They can’t make every decision about performance, functionality, or database modeling. In the end, the official designers need the unofficial designers to make good design decisions on their own.

The Convolution Of Reward Systems

What seems to frustrate the official designers most is when those unofficial designers are making poor design decisions. Because the unofficial designers don’t know the ways of good design — for example, they don’t necessarily know to put the user first — the odds they’ll make the right decisions are slim.

To make things worse, the cadre of unofficial designers are often rewarded for something other than making the user happy. They are rewarded for achieving business goals, such as shipping on time, reducing costs, or for providing a list of competitive advantages.

Those amiable goals can conflict with a great user experience. Sometimes it takes longer to develop a great user experience, because you have to spend the time researching and learning what the users need. It can cost more to do all that research and iteration, instead of building the first thing to come to mind. And more features often increase the complexity of the product, thus diminishing its value to the user and raising support costs.

These unofficial designers fall into the trap that every designer falls into: they fall in love with the idea they’ve come up with. A product manager may fall in love with their idea for a new feature, because it seems cool and shiny. Not because it solves any problems the users have.

Great designers don’t fall in love with their solutions.

Great designers fall in love with the users’ problems.

Usually, it’s not ego that drives them to falling in love with their ideas. It’s that they have little-to-no exposure to the problems the users have. Without exposure to users, they have no way of validating their idea. Without the data from any sort of validation, all that’s left is opinion. And there’s no way to sway an opinion in the absence of data.

The reward systems make this more convoluted. In many organizations, delivering features is rewarded more than solving customer problems. Product managers, like everyone else, naturally gravitate to what they’re rewarded for.

This means those people who set the organization’s reward systems are also influencing the design. They’ve rendered their intention on the organization, making decisions that affect the outcome of the design.

The only way we’ll get better decisions from the unofficial designers is to work to create a reward system that puts solving the customers’ problems first. And to do that, we need to bring the organization as a whole up to speed on what the customers’ problems are.

Experience Maps Help With Understanding The Problem

Since the earliest times, humankind has used maps to communicate. Maps show where we are and where we want to be. They communicate the relationships between the elements they contain.

In design, we map experiences. These maps take different forms. Customer journey maps show how our users progress through our design, often highlighting the frustrating moments alongside the delightful ones. Service blueprints describe how the organization interfaces with the customer, often revealing the invisible steps that happen for every action a customer takes. Empathy maps explore what our customers see, think, say, and feel, as they interact with our designs. And system relationship maps describe how the underlying parts of the system interact with each other to produce the users’ total experience.

It’s with maps like these that we explore the users’ problems with the unofficial designers and their reward-setting stakeholders. We can show where our customers are receiving less-than-intended quality, where our designs create frustration, and how those issues change the way people interact with our designs. We can show when customers call support (thus driving up costs), users avoid features (thus reducing value), or potential customers turn away (thus lowering sales).

Looking at someone else’s map can work. However, we’ve found a more effective approach is to have these unofficial designers and reward-setting stakeholders participate in making the maps themselves.

Map Making is Powerful

When we involve these essential influencers in the process of collecting the data and representing it on the map, they are more likely to “get it.” They see where the customer pain is coming from. They see how the decisions they’ve made have created the outcomes we’ve gotten.

It’s that act of putting pen to paper that is most powerful. To be the one who draws the point where users are frustrated makes them want to draw it elsewhere. And the way they draw it elsewhere is to change how they make decisions.

It’s simple, really. Many times we’ve seen tremendous change by just asking the highest paid stakeholder in the room to draw what we’ve learned from our research. They come away from that mapmaking experience with a strong motivation to change the map going forward.

For the first time, those unofficial designers and their reward-setting stakeholders are seeing how their decisions turn out. The stakeholders see how the rewards are pushing the organization in the wrong direction. Shared knowledge emerges and a common sense of the customers’ problems drives future thinking.

All because we gathered everyone together to make a simple map.

We’ve invited Jim Kalbach, author of the fantastic book Mapping Experiences, to teach a full-day workshop on creating different kinds of maps to engage stakeholders and unofficial designers. Join us at the UX Immersion: Interaction Conference on May 3 in Portland, where you’ll learn the techniques for effective experience mapping. See exactly what you’ll learn.

---

The Power of Experience Mapping was originally published in UX Immersion: Interactions on Medium, where people are continuing the conversation by highlighting and responding to this story.

from Stories by Jared M. Spool on Medium https://medium.com/ux-immersion-interactions/the-power-of-experience-mapping-212ba81e5ee?source=rss-b90ef6212176——2

from CoinDesk http://www.coindesk.com/building-blockchain-researchers-arent-giving-internet-sized-ideas/

from InVision Blog http://blog.invisionapp.com/designers-developers-collaborate/