Foundation Adopts CSS Grid, Launches Building Blocks





If you don’t write a lot of CSS yourself, you might think of CSS Grid as that thing Rachel Andrew keeps tweeting about. Well, it’s a whole new system for layout, and Zurb is apparently following her feed. So are most browser vendors.

At the time of this writing, CSS Grid is supported in the following browsers:

  • Chrome. Enabled by default since version 57.
  • Firefox. Enabled by default since version 53.
  • Internet Explorer. Enabled by default since IE10
  • Opera. Enabled by default since version 44.
  • Safari. Enabled by default since version 10.1.

That’s right. Internet Explorer got there first. It’s always a little awkward when that happens. Anyway, this info comes from Zurb themselves, who have announced the inclusion of CSS Grid in Foundation in their latest blog post. They have three reasons for the switch:

 

They want to stay ahead of the pack

Foundation has made its bread and butter by staying out in front of emerging web technologies, and giving web designers a reason to adopt them. If you want long-term legacy browser support, there are other frameworks for that. Foundation likes new things, and so do its users.

For them, this kind of fairly-early change is business as usual, rather than a radical departure from the norm.

 

CSS Grid is just better for big layout stuff

On the surface, it seems like Flexbox meets the same needs as CSS Grid, and the support’s already here. Well, it’s not as simple as all that.

While Flexbox was certainly an improvement on the old float-some-things-and-absolutely-position-others school of layout, it was not without its quirks. It lends itself more easily to allowing your content to define how it’s displayed. People seem to agree that it’s great for laying out content within the smaller elements of a page.

CSS Grid seems to have been designed with the larger page layout in mind. It makes it easier to create, manage, and “responsify” large layouts with fewer lines of CSS than other options. As easy layouts are sort of Foundation’s whole deal, it makes sense for them to incorporate CSS Grid.



 

They think we should ditch the page metaphor anyway

Zurb and many others seems to believe that the whole concept of the “page” is going the way of the dodo, at least for designers and developers. CSS Grid apparently works quite well with modular systems that treat layouts as a collection of reusable elements rather than a single page.

This way of thinking is especially popular with developers and designers who work on apps or very large websites more than five-page brochure sites. That includes Zurb. Go figure.

 

The way forward is paved with Building Blocks

Is this a good thing for web des… yeah I’m not even going to finish that. CSS Grid is taking off big-time. Foundation adopting it means that it is, for the foreseeable future, pretty much official: CSS Grid is a thing. And hey, it might take some getting used to, but I like it.

Besides, Zurb isn’t stopping there. The adoption of CSS Grid has led Zurb even further down the path of modular code. They just released a new set of pre-coded UI components that they’re calling Building Blocks. Building blocks will not be part of the Foundation core. They’re extensions. Download them, drop them into your project, and go.

So far, they consist of individual UI elements coded by Zurb — as well as code patterns created by the community — specifically to work with Foundation. Then there are curated sets of Building Blocks called Kits, that are designed to make it easier to build a specific kind of site. There are kits for eCommerce sites, portfolio sites, admin dashboards, and more.

Readers with eidetic memories may remember that Rafi Benkual talked about this very concept back in our interview with him and Kevin Ball. Well, they’ve done it. It seems Zurb is determined to make it easier for designers to focus on UX concerns and aesthetics without doing all of the grunt work themselves. And push the web forward.

I can get behind that.








from Webdesigner Depot https://www.webdesignerdepot.com/2017/04/foundation-adopts-css-grid-launches-building-blocks/

How Silicon Valley is (ab)using behavioral science and nudging

In an extensive review of The Undoing Project: A Friendship That Changed Our Minds, the book by Michael Lewis on the psychologists Daniel Kahneman and Amos Tversky, Tamsin Shaw provides a deeper criticism of the field of behavioral economics. He claims that behavioral science can be used quite deliberately for the purposes of deception and manipulation, and that this has been one of its most important applications:

