The new Handcraft is here!

Category → Peers and Punditry

Stephen Anderson on wireframes vs high fidelity prototypes

UX thought leader and speaker Stephen Anderson weighs in on whether you should focus on wireframes or push forward with high fidelity, interactive prototypes early on. I like his use of internalising over skipping:

I think there’s a difference between skipping a phase versus internalizing a phase. As young students, we go through a very formal writing process in order to learn the skills needed to be a good writer; I doubt very seriously that any of us go through that same, explicit process as mature writers. We’ve internalized those things we were taught.

At Q42 and on the Handcraft team we frequently do sketches and then immediately move on  to interactive prototypes. Not because we want to skip wireframes, but because that part of the process is kind of redundant. It doesn’t add anything of value when you can just get on with the things you really want to communicate to your client, namely the refined details of the interactivity you’re mocking up.

Stephen comments on communication as an important stage in the process, too:

Asking someone to comment just on the interaction or just on the structure–independent of the other pieces — is a bit like asking someone to judge a chocolate chip cookie based on only a handful of ingredients. “Here, these are the wet ingredients (eggs, sugars, vanilla)–what do you think of this cookie?” How can we possibly expect to get good feedback on such an incomplete experience?

Fully interactive prototypes allow the client or stakeholder to comment on the actual experience rather than a picture of it. That way you get a constructive discussion going early on about the final product instead of wandering around in idea land for too long. Getting to this stage as fast as possible means you can spend more time testing with real people, which is another point Stephen makes:

I’d argue for an integrated, holistic approach to UX that serves up as complete an experience as possible, as early on in the process as possible. I’m talking days, maybe even hours in some cases. This is not so we can be done more quickly, but so that we can use this new found time to iterate more frequently with actual users, leading to better, more user focused experiences.

We talked about this in our presentation at UX Brighton last summer: focus on the details rather than skipping over them just because you want to be done sooner.

Stephen’s a great thinker and writer and it’s awesome to see a gradual move towards this kind of thinking in the design industry overall. Read all of Stephen’s thoughts on the subject at The Pastry Box Project: Wednesdasy, 4 April. Here’s hoping he works this angle into a future talk!

How the new Chrome Web Store increased signups to Handcraft by 1000%

Last week’s release of a renewed Chrome Web Store by Google increased signups to Handcraft by 1000%. What happened?

A list of apps in the Chrome Web Store

Continue reading →

An open letter to Stripe

Update: Stripe responded below, and if you want Stripe in Europe you can leave your name and country here

Dear people at Stripe,

Stripe sounds lovely and I wanted to add a voice from Europe calling for you guys to hurry up and get over here. The payment processing industry is probably a mess in the US, but I can almost guarantee you it’s even more of a mess over here if you’re not in the UK. Sounds like a great business opportunity, right?

In getting ours set up we went through a 3-month long nightmare/adventure and finally settled on Ogone+Spreedly. I’m sure you know of both. Spreedly is like Stripe in its elegance and simplicity, but it’s not full-stack, which means we’re required to suffer through the terrible UX and customer support of Ogone. Seriously, if there’s a company I could say I actually hate, it might be Ogone.

I wrote some blog posts about our experiences that I’d like to share with you in an attempt to hopefully convince you to expedite your trip across the Atlantic:

Please come to Europe as soon as possible. We’re over here waiting to give you our 2.9% + 30c.

Yours faithfully,

People in Europe who want to make money off their web-based software

Continue reading →

“A designer who does not write markup and css is not designing for the web, but drawing pictures.”

Andy Rutledge wrote a blog post saying that web design is product design:

Web design is product design. Drawing a picture of the product is not designing the product. Web design is experience design. Drawing a picture of on-screen content or mechanism behaviors is not designing the experience. The functioning html/css (and sometimes JavaScript) is the design.

The key quote here is “the functioning code is the design”. All too often people view “design” as just describing something visual. But the design of a building isn’t the picture of the building, it’s the blueprint. The design of an iMac consists of more than just an illustration of the iMac, it involves all the specifications and internals. That’s design. To wall in design within the visual is to misunderstand all the skills designers must have to do their jobs well.

In the case of web design, as Andy says, the code is the design. The beautiful thing about that is that you can work on just the design, writing HTML and CSS, and suddenly you have the end result. You don’t need to go into, say, mass manufacturing. You just publish your code (and maybe clean it up a bit). This is why we made Handcraft.

Don’t stop calling yourself a UX designer – it’s working!

It seems like there’s a neverending debate over whether people should be allowed to call themselves “user experience designer”. On one side of the fence you’ve got people assigning themselves the title because they feel that it represents best what they do, or have done for years. On the other there’s a crowd calling the former group names because they don’t feel they “deserve” to call themselves something they appear not to be.

