Design & Development - The Magic Happens Here -

Editor's Notes

• #3: (*) During WWI, warfare was in transition. Cavalry & cutlery was were giving way to mechanization and weapons of more widespread destruction. (*) Trenches outlined the battle front across Belgium, France & Germany. (*) Between the trenches was a “No Man’s Land” littered with mud, mines, barricades and barbed wire. Those trenches defined the war. (*) Interestingly, around Christmas In 1914, stories of impromptu cease-fires were being reported. Enemy regiments climbed out of their trenches, exchanging gifts, singing carols, worshipping together and (*) even playing the occasional soccer game. As the war progressed these incidents decreased but for a while, in a few places, people were talking together, fostering a camaraderie in spite of their differences but based on their shared experiences. (*) For a little while, they did what many would have called impossible.
• #4: When I was asked to come speak here I knew what I DIDN’T want to do is give a talk on my view of the mobile world from the UX standpoint and talk about how great it is and how it’s different from yours because, do you really care? So…what the hell do I talk about? What could I talk about that was useful; that offered insight without being a lecture about UX? Is there something that we do at Bottle Rocket that is remarkable? We have a pretty impressive track record so there MUST be something. Then it occurred to me. I realized the most remarkable thing we do is very simple as ideas go but it’s remarkable because in nearly 20 years of Web and now Mobile design, I seldom see it in the wild. Whether you work in a large organization or you’re a one-person show. Design and Development can often be at odds even if you’re responsible for both. For the purposes of this discussion though we’re going to avoid schizophrenia and consider the roles as separate people or groups in an organization. (*) There’s an intersection that crosses disciplines and that’s where the magic happens.
• #5: Whenever you have opposing factions, you usually have two prevailing dynamics. It isn’t usually personal but the cat is, we don’t immediately trust people who don’t think like we do. We don’t trust them to consider; let alone protect what’s important to us. How can THEY understand the value I bring. If I can, I’ll work around you. Us & Them. When that happens we’re not respecting the other’s discipline. We’ve all looked through that lens at some point. I’m not saying it’s always unjustified. Everyone deserves an even break and sweeping generalizations are never good but they get traction for a reason. Here’s what happens? “Those bastard fluffy designers have no concept of what it takes to create this stuff.” “Those bastard propeller-head developers have no imagination and they they can’t see past their computer screens.” Divisiveness creates work in silos Stonewalling creates churn and duplication of effort Projects ship late if at all What does that mean to the work in the long-run? The resulting apps have no balance – they lean toward whomever has the most organizational clout in the room. That’s bad no matter which way it leans; development or design. Function without aesthetic and ease or vice-versa is half an app with a shelf-life measured in minutes.
• #6: How to you turn that around? It can happen. If two warring countries could could suspend distrust and disrespect - even real feelings of hate during what was then, the largest armed conflict in history, certainly a few app creators can manage it for little while. It doesn’t happen automatically. At first you’re really just trying to earn the benefit of the doubt. You need it just long enough to prove you ARE worthy of that trust and respect. You have to show it in return as well.
• #7: It doesn’t matter if no one focused explicitly on it or not. The first time someone uses an app, a user experience will occur; good or bad Don’t mistake me. If there’s an app, development had to happen too or there is nothing TO experience. Let’s talk about being deliberate about both; weaving them together so that the outcome doesn’t skew toward function that is difficult to use or aesthetics with no muscle behind them. Let’s start with something common to both disciplines…
• #8: Never underestimate the power of sitting down over a legal stimulant and having a good talk about objectives. Better yet, have a meal! Break bread with your enemy and refuse to discuss work. Put your phones away and visit. Find-out how they became a developer or a designer. What were the key moments that defined their careers. What do they LOVE about what they do. There’s something else we have in common…
• #9: When something special happens in an app that seems unexplainably wonderful, it’s magic. We love different apps for different reasons but at some point we had a moment when we experienced something brilliant and it could only be magic. We’re the people who create those moments. We make magic! Everybody wants it. We want to give it to them. Is there anyone here that doesn’t want their work to be loved? There’s a great quote from Adam Engst; He has a blog called TiDBITS and he wrote this in 2010…the [device] is that app. Switch to another app and the [device] becomes that app. If that's not magic, I don't know what is. (*)
• #10: One way or another we all have to cover this ground. It’s been labeled many ways but this is as good as any. We’re all aimed in the same direction. The difference between Dev & UX is that we get there in different ways. We even look for the same outcomes but to get there we interpret the journey differently. Business Rules: can be an outcome of workflow or simply map to APIs Business Goals: Looking good and supporting a brand image or a set of functional capabilities Platform Conventions: Constraints that will affect publishing or adherence/departures from guidelines Logic: UX use cases and technical use cases Risks; Adoption or abandonment or effort vs. time APIs: Tells you how something should be coded. It also tells you what can be added or removed from an experience. All these things have very specific but different implications to our disciplines. Anything on this list can be expressed as both a development use case or a design use case. We execute against the same dynamics. It’s the differences that gives an app dimension. It’s those multiple facets that support magic.
• #11: This is where it comes together. Here’s where the worlds merge and the foundation for trust and respect is established. At the outset of a project, there is a time when we have to learn all about what we’re building. We ask a lot of questions about the users, the business, legacy systems, the room for creativity, the need for new development. We learn the boundaries We begin to imagine what an app can be; what experience it should foster. The most important thing about this early timeframe is that, for JUST a little while, the laws of physics are on hold. This is the time to conceptualize without boundaries, to put ourselves entirely in the place of the user and only think about what will be cool for them. That’s what they care about. Notice that timeframe includes development. This is sometimes the hardest part because if you’re good at what you do, you’ve done some due diligence. You know some, if not all the constraining factors. but you have to control the urge to hammer these points home at first because, believe me, they’ll come into play soon enough . We indulge a kid’s imagination for a while because you want to preserve a sense of wonder. We need to be stewards to that same sense of wonder. Sometimes we even have to create it. True, what we don’t know can bite us in the ass but it can also reward us. This is where the opportunity to do something magical can live or die. Designers will respect developers who can support this idea and play along – the idea that for just a little while, anything is possible. The most important thing here is that when all parties are in the conversation…they are IN the conversation.
• #12: That’s the key…The discussion is for everyone. Some of the most elegant ideas for apps I’ve worked-on came from developers or QA. We use apps all the time whether it’s productivity, games, creativity or research. We remember the little things that caught our eye. We bring (and we know our users bring) something called intellectual funding to apps, movies, books and games. This just means that an author, director or app creator bet you would know a few things before you showed-up and they are banking on that knowledge in hopes that you will understand certain things without explanation. Examples would be any movie sequel where there’s an expectation that the audience will know the premise. Things that are derived from other sources like comics or even a Disney ride. There are conventions that most people already understand; Westerns with white and black hats, a shoot-out, a school marm and a saloon. It’s the same with app features. Everybody has experiences both good and bad that left an impression. Good ideas can come from anywhere and anyone.
• #13: An idea or Innovation is, at it’s core, a simple thing: A new combination. When you see something innovative, what do you do? [head-slap] Of course! Why didn’t I think of that? That’s because innovation brings two known things together. They’re recognizable and familiar to you. It can be two physical things, two concepts or both. It happens like this: Two ideas collide. It might be an old hunch you’ve carried around for years that meets up with something you saw today. It may be commonplace but for some reason you combine them in your mind. The trick is to capture that combination so you can hold it up later and examine it some more, turn-it over a few times and wrestle with it. You may be on to something or you may toss it out; (often the latter) but at least you tried to carry it to a conclusion. A little story. There was a woman working in fabrication plant. Her job was to use a large metal plunge-cutter to stamp-out die-cut sheets of metal. The cutter would raise up about 6 inches, she would slide the metal into place and using two hands, press two buttons that brought the blade down and stamped-out the sheet. The two buttons guaranteed her hands were clear of the blade. Rinse and repeat. Her day was measured by the number of sheets she could stamp-out in a shift. Over time, she noticed two things. As she went, so did the assembly line. The line produced as quickly as she could go. The metal sheets were very thin. She asked one of the maintenance guys to adjust the cutter so that it only rose about an inch instead of 6. Her output nearly doubled, the line’s output nearly doubled. Her innovation; combining the concept of efficiency with the physical adjustment to the machinery made her company more successful. Sometimes innovation requires a little more convincing. This is a segment from an HBO Special called “From the Earth to the Moon” It was produced and hosted by Tom Hanks in 1998. This particular episode was about the design of the Lunar landing craft called the Lunar Excursion Module or LEM. Here’s a short segment about a new combination. See if you can tell what it was.
• #14: Keep in mind, this whole endeavor was innovative. They had to design the tools to create materials used to build the LEM and design the tools to test it. What was the innovation here? The need to shed weight The realization that people will be working in 1/6 gravity and they didn’t need to sit down; “Legs are great shock absorbers” They pushed the idea by prototyping so the exec could “see it”. You may come-up with something innovative on a daily basis. Innovations are often small things. Little innovations can pave the way for bigger ones.
• #15: Did you see how certain the exec was about the need for windows and seats? I wish I had a nickel for every time I was absolutely certain of something at the beginning of a project only to toss it out in the face of good evidence. This is why “play-time” is important. Give yourself the opportunity to test drive ideas – both good and bad. Allow for failure and you allow for surprises.
• #16: The important thing is not to be afraid to push what seems like a good idea. If you don’t, you’ve just staked out the safe-ground which is where mediocrity lives. You’ve killed the magic before it got a chance to show itself. This is true for both Developers and Designers. Don’t fall back and build what you’ve already built. Don’t fall back on design that’s already been designed.
• #17: Yes there are some cold, hard truths about projects that we’ve been happily ignoring. There’s this guy. He’s the main stakeholder and unless the app we’re building will guarantee success in way he can get his head around, he’s going to keep a pretty tight rein on Time & Money. He has a hard time with the notion that a great experience is good business because it doesn’t play out nicely in an algorithm that shows a guaranteed increase in revenue or a decrease in costs. Sometimes, what the user wants can’t be shown to directly impact these things. Sometimes you’re told to find a way to get the user to want what the company wants which may not be the same. What can I tell you. Sometimes it just sucks but…if you have a smart advocate in another stakeholder, someone this guy trusts or you can become the guy he trusts (if you’re not already), you can get him to suspend disbelief just long enough to breath life into a great idea. Maybe you can even demonstrate it to him so he can see it in his mind and want that magic. Sometimes this is where you come-in…
• #18: Designers are valuable if we make you look cool or if we just shut-up and color. We suffer from the fact that everyone thinks they can do the job of an art director. Development has advantages that UX does not. You have an opaque skill set and with that comes built-in credibility. After-all real work isn't happening until someone is writing code ammaright? Nobody looks over a developers shoulder and tells them to make the code bigger, or change the color, move it more to the left, squeeze this image onto the main screen. If you support the ideas that make the magic, you dramatically increase the chances of bringing it to life.
• #19: Why is the magic so important? We’re seeing a shift. Just like we saw a shift from hand-drawn design to computer graphics, from Client-server SW to internet apps, from desk-tops to mobile, In each case, technology led the way…initially, until people began to take that as a given, then they looked to the experience. We’re about to see a shift from devices to actions. The Internet of Things won’t be about the internet or even things. It will be about ubiquitous access to information, the casual ability to set features and functions in motion with a gesture or simply by standing close enough to something. It won’t just be coupons pushed to your device in a store, it will be collaboration between people, services, and profiles - profiles you created that self-edit over time to become experiences unique to you. It’s going to seem like magic and it will become increasingly simple for users. BUT…everybody in this room knows… simple is hard. The only way to make the magic happen is if the different facets and varied perspectives and deep expertise of developers and designers alike share a balanced approach to solving problems and dreaming-up solutions.
• #20: Why is the magic so important? We’re seeing a shift. Just like we saw a shift from hand-drawn design to computer graphics, from Client-server SW to internet apps, from desk-tops to mobile, In each case, technology led the way…initially, until people began to take that as a given, then they looked to the experience. We’re about to see a shift from devices to actions. The Internet of Things won’t be about the internet or even things. It will be about ubiquitous access to information, the casual ability to set features and functions in motion with a gesture or simply by standing close enough to something. It won’t just be coupons pushed to your device in a store, it will be collaboration between people, services, and profiles - profiles you created that self-edit over time to become experiences unique to you. It’s going to seem like magic and it will become increasingly simple for users. BUT…everybody in this room knows… simple is hard. The only way to make the magic happen is if the different facets and varied perspectives and deep expertise of developers and designers alike share a balanced approach to solving problems and dreaming-up solutions.