Behavioral scientists claim to have developed the capacity to manipulate people’s emotional lives in ways that shape their fundamental preferences, values, and desires. […] Kahneman, working with others in the field of positive psychology, has helped to establish a new subfield, hedonic psychology, which measures not just pleasure but well-being in a broader sense, in order to establish a more objective account of our condition than our subjective reflection can afford us.

This new subfield has led the way in combining research in behavioral science with “big data,” a further development that has tremendously expanded the potential applications of Kahneman and Tversky’s ideas.

The manipulation of preferences has driven the commercialization of behavioral insights, he says, and is now fundamental to the digital economy that shapes so much of our lives.

He also describes how these techniques are being used in politics and even in military confrontation.

The idea of Libertarian Paternalism, in which the tools of the new behavioral sciences remain in the hands of benign liberal mandarins, has come to seem hopelessly quaint. In a more combative and unstable environment there must clearly be greater concern about our capacity to regulate the uses of behavioral science, the robustness of the fundamental research, and the political or financial motivations of any behavioral initiatives to be employed or countered.

Shaw concludes: “It is still possible to envisage behavioral science playing a part in the great social experiment of providing the kind of public education that nurtures the critical faculties of everyone in our society. But the pressures to exploit irrationalities rather than eliminate them are great and the chaos caused by competition to exploit them is perhaps already too intractable for us to rein in.”

Tamsin Shaw is Associate Professor of European and ­Mediterranean Studies and Philosophy at NYU and the author of ­Nietzsche’s Political Skepticism.

The post How Silicon Valley is (ab)using behavioral science and nudging appeared first on Putting people first.

from Putting people first http://blog.experientia.com/how-silicon-valley-is-abusing-behavioral-science-and-nudging/

Increase conversion with empathetic UX

Of 90% of digital businesses that fail, a whopping 60% of them fail because they built something nobody wants.

So, how can you increase your chances of success? Empathy is a good place to start. 

Being able to connect with your users and understand their emotions, goals, problems, and motivations will make you a better designer and a more receptive individual. That’s invaluable in the world of product development.

Related: Building user empathy within product teams

When we know our user’s key problem, we have a direction. When we have a direction, we have a purpose. 

The best UX designers have an uncanny ability to spot pain points and problems, but to do this you have to care—you have to truly want to make the environment around you as good as it can be. But doing that is much harder than it sounds. 


User empathy

Learning to empathize starts with you—it’s a personal journey. Really, we all do it to some level already. Here are some tips to help you smash through that empathetic barrier and think with more feeling.

Have an open mind

A closed-minded approach to anything reduces options and honesty. To truly empathize with your users, you need to learn to actually listen to them and stop judging. Stop picking out the feedback you want to hear—switch your ears on to everything you’re being told.

Users have the frustrating habit of requesting every feature under the sun. Most of these requests will fall beyond your product’s unique selling proposition (USP). Things like “I really want to be able to change the background color to pink!”, but feedback will include many issues, suggestions, and ideas that will be pure gold dust—amazing new opportunities to smooth your user’s journey through your product. You must learn to pan through the dirt to find the gold.

Take the time to see problems from all perspectives

Rarely is your line of thought the only option. And just because it’s yours, does not make it right. Stand up for yourself, but learn to stand in your user’s shoes and relive the issue from every side to truly understand the impact and frustration the problem is causing. Learn to do this and you’re well on your to way UX stardom.

  • How does this issue affect the user?
  • Does this affect some of our users differently from others?
  • Which users are most important to us?
  • How does this issue affect our goal and milestones as a business?
  • How does this issue affect our internal capabilities?



“Stand up for yourself, but learn to stand in your user’s shoes.”


Example: Joe is a power user and using your application daily, go Joe! Woo! He has a lot of data stored in your app and has run into an issue where he has to click through 30 pages of content to get to where he needs to be to carry out a task. Joe has to click 30 times to get to that content and he’s frustrated! You, on the other hand, only have 3 pages of content within the app, and let’s be honest—you’re not a power user.

You have not foreseen the issue and potentially would never come across it. You must step in to your users shoes and observe the issues that affect their path through your product.


User empathy

With that in mind…

Learn to accept what you’re being told

