What if there was a better way to use our time, energy and resources? How much better would our final products be if we spent what valuable time we had on real design thinking and execution? We can give our clients much greater value for money with only a small change in our perspective and a big change in our process.

In essence, I’m talking about designing, or as Dan Mall suggests, deciding in the browser. Instead of creating a series of disposable deliverables, such as Axure prototypes and OmniGraffle wireframes, we should consider an evolutionary process, from sketches to the final website. Everything we make or do should move us towards creating a final product with as little waste as possible.

Enter prototyping in code, using the faithful web browser.

Prototyping in code, in the browser, is scary stuff to many designers. It’s something developers do, not designers, which is somewhat at odds with where the Web is today. With the proliferation of mobile devices and responsive design gaining significant traction, along with the increasing maturity of web typography, designing in the browser instead of on static comps is becoming a matter of necessity. As Cennydd Bowles puts it, “designers should be able to code to the level they require to produce excellent work. Usually that’s ‘some’, but not ‘lots’.”

Jared Spool, another proponent of designers knowing how to code suggests “you’ll better understand the medium you’re working in…If you know what’s easy to code and what’s difficult to code, you can get your ideas implemented faster. Understanding what your medium does well and where isn’t as effective makes for more informed design decisions.”

“Whilst it’s good to know that HTML describes the structure of a page, CSS handles the layout and decoration, and JavaScript can be employed to add behaviours, there’s no voodoo involved,” says Alex Morris. “There are no hidden traps or anything that can go mysteriously wrong, what you write is what you get.”

Designing in the browser, with HTML and CSS, can produce prototypes that communicate the intent of a design more clearly and effectively than any wireframing tool ever can. Indeed, if we are to think about Responsive Web Design, traditional prototyping tools simply do not support this paradigm, pushing us towards designing in the browser, using browser-based technologies.

Whilst I’m a proponent of writing your own code, with the proliferation of frameworks such as Foundation, Bootstrap and Ratchet, and tools like Gridset, Mixture.io, Divshot and Jetstrap, prototyping in HTML, and across different devices, has become remarkably simple and accessible to a broad audience.

Through designing in code and in the browser, the users you’re testing the product experience on, or the client you’re presenting the product to, get to see and engage with it in it’s natural environment. Interactions, behaviours, typography, content and forms are all represented as they would be in the end product. By building prototypes in this way, closer to the product’s intended experience, the feedback you receive from users and clients will more accurately reflect that of the final product; no leap of the imagination is required.

Mobile has become an indispensable part of our daily lives.

With many competing business models, technologies and systems, a perennial topic of conversation is which approach is better for mobile: websites and webapps, written in HTML5 and related Web technologies, housed on the Web and run across multiple platforms, devices and browsers; or native apps, downloaded to devices and built upon and designed specifically for iOS, Android and other mobile platforms.

In the face of the paradigm shift from desktop to mobile, organisations must engage with mobile or risk losing customers and all-important revenue. But what of the options? We have 5:

1. Do nothing
2. Build a mobile website
3. Create a responsive website
4. Go native
5. Build a hybrid app

Do nothing

This isn’t an option we’d recommend, but there is a case for allowing your website to be rendered on mobile as it would on desktop. For devices such as Apple’s iPhone 5 and Samsung’s Galaxy S4, where users are used to panning and zooming, this may be acceptable. However, with this option you’re not optimising the experience for the user’s context of use, which is likely to negatively impact the user experience.

It’s difficult finding examples of this strategy, but they could include Apple and Last.fm.

Build a mobile website

Built with the same Web technologies as responsive and adaptive websites (i.e., HTML, CSS, JavaScript and a server-side language), mobile websites and apps tailor the experience to the mobile device, rather than simply reconfiguring the same content a desktop user would see. These are the classic m-dot and t-dot websites that you often find. The main distinction here is that you’re building and maintaining two separate sites: one for desktop and one for mobile.

Mobile websites work across any device that uses a modern Web browser such as Safari, Chrome and Opera, meaning access is relatively universal and cross-platform. As a consequence, mobile websites are often limited in functionality and user experience by what support is provided by the mobile browser and platform. Much like responsive websites, mobile websites won’t have access to device-specific features such as Near Field Communication (NFC), the camera and motion sensors, or the device’s native user experience.

Since mobile websites can be accessed by a broad range of modern mobile devices, this maximises the potential audience, but arguably less so than with responsive websites.

