Ooh! New (old) bike… erm…

I got a knackered old Pulse Adrenaline 125 from Big_D, at virtual no cost 😉

Why rebuild a Chinese 125 which probably won’t be worth more than about £500 when finished? Why not? I’ve not ridden a 125 road bike for about 20 years, and I’ve never ridden anything Chinese, so it seemed like a reasonable thing to do in preparation for the rebuild of my RD350LC, planned for summer.

Also, the parts for Chinese bikes are dirt cheap, and there’s an opportunity to put some of the frankly naff original items, and also to reverse years of teenage abuse.

Here are the pics as it was picked up on Friday… brace yourselves!3938ZAn - Imgur 12281954_10154447268893776_568905648_o 12510108_10154447269063776_443603403_o 12528666_10154447269008776_1758599867_o 12544044_10154447268968776_1333054458_o 12544779_10154447268908776_1415340346_o 12546241_10154447268863776_2070819996_o 12546314_10154447268998776_1332629347_o 12557169_10154447268983776_736082611_o 12557191_10154447269053776_456063337_o 12562458_10154447268813776_251723920_o 12562732_10154447268943776_2059067911_o

Are IBM doing it right?

Our knowledge of IBM on the Boots project tells us they have a largely inflexible webshop platform (Aurora) with no API capability.
Given that OOTB product front ends tend not to be appropriate for any of their customers, and always need heavy customisation. The level of customisation depends on the budget, and is invariably not met by the systems vendors working in agile methodology.
So everyone’s a loser. Apart from the systems integrator, who are quids in.
This might spell the end of inflexible boxed systems and pave the way for bespoke experiences built on common technology… but I guess leaves an open question as to the role of agencies in IBM’s (and potentially their customer’s) plans.

One step closer to sign off…

As another project draws closer to completion, I contemplate exactly how we brief staff to deliver modular projects. It’s an increasing requirement, especially in a responsive project, but one which is easily lost amid a flurry of client feedback.

In order to address this, we at Splendid are trialling an approach to re-implement responsive even where it’s not being followed by development teams… Watch this space…


Car infotainment: It’s not all good (shocker)

Autoblog recently published a report about car infotainment systems generally beginning to fail after a year.

The issue is that most of these systems are bespoke, with bespoke connection to common handsets or data services. As those services change, the systems are generally difficult to update and often need to be taken back to the dealer to fix. All of which is costly, time consuming, and frustrating. The exact sentiments a good in-car system should avoid.

I’m increasingly thinking the right way to go is the phone software route. Maps, calls, music, video, etc can all be run from a modern smartphone. Separate that from the system stuff, and all you’re asking of the system is an AV connection, in effect.

You then save on having to create an OS (which we did with AM), the overhead of customers learning that, and all the massive integration issues that presents. Those issues are then exacerbated by the secondary kit’s own upgrade paths, extensions, etc…
It’s a big ball ache. Better to keep it simple, and use what the customer already has. Of the obvious manufacturers, BMW are currently leading the way in this, from what I can see, but are still hamstrung by their dreadful iDrive system operating the front end. If they ditched that, they’d be about there, as their back end integration to the OS is as described above.
But the front end of iDrive running this means that the presentation layer has to be reinterpreted. Which is madness.
We should do another one…


Replacing hotel door messages

While at the Amalia Hotel in Athens, Greece, I spotted this simple method of telling the staff you want your room cleaning. Now many hotels are employing smart digital technology to allow communication, but something about the simplicity of the controls struck me here. I can imagine my mum using this…



8-legged usability clanger

The Spyder uses on screen notifications... poorly.
The Spyder uses on screen notifications… poorly.

Our IT department uses Spyder calibration devices to ensure all of our screens are nice and accurate. The other day, while watching the process, I realised the software which comes with the device uses a visible template of where to put the device. This template is shown along with the first prompt to ‘Place your Spyder here’. Great, really simple, easy to follow.

However, once the automated colour balance process is completed, the device uses the same space to tell you that the process is over and you should remove the Spyder. However, the Spyder is directly blocking the user’s view of the notification. Oops.

Patterns 0 – Usability 1.

Designing for banking mobility

Banks aren’t thought of as ‘helpful guardians of financial wellbeing’, but as unflinching holders of ‘our’ money. Existing mobile banking experiences do little to counteract this, and don’t take into account the users needs and context. User’s we’ve interviewed want help managing their finances. This doesn’t mean an interview with a bank manager, but nudges when they are spending a bit too much, or a pat on the back when they’re saving.

