Category → The Status Quo
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!
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:
People in Europe who want to make money off their web-based software
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’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.
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.
In 5 Lessons from Beyond the Polar Bear, BBC information architect Mike Atherton lays out how domain-driven design has changed his and the BBC’s perspective on designing the user experience. Many of his points represent the shift towards designing the holistic experience that web designers are going through at the moment, and late in the article he even goes so far as referring to them as “information experience design architects”. Continue reading →
Jared Spool over at UIE just published an article about “why the Valley wants designers who can code“. In it, he asserts that startups in Silicon Valley want to keep teams small and therefore look to combine critical roles within a single person, while established players in the industry can afford to spread those roles out over more people.
Balsamiq Mockups’ new manifesto includes a chapter about prototyping. Here’s an excerpt:
Wireframing + real running code is way better than prototyping
We consciously decided not to let our users specify interactivity other than the ability to link wireframes together into a storyboard.
- We’re not huge fans of building large prototypes.
- Letting you specify behaviours and click-actions would inevitably turn Mockups into a much more complex tool
Geez, Peldi! We’re hurt!
Less CSS really does what its title claims. It’s an elegant approach that adds all the syntactic sugar you ever wanted to vanilla CSS, such as variables, nested rules and declaration templates. And it starts out by being 100% compatible with your original CSS files. So what are you waiting for? The only way is up.
Firebug offers a great way of doing on-the-fly CSS modifications right there where it matters: in the browser. It allows you to actually “design in the browser” which is part of the Quplo philosophy. The only problem is that CSS changes done in Firebug aren’t persistent, so you have to redo them in your editing environment in order to save your work.
Well, not anymore. Here’s Backfire: the save button for Firebug.