It might not be right, but we’re far too quick to discount information and feedback from others based on our ingrained beliefs. Listening is easy, but learning to process and act on what you’re being told is an art.

Reduce bias at every opportunity

Step outside of your favored decision and consider that, for whatever reason, you’re too close to a project, person, or task to be impartial. Bias can strike at any time, and it’s contagious. Just because you and your colleague spent 2 days working on a new user journey for your product, it doesn’t mean it’s going to work. You may have just discovered an approach that won’t—and that’s still valuable progress.

Edison had it right when he said, “I have not failed. I’ve just found 10,000 ways that won’t work.”

Ask the right questions when user testing

To empathize on feedback, you need to learn what your users really think. When user testing, the questions you ask or don’t ask are key. Effective questions are specific, clear, open ended (cannot be answered with yes/no) and do not lead the interviewee.

Let’s go through a good question scenario and a bad question scenario:

Here goes the bad question:

“Don’t you just love our new sign-up page? We do, do you? If you go to this page, then click here and scroll down to here you can see it… Well, wasn’t that easy to use?” 

Why is that bad?

  • You’re drawing focus to a new feature far too quickly when you should be setting them a task first, then stepping back to watch and observe.
  • You are swaying their opinion before you’ve given the user a chance to think for themselves which is super common and works against you! This is not about you but them.
  • And you are telling them where to find what you are testing when you should be watching and waiting to see if and how they can find it. 


Let’s rephrase that as a good question:

“Starting from the home page, please sign up for our product. Great, thanks! Did you encounter any problems when signing up? If you could change one thing when signing up, what would it be and why?”

Why are those better questions?

  • You’re starting with a task that is controlled. This enables you to step into your user’s shoes and observe things from their perspective.
  • You’re asking a question that is unbiased. You’re not there to persuade, but to observe their true behavior.
  • By carefully watching your users and asking them unbiased questions, you’re uncovering valuable insight that can be acted upon in confidence.


“Your product’s UX is linked to your own appreciation & acceptance of empathy.”

Validate your ideas

Empathy opens the door to potential opportunities because it enables you relate, but validation is key as it confirms your thinking and enables you to act and fix a problem.

Taking your idea to your audience and asking the right questions while keeping an open mind is key to qualitatively validating your idea successfully. If you ask loaded questions and go into any problem with a closed mind you’re going to struggle to work through the problem to find your real answer.


Share the love

You may be on a mission to empathize with your users, but don’t do it alone! Promoting an emphatic culture within your business is just as important. It’s not just on your shoulders to learn to think with feeling. The more empathy you can share with the people around you, the better. Designers, developers, product managers, content writers, and support staff all benefit from empathy.

Your product’s user experience is heavily linked to your own internal appreciation and acceptance of empathy, so learn to embrace it and all the benefits it will bring. 


“Don’t empathize with your users alone.”

If I make that sound easy, I’m sorry—it isn’t. We’re becoming more and more glued to our computer screens, engrossed in our work. That in itself makes relating and empathizing with the people, users, and colleagues around us in person a harder task to achieve.  

Here are some tips to get your team thinking with feeling: 

  1. Create visual personas of your audience and leave them around the office for your team to see. Attaching a name and face to your users shows they are real people which help others to relate.
  2. Openly invite all staff to user testing sessions with real users so they can see the issues they experience and the frustration this causes.
  3. Hold a roundtable meeting with staff to walk through the benefits of empathy within the workplace. Show the team how it helps you in your role.
  4. There’s a lot to be said for just sitting down and talking with someone. The people I look up to the most have always been able to listen, understand, see through the anger, excitement, sadness, or confusion and offer great feedback and advice. That rubs off on the people around you, so lead by example.

Get out there and start empathizing

Learning to empathize is at times exhausting and emotionally draining, but it’s such a valuable ability in life that enables you to listen, consider, and act with respect. Being empathetic means great things for your product and the people around you. From here on you can hopefully, carefully talk with your users and see problems from a new perspective. 

It’s important to mention that this won’t happen overnight. It’s a skill that needs to be practiced, and it improves with experience.