Popular examples of mobile websites include YouTube (m.youtube.com), Twitter (mobile.twitter.com) and Facebook (m.facebook.com).

Create a responsive & adaptive website

Responsive and adaptive websites follow what is called the One Web. One Web means making, as far as possible, the same information and services available to users whatever device it’s being viewed on, irrespective of whether that device is a feature phone, smartphone, tablet, smart TV, laptop, traditional desktop or other Web connected device.

However, One Web does not mean that exactly the same content is available in exactly the same form across all devices. This is where responsive and adaptive design comes into play. The context of mobile use, device capabilities, bandwidth issues and mobile network capabilities all affect the representation of the content.

Websites vary greatly in their focus. Some websites have a primarily mobile focus (e.g., location based services), some have a primarily mobile focus but have a complementary desktop aspect (e.g., for complex configuration tasks), and others have a primarily desktop focus but a complementary mobile aspect (e.g., for notifications and updates). Finally there will remain some websites and applications that have a primarily desktop focus (e.g., for large-scale imagery or high-definition video).

As experience designers we have a duty to provide the best possible experience in the context in which the website or service has the most appeal. Whilst websites may be more appropriately experienced in one context or another, it is good practice to provide a common experience, within the limitations of the device, and not exclude access from any particular class of device and/or user.

There are a significant number of websites that follow the responsive and/or adaptive paradigm, but fewer webapps. Examples of websites that follow this approach include Time, British Vogue, ISO (International Standards Organisation), Starbucks, Currys and Microsoft, whilst webapps include Mailchimp and Trello.

Go native

Native apps provide a fundamentally different experience compared to websites. Native apps are good when needing to take advantage of the platform’s hardware capabilities, affording the opportunity to use motion, environmental and position sensors, NFC, storage and hardware acceleration amongst others.

By following vendor-specific Human Interface Guidelines (HIGs), native apps offer a consistent user experience. However, that user experience will be different between different platforms (iOS, Android, Windows 8, etc.) since their HIGs are subtly, or sometimes extensively, different.

A fundamental limitation of native apps is the need to build an app for each platform on which you want a presence. Native apps aren’t cross-platform unlike websites. That can be a costly endeavour.

There are a plethora of native app examples that I could mention, but popular examples include Instagram, Facebook, Mint, Cut the Rope, Doodle Jump, Barclays and Skype.

Build a hybrid app

Hybrid apps are the middleman of the website or app debate. Built using products such as Appcelerator, Corona, PhoneGap and Sencha, a hybrid app is in essence a native application wrapping Web technologies (i.e., HTML, CSS and JavaScript). By building the app with Web technologies it’s quicker to develop and easier to publish to multiple platforms (i.e., Android or iOS) – develop once, deploy everywhere is the goal here.

As the app is essentially native you get access to hardware capabilities such as the camera and NFC but performance is often poorer than the fully native experience and the apps don’t often follow the platform’s HIGs.

Examples of hybrid apps include BBC Olympics, Tiny Terrors, tripcase, Kiva, TEDx and Maximuscle.

Which approach should you choose?

There are no absolutes in the argument between the Web, native and hybrid apps. What’s great about the Web is ubiquitous network availability, not that it runs within a browser. Websites are just services, and what you see in a browser is merely one possible interface to that service.

Frequently, but certainly not always, the best possible interface to that service is going to be a native app, not a Web app. That’s primarily because native apps have access to all that the web can achieve, but with the added benefit of being able to fully access the hardware on which the app resides.

Whilst current technology makes native apps a superior experience, this is only the case for as long as we’re stuck with current technology. We’ve all seen, and continue to see, the pace of technological change, so it follows that the Web experience on mobile devices will only get better and better. Indeed, the likes of Mozilla’s Firefox OS and Amazon’s Appstore are putting the Web and its technologies at the front and centre of the mobile experience.

Imagination is more important than knowledge. The purpose of human life is to serve and to show compassion and the will to help others. Creativity is the ability to introduce order into the randomness of nature. Life is an exciting business and most exciting when it is lived for others. You cannot do much about the length of your life, but you can do a lot about its depth and width.

The quote is an amalgamation of multiple quotes by Albert Einstein, Charles Baudelaire, Albert Schweitzer, Eric Hoffer, Helen Keller and Evan Esar.

The problem (and opportunity) is big…