With increased competition, ever-stricter regulation and government switching legislation, loyalty to banks is at a low point. To turn that around, we need to respond to customer needs and take a look at how they actually want to manage their finances.

Branch-centric banking customers are generally more accepting of wait times, and more accustomed to visiting the branch to perform banking tasks. When necessary, they will call or use an ATM, and rarely will they log onto their account online. But this behaviour is changing.

Customers are increasingly embracing mobile technology, and the expectation is now that their banking relationship can be handled through their mobile device. For many, it’s the primary device, it’s with them all day long, and many other customer experiences are served through it. Leveraging that behaviour is key to generating reliance and loyalty.

So we need to be on their mobile devices, providing the services they need. Balance and activity, Forecasting, Mobile payments and transfers, Savings and debt reduction, and Education and support are all identified as critical by users.


5 top tips for banking mobility

1) App or responsive website?

To begin the digital relationship, the website is often the first port of call. However, once behavior becomes more frequent, users tend to download an app. For an account servicing banking experience, an app provides enormous power. The ability to work offline for certain tasks (balance caching), and to maintain a logged in state behind a simple passcode, apps provide a far faster, more mobile-appropriate experience. Ideally, you’ll provide both.

2) Offer the appropriate features

It’s tempting to provide a fully featured experience, in which a user can perform any task they want to. But is that absolutely necessary? 80% of the time, a user wants one of very few tasks: Balance, Alerts, Payments and transfers. So focus on doing those brilliantly. This can inform build priority, and ultimately allow you to get to market faster.

3) Design for interruption

It’s tempting to assume users always finish the task they start. The reality is, when they are on their mobile device, they’ll get interrupted. Bus stops, network interruptions, bumping into a friend or just watching TV. Tasks get interrupted frequently. Ensuring that the user is secure and logging them out is good, but ultimately often means they’ll have to start again, resulting in frustration. Providing fast, pre-authenticated log in methods and caching or saving progress will go a long way to ensuring the user does complete their task.

4) Consider the platform

Most banks have strong brands, designed to differentiate them from their competition on the high street. All offline literature is heavily branded, and adverts immediately identifiable. However when the user is on their device, over-branding the interface can create a negative experience as a whole. The user will be used to their device, the way it works and the way Ui controls like drop menus work. Coding appropriately you’ll leverage the learned behaviours of the users device, and more carefully consider the usage of branding. Platform-agnostic information architecture design means we can design a single set of features and services, which can then be quickly appropriated to various platforms and OS’s. Android (and now iOS) devices have NFC. They also have different links to the OS controls, different user interfaces, and different task focuses. Respect the user’s digital environment and you’ll make them more comfortable using your products.

5) Deliver task-focused experiences

When you’re paying for lunch and need to know your balance, you don’t want a welcome screen and sales messages getting in the way. Focus on the users tasks, and leave the rest behind. Speed and simplicity provide the key to making your product usable.

Allow the customer to quickly get to the functions they need, when they need them. This will mean focusing the experience on the core functions, and leaving less important functionality a click away in the UI. Context is another important factor, allowing us to further tailor the experience. If we know the user has just gone overdrawn, we can tell them. We can even provide them the next action: ‘Transfer money from your savings account, madam? Certainly.” Focusing on the task at hand usually means providing clear, linear journeys, with the shortest number of steps possible. Removing the requirements to gather additional information in a sign up or registration journey is far more likely to result in the user completing that task, and using your product more and more frequently. Making their banking easier.

Designing for content and data

Ultimately, everything we design is there to consume content. Whether that’s images, text, video, or whatever, they are (almost) all containers. When designing for responsive sites, this is even more true. The modules/components will scale and in many cases the content within them will too. A lot of the work we are doing at Splendid these days is responsive, and it’s surprising how many designers don’t really understand the importance of the pattern in this type of project.

My first exposure to patterns was back in 2003, when the company I was working for were working on design patterns for Visa. The discipline was considered relatively new at the time, at least from a digital context. Obviously lately there’s been a resurgence, as designers begin to understand how to use patterns, and more importantly how to make them scalable.

An article popped up on my Twitter feed the other day, which is actually a pretty decent set of considerations. I shared it round the office, and will hopefully get roux to seeing if anyone actually read it! Here’s the link:

Hot Data and Content Design Patterns for Mobile

Personally, I think more needs to be done to explain HOW to use patterns, on top of articles such as this which explain the patterns themselves. I’ve (recently) seen designers come up with some interesting design patterns for individual screens or components, but they have absolutely no consistency to the overall experience. I’m hoping we’ll get round to a decent formal of how to explain (and solve) this issue, but until then… send me your thoughts!