But as with all skills, the first step is to start.

Tom Starley
Tom Starley is a UX and UI specialist and founder. He’s passionate about increasing conversion and revenue for growing online companies through expert UX/UI design and consultancy. He has a passion for helping people embrace the benefits of design thinking.

from InVision Blog http://blog.invisionapp.com/ux-design-empathy/

Google’s Golden Krishna on designing screenless experiences

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.

Digit

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.

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/

Eye-Tracking Study: How Consumers View Google Search Results for Hotels



The way consumers view Google results pages related to hotel searches has changed significantly over the past few years, according to recent research from Travel Tripper.

The report was based on an eye-tracking study conducted using the Sticky platform. As part of the study, 100 consumers were shown desktop Google search engine results pages (SERPs) for three hotel names (Capitol Hill Hotel, Park Lane Hotel, and The New Yorker Hotel). Participants’ eye-movements were tracked as they looked at each SERP for 15 seconds.

In past studies, consumers tended to look at desktop SERPs in an F pattern: starting at the top with paid ads, then moving down to organic results, then across to the ads in the right column.

The rollout of new right column units by Google that display a hotel’s business listing and metasearch price results has changed this behavior, the analysis found.

Consumers now focus intently on the top of the page at the paid ads and hotel business listing. Organic results receive significantly less attention.



The researchers found that when looking at hotel SERPs, consumers tend to look at the paid ads at the top first, the business listing second, and then either the organic results or metasearch prices.

In addition to tracking eye movements, the researchers asked participants which links on the SERPs they would be most likely to click on.

More than half (55%) said they would click on a paid link, 28% on an organic listing, 10% on a metasearch link, and 7% elsewhere (e.g., on the hotel photo in the business listing).


About the research: The report was based on an eye-tracking study conducted using the Sticky platform. As part of the study, 100 consumers were shown Google search engine results pages (SERPs) for three hotel name keywords (Capitol Hill Hotel, Park Lane Hotel, and The New Yorker Hotel). Participants’ eye-movements were tracked as they looked at each SERP for 15 seconds.







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

English Doesn’t Have a Word for This Color, but Japanese Does

In English, we might call the color above “sky blue,” or perhaps just “light blue.” But in Japanese, it’s not blue at all. It’s its own color: mizu. It’s perceived as a unique hue, as GOOD reports, much like we think of red and purple being unique.

Japanese researchers in Tokyo and Kyoto, and Ohio State University researchers in Columbus asked 57 native Japanese speakers to look at color cards and name the colors they saw in order to get a better idea of how many distinct, base colors the Japanese language recognizes. As they write in the Journal of Vision, they found 16 distinct color categories.

The 11 main, base colors named by most participants were equivalent to colors found in the English language: black, white, gray, red, yellow, green, blue, pink, orange, brown, and purple. Others were unique to Japanese, seen as distinct colors in their own right: mizu (meaning “water,” a light blue), hada (meaning “skin tone,” a peach), kon (meaning “indigo,” a dark blue), matcha (a yellow-green named for green tea), enji (maroon), oudo (meaning “sand or mud,” a color we’d call mustard), yamabuki (gold, named after a flower), and cream.

The color terms gathered through the study. The taller the column, the more subjects described the color using that word. (All the colors were named by at least four participants.) Image Credit: Kuriki et. al,

Journal of Vision

(2017)

 
Mizu, in particular, stood out as a distinct color. While not everyone in the study identified dark blue as kon, mizu was almost universally recognized by the interview subjects. Because of this, the researchers suggest that it be recognized as its own 12th color category in the Japanese lexicon, added to the language’s standard color categories of red, blue, green, etc. (the ones that English speakers would find familiar).

The existence of these colors doesn’t necessarily mean Japanese is more sensitive to color differences overall compared to other languages—it doesn’t have names for some colors we can identify in English, such as magenta or lime.

“The study of color naming is fundamentally the study of how words come to be associated with things—all things that exist, from teacups to love,” Ohio State optometrist Angela Brown explains in a press release. “The visual system can discern millions of colors,” she says, “but people only describe a limited number of them, and that varies depending on their community and the variety of colors that enter into their daily lives.”