While nearly 75% of users prefer a mobile-friendly site, 96% of consumers say they’ve encountered sites that were clearly not designed for mobile devices. This is both a big problem and a big opportunity for companies seeking to engage with mobile users.

Mobile-friendly sites turn users into customers

The fastest path to mobile customers is through a mobile-friendly site. If your site offers a great mobile experience, users are more likely to make a purchase.

• When they visited a mobile-friendly site, 74% of people say they’re more likely to return to that site in the future
• 67% of mobile users say that when they visit a mobile-friendly site, they’re more likely to buy a site’s product or service

Not having a mobile-friendly site helps your competitors

A great mobile site experience is becoming increasingly important, and users will keep looking for a mobile-friendly site until they find one that works for them. That means your competitors will benefit if your site falls down on the job (and vice versa).

• 61% of users said that if they didn’t find what they were looking for right away on a mobile site, they’d quickly move on to another site
• 79% of people who don’t like what they find on one site will go back and search for another site
• 50% of people said that even if they like a business, they will use them less often if the website isn’t mobile-friendly

Non-mobile friendly sites can hurt a company’s reputation

It turns out that you can lose more than the sale with a bad mobile experience. A site that’s not designed for mobile can leave users feeling downright frustrated, and these negative reactions translate directly to the brands themselves.

• 48% of users say they feel frustrated and annoyed when they get to a site that’s not mobile-friendly
• 36% said they felt like they’ve wasted their time by visiting those sites
• 52% of users said that a bad mobile experience made them less likely to engage with a company
• 48% said that if a site didn’t work well on their smartphones, it made them feel like the company didn’t care about their business

Takeaways

While the research confirms what we already suspected — that mobile users actively seek out and prefer to engage with mobile-friendly sites — it’s a sobering reminder of just how quickly and deeply users attitudes about companies can be shaped by mobile site experiences. Having a great mobile site is no longer just about making a few more sales. It’s become a critical component of building strong brands, nurturing lasting customer relationships, and making mobile work for you.

Click here to view the embedded video.

The MoMoLo debate was prescient since Facebook CEO, Mark Zuckerberg, said his company’s biggest mistake was using HTML5 for mobile development, sending shockwaves across the development landscape. The comment re-ignited the conversation over whether to go native or HTML5 and Web-standards based when building mobile apps.

The following are key tenets of the perennial discussion:

• Distribution – Native apps (based on iOS, Android, etc.) are distributed through app stores and markets controlled by the owners of the platform ecosystems. HTML5-based apps are distributed through the rules of the open Web: the link economy.
• Monetisation – Native apps come with one-click purchase options (a.k.a. in-app purchases) built into the platform. HTML5-based apps tend to be monetised through advertising and subscriptions. Native apps are often subject to a revenue share model, HTML5-based apps do not have that constraint.
• Network effects – Developers have to conform with platform’s rules. The platform’s market share, meanwhile, creates network effects and lock-in. If and when developers can build excellent functionality on the web using HTML5 and JavaScript, developers can cut the platform out of the loop. This will reduce the network effects of each platform (iOS, Android, Metro, etc.).
• Functionality – Right now, native apps can do a lot more than HTML5-based apps because they have access to core platform APIs. HTML5-based apps will get better, but not as fast as some HTML5 advocates seem to think since, arguably, it’s not in the interest of each platform to support a full HTML5 feature set any time soon. Some suggest taking a hybrid approach — wrapping HTML5-based apps with something like PhoneGap or Appcelerator’s Titanium — but that has it’s own challenges.

On the side of HTML5 based web-apps was Andrew Betts of the FT, Sam Arora of Keynote Systems and José Valles of BlueVia; on the side of native apps was Alex Caccia of Marmalade, Chris Book of Bardowl and Nick Barnett of Mippin.

Here is an overview of the two camps’ arguments (and apologies if I’ve missed a whole bunch of them; please feel free to comment):

Native apps

• The strength of native apps is in the business model, payment mechanism and distribution mechanism. App stores allow users to search and download apps with relative ease.
• The ‘footfall’ of users in the app stores is vast.
• In-app purchases and subscription mechanisms reduce purchase friction.
• The browser is a black box. If a bug exists in it, which prevents some functionality from working, there’s little you can do about it. Native apps on the other hand have access to the core API of the device, so limitations become the expertese of the developer.
• HTML5 and its sister technologies are still fragmented and ill-defined/implemented. The W3C are dragging their feet in ratifying the standard.
• App stores are no different from the traditional retail model found in shops such as Selfriges and John Lewis. They provide the mechanism to get the product to the customer, for a percentage.
• You can’t do decent high-end games in HTML5.
• You can’t deliver large amounts of content securely and in a way that allows for offline storage.
• The user experience of HTML5-based web-apps is hindered by needing to seek permission of the user every step of the way. Permission is implied when you buy a native app.

