I guess people’s (in) ability to say “sorry” is not unique to the digital landscape. However, you do not have to be a rocket scientist to see that the web and social media have made mistakes and public relations disasters a lot more public and transparent. I am always particularly interested in one’s ability to hold his hands up and say “sorry”.
A few weeks ago I came across a great example of saying “sorry” when I read this blog post by Giacomo ‘Peldi’ Guilizzoni. Peldi is the founder of Balsamiq, a 4-year old company that created Mockups, a wireframing tool that helps programmers and user experience (‘UX’) staff design software by letting them sketch ideas and then collaborate over them. In his blog post, Peldi apologises for the 3 hours of downtime in which myBalsamiq users were unable to use their online UX project tool and explained exactly what had happened and where Balsamiq went wrong in what should have been a short, routine database update.
I do not think that Peldi wrote this blog post just because he was happy to hold his hands up, be transparent and to reimburse his customers. He must have realised that for a product that aims to “want to compete on reliability”, a significant breakdown of the application is not a great look. He therefore must have felt compelled to make a clear statement.
As it happens, Peldi and Balsamiq have positioned themselves as big advocates of “radical transparency”, a new management approach that is slowly starting to influence digital businesses. In essence, radical transparency strongly promotes public decision making. This for example means that companies involve their customers directly in making product decisions or empowering customers to make well-informed buying decisions. Let me look into this a bit more:
Total transparency – Other than personal user data, not much else is out of bounds under the “radical transparency” banner. This can vary from businesses publicly sharing arguments for and against a proposal to the guys at Balsamiq being completely open about cocking up.
Open engagement (1) – Increasingly, companies have started using tools like Lithium and Get Satisfaction to directly engage with their customers. Businesses like 7digital (where I work), Spotify and TomTom are using designated platforms to engage with their customers and to address any queries users might have.
Open engagement (2) – You could argue that some of the conversations on such customer platforms don’t go far enough if you were to fully adhere to the “radical transparency” mantra. Rather than replying to such a customer query by saying: “Unfortunately, we don’t support our software on such and such device device”, a business could go a few steps further by explaining that “We looked into supporting our software on this device but it proved too expensive to implement and we feared that it would give our customers a really bad user experience. Here are some of the draft wireframes that we used at the time to sketch and highlight some key development and user issues. Please tell us what you think and whether these issues would matter to you?” A business could then open up this discussion by for instance blogging about it and throwing it out to the developer community for input and suggestions.
Empowering customers – Involving customers in a public decision making process is a critical aspect of public transparency, as I outlined above. Sites like GoodGuide, Sourcemap and SkinDeep aim to provide consumers with product and company data to help in making those decisions. For example, it sayson GoodGuide that fashion brand Ralph Lauren “does not make a meaningful commitment to using environmentally preferred fibers.” The financial sector is in my opinion an industry that could benefit from radical transparency, standardising financial information and being more open with its customers.
Customer data vs customer input – It is interesting to see that whilst a data-driven focus seems to be getting a strong hold on software development (think Eric Ries and “lean startup”), there is also a growing focus on qualitative customer input through the “radical transparency” movement going on at the same time. Businesses like Balsamiq strongly believe in concentrating on what the customer wants and not just improving through continuous testing and measuring performance.
Main learning point: I tend to have a great respect for people who can just hold their hands up and say “sorry”. Especially when that apology comes with an honest explanation of what happened and how you are looking to make up for it. The “radical transparency” movement urges businesses to be much more transparent and to actively involve customers in their decision making processes. Balsamiq seems like a great example in this respect, I like how they consistently try to be transparent and involve their customers.
I have been interested in Smart TV for a while now and I think it is an interesting area to look into. First of all, because it is TV and, despite what some people might think, TV still drives an enormous part of how we consume content. Secondly, the integration between telly and the Internet is likely to be a significant growth area for both consumer electronics firms and digital content providers.
This integration between TV and online is the main reason why Smart TV is often also referred to as “Connected TV”. I think it is fair to say that the days of television as a stand-alone medium are limited at best. No longer is it enough for people to just sit in front of the telly and consume its content; viewers want to interact with the content, share it with others and access it online too.
I have just picked some examples to better illustrate the functionality which Smart TV has to offer:
Interaction – Smart TV is all about about enabling users to interact with their TVs. A good example is the gesture control functionality of Samsung’s latest line of Smart TV’s. In theory, users won’t need a remote control anymore to switch channels. It was interesting to read a review of this functionality by CNET which found that “the Smart TV voice and gesture control features routinely mis-heard commands, and the gesture commands were laggy, when they were properly received at all.”
Acting as a content hub (1) – Smart TV systems like Panasonic’s VIERA TV enable users to link up their TV with content stored on other devices. Things like built-in Wi-Fi enable the VIERA TV to ‘communicate’ with compatible devices, which means that you can for example stream music or pictures stored on your smartphone to your TV.
Acting as a content hub (2) – The integration of the Internet into TV sets is – alongside interaction – a key feature of Smart TV. Similar to the way in which online content and apps are integrated in smartphones, Smart TV users can access online content through their TV sets. A good, recent example is the tie-up between LG and Perform whereby LG’s Smart TV users will have access to Perform’s digital sports content. Google TV is another good example, with users being able to control their TV using their Android phones.
The other day I was talking about Test Driven Development (‘TDD’) like one talks about a favourite football team or a popular artist. However, It was only halfway through the conversation that I realised that I would struggle to explain TDD to non-techie people and that it would be good to delve a bit deeper into the underlying principles of TDD:
Write tests first –In more traditional software development methodology, the focus is on writing code first and then test it afterwards. Test Driven Development intends to throw that order out of the window; developers are expected to write a test first, run the test and then write more code.
Write enough code to fail the (first) test – As outlined in below diagram (Fig. 1), the idea is that when testing a ‘first development’ you write a quick first test and make it pass with the simplest change to the production code as possible (this is often referred to ‘test first development’ or ‘TFD’).
Subsequent code updates and testing(1) – The outcome of a test is either ‘red’ or ‘green’. Depending on the result of the test, you then make a little change in the code (refactoring) and run the test again. If a test has passed (i.e. shows as ‘green’) you can refactor from a green test to another green test. Following a refactor, if all tests are green, you then right your next failing test. A commonly used formula to represent this approach is: TDD = refactoring + TFD.
Subsequent code updates and testing(2) – What it effectively comes down to is a continuous cycle of writing a failing test (‘red’), making it pass (‘green’), move to the next failing test and then change the code of this test (refactor) to make it pass (see Fig. 2 below).
It’s about testing, not about writing specs! – I guess the main thing to stress is that TDD is NOT about writing detailed specifications. However, I spend quite a bit of time working with business stakeholders to specify scenarios on how a system is expected to work. This helps in creating a shared understanding of how functionality is (or isn’t) going to work, but – again – is not about capturing the scope of the functionality in painstaking detail, it is much more about driving the architecture of the code.
Acceptance testing to prevent new software bugs – If you are a developer, the main aim is to write and run continuous tests to uncover any new – functional and non-functional – bugs and see if any changes or enhancements made resulted in faults or bugs.
It’s a collaborative process – TDD specialist Gojko Adzic stresses the collaborative nature of TDD. The number of people that actually need to be involved depends very much on the nature of the product. For instance, if you are working on a new product or feature then it would be a good idea to have regular small workshops with the “Three Amigos”; a developer, a tester and a business analyst. In contrast, when the product is more mature it might just be a case of pairing two developers to work on it.
Main learning point: one of the key things to remember about test driven development is its radical departure from traditional software development. Rather than writing all the code first and then doing tests at the end, the main goal of TDD is to let the tests do the work for you, to drive the structure of the code. What I like most about TDD is its iterative nature, following the continuous ‘red-green-refactor’ loop, which enables developers (and the business) to discover any issues or bugs early on in the process.