[h/t GOOD]

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

The full stack design system

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
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
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
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
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
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.

Intercom world tour 2017 banner ad

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/

The Power of Experience Mapping

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

Building ‘The Blockchain’: Developers Aren’t Giving Up on Big Ambitions

Even as bitcoin’s block size debate rages on, enterprising developers are looking beyond the infighting to focus attention on what’s ahead.

Adem Efe Gencer is one such developer. A research assistant at Cornell University‘s center for blockchain and cryptocurrencies, he believes the tech will come to be used on a broad scale to track everything from land records to deeds, fine arts and even precious metals.

But as Gencer explained, if we put each each and every asset on its own blockchain, we risk splitting the mining power that secures these transactions and their history, thereby reducing the security of the platform. Putting everything on one blockchain, he countered, will lead to cluttering.

So, how will blockchains handle all of these multiple assets? Should we have dedicated chains? Or is there a better way?

At the Financial Cryptography and Data Security conference in Malta yesterday, Gencer offered a solution, outlining an approach called “service-oriented sharding”.

Currently implemented on a platform called Aspen, sharding is basically a way of splitting data into parts, and then storing those parts across multiple databases for better throughput.

Gencer explained that service-oriented sharding applies that same idea to blockchains, so that transactions for different assets run on independent subchains. Users only keep track of the subchains they are in, and mining is combined.

Gencer told CoinDesk:

“We want to shard the blockchain with respect to services, so that each shard contains the transactions of only the related service, but not the other services.”

Sharding for tomorrow

Today, Aspen is designed to run on bitcoin-NG, a protocol for scaling bitcoin originally developed by researchers from Cornell.

Introduced in 2015, the idea was to break up certain functions of block creation in what was then one of the more radical proposals to increase network performance.

Still, Gencer said his sharding idea could just as easily be applied to bitcoin, ethereum or another blockchain protocol, as it simply re-orders how data is stored while retaining the same blockchain structure.

“In terms of mining, this change will have no effect,” Gencer said.

He believes that sharding is the future of blockchains, but points out that it is not easy to do. If you naively try and get rid of some part of transaction history, a blockchain will lose its tamper-resistant, immutable structure.

With Aspen, he said, we can maintain all those properties while requiring less computing power and providing un-fragmented, unified security.

Nodes for the masses

Gencer was not the only one at the conference examining a future where every single car and property is being traded on a blockchain.

Dmitry Meshkov, a researcher at distributed systems firm IOHK, presented yet another idea for making blockchains more manageable, proposing a way to solve what he called the problem of “big state”.

The problem as described by Meshkov is that you can’t store an entire copy of a blockchain on commodity hardware. What’s more, he explained, you don’t need all of that data to validate a single transaction anyway.

If Alice wants to give some asset to Bob, you only need to know whether or not Alice has enough tokens to allow a transaction to go through.

Meschkov presented a solution called “cryptographic authenticated data structures” as a way to verify transactions more cheaply. Essentially, the approach adds a proof with a transaction, so you know with certainty whether a transaction is valid, or not.

The solution, he says will reduce the memory requirements of a blockchain, enabling everyday mobile phone users to validate transactions.

Solutions like these promise to make blockchain more accessible to a broader community of users. They also bring into perspective that cryptocurrencies like bitcoin may one day take a backseat to other assets traded on a blockchain.

Disclaimer: CoinDesk received a subsidy to attend the Financial Cryptography and Data Security conference from the event’s organizers.

Image via Amy Castor for CoinDesk; Shutterstock

EthereumScalingTechnology

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

Designers and developers collaborate better with these 5 adjustments

It’s increasingly understood that design informs technology and technology inspires design. So why do most product development cycles still begin with design and end with development?


I’m a firm believer that the best products are made by bringing design and technology together at the outset. Creating an environment where the mindset considers both technology and design can reduce handoffs (and their inherent inefficiencies) and unleash the creative potential of both skill sets.