HTML5-based web-apps

• Native is monopolistic, which isn’t good for the user experience.
• HTMl5-based web-apps are device agnostic. If a new device or ecosystem emerges, the apps can be made to adapt relatively easily.
• Need to think about TV, kiosks, etc., which don’t have app architectures.
• There is a direct relationship with the customer. You’re not constrained by intermediaries, i.e., the device/ecosystem manufacturers.
• The Web succeeds by breaking boundaries; Native creates boundaries.
• If you subscribe to the notion that experiences should be branded to the organisation rather than device, we should standardise on a brand UI rather than a platform UI.
• Can cater for different input paradigms, e.g., gestures, keyboard/mouse, etc.
• We don’t need an imtermidiary with the Web (a la the traditional retail model of app stores).
• Security isn’t an issue in HTML5 apps, since we have the likes of online banking for desktop users.
• A more granular permissions can be applied to your apps, e.g., with localStorage.

Unfortunately the native camp won the debate. I say unfortunately because overall the debating wasn’t terribly coherent! Apart from gaming and the need to protect DRM’ed content, the supporters of native apps didn’t justify clearly why you should choose their paradigm. Similarly, the HTML5 camp didn’t make any profound arguments, but everyone largely agreed that Telefónica’s partnership with Mozilla on Firefox OS will be a proving ground to see if the Web can truly be set free on mobile devices.

But in essence, whether the app is native or HTML5-based, normal people simply don’t care! They want a frictionless experience using an app that satisfies their needs. They just want things to work. Like everything, you need to choose the best tool for the job.

What other people are saying

• HTML5 and native apps: the hybrid approach.
• Facebook for iOS goes native, waves goodbye to HTML 5.
• HTML5 vs. native apps: How to pick the right path.
• Why HTML5 is in trouble on the mobile front.

It’s one thing to talk about ‘rapid experimentation’ and ‘validated learning’ as abstract concepts. It’s quite another to see them in action, in a real-world setting.Eric Ries, Startup Lessons Learned

Nordstrom has put Eric Reis’ statement into practice by creating an ‘innovation lab’. The following video is an interesting case study on Lean UX and what Nordstrom are doing to embrace innovation.

Click here to view the embedded video.

Here are some of the highlights from the video:

• One week experiments. Innovation and agility is notoriously difficult for large organisations such as Nordstrom, but by working in one week iterations, the lab is able to break from the usual corporate slowness. In the video above, the team creates a usable product in one week.
• Simple and rapid experimentation. By having two iPads, the team were able to use one for testing, while another was loaded with the latest version of the software, cutting down the time needed to deploy each release.
• Innovation on the shop floor. By being on the shop floor, the lab is able to rapidly prototype and test their ideas with real users: the salespeople and customers. This also allows them to identify an opportunity and execute it extremely quickly. An example is when the team discover iPad screens can’t be seen in portrait when wearing polaroid sunglasses.

Arguably, innovation should flow through the veins of everyone in the company, but where that is unrealistic, or impossible, ‘innovation labs’ such as Nordstrom’s, are helping to extol the virtues of the Lean movement.

When I’m introspective about the last few years I think the bigest mistake that we made, as a company, is betting too much on HTML5 as opposed to native…because it just wasn’t there. And it’s not that HTML5 is bad. I’m actually, on long-term, really excited about it. One of the things that’s interesting is we actually have more people on a daily basis using mobile Web Facebook than we have using our iOS or Android apps combined. So mobile Web is a big thing for us.Mark Zuckerberg at Disrupt SF 2012

Emma doesn’t mention anything about how to defend yourself from your childhood toys, when they inevitably come to murderous life, or how to jump onto a speeding car, but the 22 ‘rules’ are nuggets of narrative wisdom from Pixar.

