Yesterday I went to a User Experience Sketching session hosted by Devin Hunt from Lyst. I had no idea what UX Sketching was about, but it sounded interesting and some people I follow on Lanyrd were going, so what the heck.
If you haven’t heard of UX Sketching either, it turns out to be a way to see inside the minds of your users and experience your site/product through their eyes. Even better, it’s really simple:
- Find a user
- Ask them to quickly sketch the page/feature/item of interest
- Look at what they draw – and what they don’t draw
- Repeat until you’ve got a bunch of data points
By getting the user to draw from memory, you find out what’s most important/salient to them. One example from Devin – on Lyst they had a “Love” feature. Click metrics said people were clicking on it – but it never showed up in sketches. Turns out when they dropped the feature, no-one noticed – it was only being clicked because it was there, not because it was useful.
So when is this tool useful? Obviously, you have to have some users who have some familiarity with the site/feature. It’s no use if they haven’t seen it – so it can’t start a design process for a new feature.
What it can do is tell you where your design is working, or where it’s not. Perhaps you want reviews to be central to a buying page, but users aren’t sketching them. That could trigger a round of design work, mockups, A/B testing etc to see what raises the awareness. Maybe you’re trying to figure out where on a page things should go – looking at where users sketch them will tell you where they intuitively think they should go.
I think seeing through others eyes is one of the hardest things to do in design, so this seems like a great quick, easy way to do it.
Now off to get some users sketching…
I spoke at the London Big Data meetup a couple of weeks ago about counting, and how difficult it is if you want to count things very very fast. My slides from this are now up here and on Slideshare.
More on the joy of counting soon, including why Memcached can’t count.
Some thoughts from the AWS summit today in London. The keynote presentation was by Werner Vogels (CTO Amazon), followed by a bunch of customer stories & then workshops.
Some thoughts and impressions
- It’s surprisingly big. For a vendor conference, this is pretty busy. I heard 1400 people were registered and the keynote was busy. Suits seem outnumbered by geeks.
- A super customer-friendly strategy outlined. Firstly to be a cost leader – “if we make savings, we’ll turn round and lower our prices to our customers”. Secondly, “there will be no lock-in. You can use any bits you want, from any language”. Refreshing change from previous large technology platforms.
- The sheer scale of AWS is mind-boggling. Each day, they add as much server capacity as the whole of Amazon used in 2000. There are 339 Billion objects in S3.
Some roadmap priorities were called out, but what was notable was the repeated request for customer feedback to drive roadmaps, and the separation of AWS into individual services that can innovate and launch at their own pace.
Here’s what appeared on the roadmap:
- More geographies
- Make it easier to build and manage applications
- New database offerings
- More support, billing and user management options
In conversations, the lack of a clearer roadmap was a repeated gripe. For example, one company had just built and launched their email service two days before Amazon announced their Simple Email System. The lack of roadmap doesn’t appear to be a secrecy thing, but simply reflects the customer-driven and independent team development.
This is a fundamental limitation of agile development practises when building platforms. As soon as customers are making substantial technology bets on stuff you deliver, you can bet they’re going to start asking for clarity on where you’re going, so they can aim to meet you there.
I don’t think there’s a good answer to this. At Symbian we had roadmaps galore, and plans out 2-3 years which always ended up being not what the customer wanted by the time they started thinking about their products. Amazon is at the other end of the spectrum, yet it causes a different set of problems.
Interesting perspective from Mark Baker at Canonical on how the audience stuff we do for BGT might have lessons for the UK government.
Slides from my talk at the first Big Data London Meetup are here: http://www.slideshare.net/malcolmbox/scaling-the-britains-got-talent-buzzer
They were written for speaking to rather than reading, so apologies if they don’t make sense in isolation. I don’t think there’s any video of the event available online.
We pushed Tellybug into the app store last week, and over the weekend it went live. Today the Guardian covered the app, and we started to pick up users. Great! Isn’t this the dream of every startup, the goal of every engineer: product shipped?
Of course it is. But still, shipping sucks.
Here’s just some of the ways shipping sucks:
- It’s just not ready! Whenever you ship, you know all the ways things could be improved, all the rough edges, all the places where it doesn’t live up to your original vision.
- Users! Now you have users, each with their own views on your masterpiece. And since this is v1, most of them won’t be complimentary.
- No users! Even worse than users is having no-one admiring your new baby. Why aren’t people flocking to use this revolutionary new product?
- Taxes! If you’ve been avoiding paying your programming taxes, this is where it all comes back to bite you. No monitoring? No crash logging/reporting? Oh dear.
- Marketing! No longer enough to sweat over code, now you need to promote your new product left right and centre. And sweat over the code.
See? Shipping sucks. But there’s something that sucks worse. Not shipping.
So I’m glad we shipped Tellybug, even though now there’s a million things to do to keep it running and fix all the things that we didn’t get done for v1.
This week we shipped Tellybug. This isn’t the first product I’ve shipped, but somehow this one feels different.
Before this, I’ve shipped software that’s used in hundreds of millions of phones, shipped complete phone projects, shipped marketing programs and shipped iPhone apps and web sites. None of these have felt like shipping Tellybug, our new social TV app.
So what makes shipping Tellybug feel so different?
There’s plenty of candidates: shorter delays between finishing the code and having it in user’s hands; being part of a much smaller team; the joy of seeing something new come to life.
But I think the real reason is that Tellybug is social, and that means I can see what our users are doing, and even their faces, in the app itself.
So each time I load up Tellybug now, I get a “oh wow” moment as I virtually meet all these lovely users. I’ve never had that in a previous product, and it feels different.