Related: Get over yourself—collaboration is the secret to great products

It’s with this collaborative approach that Work & Co has been able to launch products like Virgin America’s iOS and Android apps, a project that relied on an inventive technical solution in order to bring our design vision to life.



Designer developer collaboration

The value of collaboration pays back in spades, so we wanted to share 5 ways to start building a team that thrives together—and builds better products.


Act as one team

We work as one integrated team from the start. This includes our clients, who are often involved in regular reviews and standups. We don’t wait to validate feasibility or understand what’s possible. Instead, we integrate business, design, and technology perspectives into projects from day one.

We recently created an app for a leading video platform that would not have been possible without this approach. The concept revolved around an innovative color sampling technology that could adjust the color of the UI to match the video in realtime.


“Integrate business, design, and technology perspectives into projects from day one.”


To test the idea, the team—including the designers and product managers—immediately began prototyping the concept. Doing so let them understand whether color shifts had to be quicker, slower, or timed a certain way. We saved time and validated faster than a process where wireframes and PSDs get handed down the line. It also means that when it comes time to develop it, we know the true design intent.

By removing handoffs, there’s none of the usual finger pointing for why something may not have worked. We continually refine it together, as one team, with one shared objective.

Which brings me to my second point:

Include developers at the onset of every project

In many organizations, developers are excluded until it’s time to develop design concepts.

But developers can validate designs and uncover technical considerations that might cause trouble down the road (or be an exciting new territory).

A developer’s insight is essential knowledge for the success of any project. Without this perspective, creative teams risk investing in ideas that can’t be implemented as envisioned. Bringing technology into the design process can uncover new ideas while ensuring concepts get delivered on.


“A developer’s insight is essential knowledge for the success of any project.”

To further tighten collaboration, developers and designers don’t sit by discipline. We sit side-by-side by project team. We discuss each other’s work as we go, not just during major reviews. The result is shorter feedback loops and products that are better thought through.


Designer developer collaboration

Image courtesy of Work & Co.

Build an environment of open communication

Open dialogue helps everyone on the team stretch thinking and explore new ideas. Developers get involved in early design reviews. Designers keep refining as we build. By breaking down barriers, we create an environment where each team member seeks the feedback and ideas of others.


As one of our design partners says, “respect is the ultimate currency.” Our teams have to trust each other, and respect everyone’s opinions. This enables more constructive conversations throughout, and alignment towards the same goal.


Designer developer collaboration

Image courtesy of Work & Co.

Get into the habit of experimenting

We want to help our clients take bigger risks and launch more innovative products, but we also have a responsibility to ensure greater likelihood of success.

We’ve found that by experimenting at the outset, we can more rapidly identify which strategies will work. We constantly iterate and try new ways to solve problems. As a result, we produce dozens of concepts and prototypes, often within the first few weeks of kicking off. For the video app we conceived, we prototyped over 75 interfaces and interactions before arriving at the final solution.

This approach allows us to run highly targeted experiments, whether they be related to UX, technical feasibility, or any other aspect of each product.

Put energy into prototyping over presentations

We start prototyping as early as week one in a project. Working as one team means we can limit presentations in favor of reviewing in-progress prototypes. We take the time and energy that often gets funneled into presentations, and instead run user tests or get clients to interact with a functioning product. The result? Designers and developers collaborating on the product within the first week, instead of months down the line. On average, we’re delivering at least one prototype within the first month of kicking off a project.

The next time you’re ready to kick off a new project, spend some time really evaluating the perspectives and expertise you bring into the process and how talent will work together. Can you minimize handoffs and expand communication outside of formal reviews?

The investment in these adjustments will lead to happier, more productive teams—and better digital products.

You’ll love these posts, too

Oliver Dore
Oliver specializes in UI and web application development, leading front-end architecture at Work & Co. He has launched several high-profile and award-winning projects, including a fully responsive client-side booking and management engine for Virgin America, a beautiful reimagining of the Four Seasons Hotels & Resorts site, and a B2B resource site for Google. Most recently, Oliver lead front-end development for Aldoshoes.com.

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