1. You admire a character for trying more than for their successes.
2. You gotta keep in mind what’s interesting to you as an audience, not what’s fun to do as a writer. They can be very different.
3. Trying for theme is important, but you won’t see what the story is actually about until you’re at the end of it. Now rewrite.
4. Once upon a time there was ___. Every day, ___. One day ___. Because of that, ___. Because of that, ___. Until finally ___.
5. Simplify. Focus. Combine characters. Hop over detours. You’ll feel like you’re losing valuable stuff but it sets you free.
6. What is your character good at, comfortable with? Throw the polar opposite at them. Challenge them. How do they deal?
7. Come up with your ending before you figure out your middle. Seriously. Endings are hard, get yours working up front.
8. Finish your story, let go even if it’s not perfect. In an ideal world you have both, but move on. Do better next time.
9. When you’re stuck, make a list of what WOULDN’T happen next. Lots of times the material to get you unstuck will show up.
10. Pull apart the stories you like. What you like in them is a part of you; you’ve got to recognise it before you can use it.
11. Putting it on paper lets you start fixing it. If it stays in your head, a perfect idea, you’ll never share it with anyone.
12. Discount the 1st thing that comes to mind. And the 2nd, 3rd, 4th, 5th – get the obvious out of the way. Surprise yourself.
13. Give your characters opinions. Passive/malleable might seem likeable to you as you write, but it’s poison to the audience.
14. Why must you tell THIS story? What’s the belief burning within you that your story feeds off of? That’s the heart of it.
15. If you were your character, in this situation, how would you feel? Honesty lends credibility to unbelievable situations.
16. What are the stakes? Give us reason to root for the character. What happens if they don’t succeed? Stack the odds against.
17. No work is ever wasted. If it’s not working, let go and move on – it’ll come back around to be useful later.
18. You have to know yourself: the difference between doing your best and fussing. Story is testing, not refining.
19. Coincidences to get characters into trouble are great; coincidences to get them out of it are cheating.
20. Exercise: take the building blocks of a movie you dislike. How do you rearrange them into what you DO like?
21. You gotta identify with your situation/characters, can’t just write ‘cool’. What would make YOU act that way?
22. What’s the essence of your story? Most economical telling of it? If you know that, you can build out from there.

He continues: The word creativity is frequently inflated by association, frequently appearing with overused, hype-laden words such as genius, brilliance, revolution and innovation. Hype mongers and creative intimidators throw those labels around like candy, scaring most people out of their own natural creative instincts.

But we can be saved from this plight by a few concepts and tricks, which Scott believes will help anyone be creative at any time:

• Start an idea journal. The rule is: any idea that pops in your mind, at any time, write it down. There are no inhibitions: any idea for anything goes in here. This will help you find your own creative rhythms, as over time you can note what times of day you’re more creative. Use a paper journal, so you sketch or draw things, but digital journals, like those on the iPad, can work too. Your idea many not be feasible right here and right now, but should be saved. Whenever you’re stuck, flip through your journal. You are bound to find an old idea you’ve forgotten about that can be used towards the problem you’re trying to solve.
• Give your subconscious a chance. The reason ideas come to you in the shower, or just before falling asleep, is that you’re relaxed enough for your subconscious to surface ideas for you. Make this easier: find time to turn your mind off. Go for a run, swim, jog, have sex, something that’s as far from your creative problem as possible.
• Inversion. If you’re stuck, come up for ideas for the opposite of what you want. If your goal was to design the best album cover ever, switch to designing the worst album cover ever. Five minutes at an inverted problem will get your frustrations out, make you laugh, and likely get you past you fears. Odds are high you’ll hit something so horribly bad that it’s almost good, and you’re inspired to switch back to your original goal.
• Switch modes. Everyone has dominate ways to express ideas: sketching, writing, talking. If you switch the mode you’re working in, different ideas are easier to find and your understanding of a particular idea changes every time you use a different medium to express it. This is both a way to find new ideas, and to explore an idea you’re focusing on.
  Take an improvisational comedy class. This will be easier and less painful than you think. It will teach you an entirely new way of thinking about the craft of creation. Most improve classes are structured around fun, party type games and teach you ways to combine ideas in real time: a powerful skill for any creator.
• Find a partner. Many people are most creative when they’re with other creative people they like. Partnering up on a project, or even being around other creative people who are working on solo projects, keeps energy levels high. It also gives you a drinking buddy when things go sour.
• Stop reading and start doing. The word create is a verb. Be active. Go make things. Don’t study it like accounting: you have to go do it, and make lots of mistakes, to learn anything about your own creative process. So get off the Web and start making something.

Will all that in mind, now’s the time to go and be creative.