But wait just a second. Has no one noticed what this argument is really about? About what the consequences are of everyone left and right wanting to call themselves a user experience designer?

That’s right. It’s becoming cool. Continue reading →

Adobe doesn’t get it

Adobe’s new Muse is a product aimed at helping print designers design websites without coding.

There are two things wrong here. The first is the idea that print designers should be designing websites. The second is that you can design a website without coding.

This is a troubling development from a company that is trusted by so many, and, in certain ways, is an industry thought leader when it comes to providing designers with tools that help them do their jobs. This is Adobe signaling they believe in tools that abstract away craftsmanship and instead rely on outdated paradigms, returning to the heyday of WYSIWYG IDEs that lull you into a state of thinking anyone can put together a successful website.

But it’s not true. Yes, print designers can learn to design websites. And print designers can be really fantastic designers. Print designers can also learn to write HTML, and do it well. Muse, however, implies neither of those things are necessary. No, it says, you just keep doing what you’re doing and this magical piece of software will handle the rest.

In the video on the Muse website, one of Muse’s product designers says ‘In five or ten years, I don’t think very many people will be coding to design websites.’ (via Elliot Jay Stocks)

How wrong you can be – it’s far more likely the opposite will happen.

More on the difference between wireframing and prototyping

Last year we wrote about how wireframing and prototyping aren’t the same thing. A few weeks ago, I gave a talk at UX Brighton about the difference as well. We decided it basically comes down to this: wireframing is about communicating structure early on, prototyping is about the user experience. Continue reading →

UX Bootcamp: Prototyping in Code

User experience designer Leisa Reichelt recently tweeted her discomfort with prototyping tools:

Increasingly frustrated by prototyping tools. May have to do HTML5/CSS3 self imposed boot camp after all.
Leisa Reichelt

Leisa’s not alone in wishing she could write better HTML & CSS so she could just do prototyping in HTML: designers who code is a growing trend that more and more UX professionals are becoming familiar with.

But learning how to code remains something you need to invest quite a bit of time into. Perhaps that’s what’s been stopping Leisa and others from becoming expert HTML prototypers.

Thankfully Leisa is also pro-active: she’s taken it upon herself to organise a UX Bootcamp program. The first session, Prototyping in Code, is intended for designers who want to pick up the basics of HTML and CSS for prototyping purposes and will be taught by Alex Morris, Anna Debenham and Peter Gasston.

It’s in London from July 22nd to the 23rd and is preceded by an introductory day for designers who’ve never written a line of HTML in their life called Code Fitness. Tickets for the 22nd & 23rd are £299 (excluding a fee) and £149 for the 21st. Sign up here.

Knowing how to code helps you write better prototypes

UIE’s Jared Spool posted a follow-up to his “Why the Valley wants designers who can code” post, which we wrote about last week. His new article, which he says will be the last from him on the topic for a while, covers 3 reasons why designers should learn how to code. His second focuses on prototyping:

Knowing how to code helps you produce better prototypes. The best way to communicate a design idea to your teammates and clients is through an interactive prototype. Producing your own quick prototypes brings your ideas to life sooner, releasing that inner brilliance you’re carrying around and helping everyone see what your designs are really about.

The implication here is that interactive prototypes should be written in code. So by Jared’s definition, an interactive prototype can’t be, for example, an Axure prototype, or a Keynote wireframe with click zones. It has to be code.

We agree. You should handcraft prototypes in HTML. You’ll learn more about the medium you’re designing for, be able to anticipate constraints and possibilities more ably, and become a better designer overall.

See all three reasons why learning to code makes you a better designer over at UIE.

Great prototyping advice: Fail early, fail fast, fail often

Wanna Create A Great Product? Fail Early, Fail Fast, Fail Often is a great article today in Fast Co. Design magazine about the need for prototyping, how not enough people do it, and an overview of various approaches you might consider. For high-fidelity prototypes, Jeremy Jackson has the following advice:

High-fidelity prototypes can take a variety of forms: They can be coded as working HTML, CSS, and Javascript interfaces, or they can manifest themselves as non-interactive motion studies. Choose the technique that best tells your solution’s story and allows to you test any weaknesses in the system.

And there’s a great anecdote here, too:

Thumbplay, a “cloud”-based streaming music service, partnered with Method to design their next-generation app for Web-enabled televisions. Method’s designers and technologists worked together closely to create a fully animated, true-to-life prototype that allowed user testing of key service features and history states. The prototype was easily shared and demonstrated through a Web browser and, ultimately, proved instrumental in validating a number of visual and user-experience design decisions and creating a successful service.

This just goes to show how high-fidelity prototypes really allow you to get as close to the real experience of the final product as quickly as possible.

Read the full article for Jeremy’s tips on how to integrate prototyping into your development process and some awesome quotes by James Dyson and Thomas Edison.