Priya Prakash explains about Design Principles at Mobile Academy

As part of the Mobile Academy curriculum, I recently attended a class by Priya Prakash on “design principles”. Priya is a very experienced designer and has founded Design for Change, a London-based urban experience design studio.

Priya started off the session by explaining that design principles describe the experience of core values of a product or a service. Design principles help in making decisions on your product. She referred to a great definition of design principles by Luke Wroblewski (see Fig. 1 below). The important part of Luke’s definition is that all decisions can be measured against design principles.

“Design is what you decide not to do” was one of the key points that Priya raised in this class. It’s all about doing less and simplifying things.  She talked about Spotify and Google Glass as good examples in this respect:

  1. Content first – Focus on the content, and remove any unnecessary user interface elements.
  2. Get familiar – Even though there is a clear distinction between a “lean forward” mode (Spotify desktop app) and “lean back” mode (Spotify mobile app), there’s a unified design language which has been executed consistently, irrespective of the device that you access Spotify from.
  3. Don’t get in the way – Google Glass is designed to be there when you need it and to be out of the way when you don’t. The goal is to offer engaging functionality that supplements the user’s life without taking away from it.
  4. Keep it relevant – Deliver information at the right place and time for each Google Glass user.

Priya then talked about motion user interface design principles:

  1. Personality – For example, the Pitchfork app has a magazine like feel. It’s about understanding what the content is and translating this into appropriate behaviours.
  2. Responsive – Priya talked about the Clear app as being very responsive, explaining how this app gracefully expands or contracts.
  3. Context – Motion should give context to the content on screen by detailing the physical state of those assets and the environment they reside in.
  4. Emotive – This principle is all about evoking a positive emotional response. This kind of response can be triggered by wide range of user interface elements, for example  smooth transition or a nice animation. Yelp‘s app is a good example in this regard.
  5. Orientation – Motion should help ease the user through the experience.  The “orientation” principle means that motion should establish the “physical space” of the app by the way objects come on and off the screen or into focus. The key is to get the flow of actions right, guiding the user on her journey and make sure she doesn’t feel lost or confused. Mobile apps like Yelp and Evernote do this pretty well in my opinion.
  6. Restraint – Keep it simple! Similar to the abovementioned “orientation” principle, it’s important not to bombard the user wity too much animation or confuse them with too many interactions to choose from. This is one of the reasons why I’m so a big fan of single purpose apps; I like the simplicity that they offer and the level of design restraint that they tend to apply.

Main learning point: I learned a lot from Priya Prakash’s class on design principles, particularly with respect to motion user interface design principles. Design principles can provide valuable guidance for the design of any software product or service and should therefore not be taken lightly. Thanks to Priya for a great class!

Fig. 1 – Definition of design principles by Luke Wroblewski – Taken from:

“Design principles are the guiding light for any software application. They define and communicate the key characteristics of the product to a wide variety of stakeholders including clients, colleagues, and team members.”

“Design principles articulate the fundamental goals that all decisions can be measured against and thereby keep the the pieces of a project moving toward an integrated whole.”

Fig. 2 – What makes a good design principle? – Taken from Priya’s lecture at the Mobile Academy on 14 October ’14:

  • Specific enough to help make a choice
  • Focuses the team – avoid being broad
  • Measurable against user need or product/business goal

Related links for further learning: 


Tags: , , , , ,

Learning more about constructing business cases at Mobile Academy

I’ve just started attending classes by the Mobile Academy, a great joint initiative by Uni­ver­sity College London (UCL) and Mobile Monday London. The first class that I attended was run by Ian Merricks, a seasoned investor and Managing Partner at White Horse Capital.

It was interesting to hear Ian’s thoughts on the importance of proving an idea, explaining that – particularly in the UK – VC investors are not interested in just funding an idea; they want to see proof. He therefore spent a good amount of time talking about things to think through before you prepare your business case:

  • Vision – Your vision will differentiate you, it will set you apart from everybody else. Your business case will provide credibility, but the underlying vision needs to be clear and convincing (see Fig. 1 below).
  • Market – Here, Ian talked about being clear about the problems that you are looking to solve and being able to back up your market assumptions with numbers. Make sure you’re specific on your target numbers, the size of the market, route to market, best price point and being able to translate this into concrete numbers. Also, understand where the market is going and identify (potential) barriers to entry (for you and your competitors).
  • Research – Consider the following areas of research: (1) market (see the previous point) (2) commercial (talking to clients, being able to attest your assumptions based on actual user research and feedback) and (3) product (see Fig. 2 below). Ian stressed the importance of doing thorough research, explaining that the better you know your market and your customers, the higher the chance of success. He again brought it back to the numbers in a spreadsheet which you can then explain and provide sound underlying arguments for.
  • Validation – Demonstrate how you will be able to generate revenue. Ian talked about the importance of actual (third party) validation of revenue now and in the future (provide proof), the “how” and route to market as well as price competition. Are people already using your product? If so, how many and why? These are some of the questions that Ian raised in his class.
  • Cost base – Ian talked about the cost base to underpin the numbers in your business case (see Fig. 3 below). Ian seemed to be all about creating a ‘minimum commercially viable’ product and reflecting this commercial viability in your business case numbers.
  • Test case – Ian then did an exercise with one attendee, where he took a spreadsheet and started inputting some key assumptions and metrics. It was great to see a live example of someone being asked challenging questions around things such as user assumptions and go-to-market approach.

Main learning point: Even though I felt that I knew about most of the things that Ian talked about, purely having put together a few business cases in the past, it was still good to hear about the key things to focus on when creating a business on. It was particularly interesting to see a live ‘demonstration’ where Ian asked some of the questions which underpin a business case to an aspiring entrepreneur.

Fig. 1 – Key things to think about before putting numbers in the business case – Taken from: Ian Merrick’s talk about “Constructing your business case” at The Mobile Academy on 9 October 2014


  • What sets you apart
  • Could “anyone” do what you do?
  • What is your motivation?
  • How will you succeed?

Be clear

  • Simple clear message
  • USP / Differentiation
  • Management / Vision
  • Scalable

Fig. 2 – Research to do as part of constructing a business case – Taken from: Ian Merrick’s talk about “Constructing your business case” at The Mobile Academy on 9 October 2014

Market research:

Did you:

Develop a solution and then research the available (possible) market(s)


Research a market and identify a gap which you develop a solution for?

Commercial Research

  • Demand
  • Revenue
  • Market creation – Truly unique solutions can be a problem
  • Competitors
  • Price / demand curve
  • Target customer knowledge
  • Route to market

Product research:

  • Position
  • Fit for market
  • R&D
  • Features/benefits/needs
  • Supporting requirements (training, technical support)
  • Product roadmap
  • Minimum viable product -> Minimum Commercially Viable Product

Fig. 3 – Outlining the cost base of your product or service – Taken from: Ian Merrick’s talk about “Constructing your business case” at The Mobile Academy on 9 October 2014

Cost base:

  • Fixed / Variable costs
  • Testing assumptions
  • Dynamic forecasting -> the financial equivalent of “pivoting”: changing assumptions and direction
  • Sensitivity


Leave a comment

Posted by on October 15, 2014 in Digital Strategy, Startups


Tags: ,

User stories revisited, learning from Gojko Adzic

As Gojko Adzic is currently drafting his book titled Fifty Quick Ideas to Improve your User Stories, I picked up the following useful tips from his latest draft:

  1. Card-Conversation-Confirmation - The book assumes that readers are familiar with the concept of “Card-Conversation-Confirmation” (see Fig. 1 below) and the “INVEST” model (see Fig. 2 below). Both assumptions made me revisit the related concepts in more detail. I then also brushed up on ways to split user stories in such a way that they are ‘workable’ and as clear and as small as possible (see Fig. 3 below).
  2. Describe a behaviour change – Gojko makes the point that often it can be insufficient to just describe someone’s existing behaviour, and that it can be more beneficial to described a desired behaviour change instead. This trick is particularly useful with user stories that have an overly generic value statement, or where the value statement is missing. I created a simple example in Fig. 4 below. I guess the main thing here is to make sure that there’s a clear user outcome which can be tested. In my below example, the main acceptance criterion would be: “Can I see the top 5 reviews?”
  3. Describe the system change – In order to achieve the aforementioned behaviour change, the story should also be clear about the change the team needs in order to accommodate the desired change in user behaviour. What does the system need to do to enable the change in user behaviour? For instance, following my example in Fig. 4 below; if we want to enable users to filter products based on product scores, then we will need to create the necessary functionality in the system to enable this filtering behaviour (see Fig. 5 below).
  4. Watch out for generic roles – In his book, Gojko makes the point that it’s important to be as specific as possible when it comes to defining the “user” who is the ‘beneficiary’ of the story outcome. He argues that “without considering a
    particular user segment, it’s impossible to decide whether the proposed solution is the right one, or if it’s just unnecessary scope creep.”
  5. Put a ‘best before date’ on the story – When working in an iterative and flexible fashion, dealing with time-constrained changes can be a big challenge. I therefore like Gojko’s suggestion to put a date in specific stories that are subject to a deadline or which need to be completed before other stories can be started.
  6. Set deadlines for addressing major risks – We all know how tempting it can be to go for implementing the least complex user stories first and to hold off on delivering the more complex or riskier stories. However, I firmly believe it’s important to focus on the riskiest stories first, because – as Gojko points out – if you don’t address the risky stuff, at the some point the ceiling will come crashing down. He therefore suggests setting clear deadlines for dealing with specific, major risks.
  7. Group stories by impact – Gojko builds on his previous book about Impact Mapping by suggesting to incorporate user stories into the relevant parts of an impact map. An impact map is a visualisation (mind map) of how deliverable scope connects to business goals and the underlying assumptions on four levels. An Impact Map typically consists of these four levels: (1) business goal for a milestone of a project or a product delivery (2) user segments, stakeholders or actors who will be involved in achieving the goal (3) the impacts on users and stakeholders that can contribute to the business goal, or that could hinder achieving the objective and (4) the deliverables – user stories or even larger deliverables (such as epics) that can cause the impacts.

Main learning point: Even if you think that you know all there is to know about user stories, I still recommend you read “Fifty Quick Ideas to Improve your User Stories” by Gojko Adzic. Not only does the book provide a lot of helpful tips on how to create a user story but also offers valuable advice on how to fully incorporate user stories in planning processes. I found the book – based on its latest draft – to be a very valuable resource when it comes to learning how to create and apply user stories more effectively.

Fig. 1 – “Card, Conversation, Confirmation”, as defined by Ron Jeffries – Taken from:

“Card, Conversation, Confirmation”; this formula (from Ron Jeffries) captures the components of a User Story:

  • A “Card” (or often a Post-It note), a physical token giving tangible and durable form to what would otherwise only be an abstraction:
  • A “conversation” taking place at different time and places during a project between the various people concerned by a given feature of a software product: customers, users, developers, testers; this conversation is largely verbal but most often supplemented by documentation;
  • The “confirmation”, finally, the more formal the better, that the objectives the conversation revolved around have been reached.

Fig. 2 – INVEST as way to summarise characteristics of a good user story, as defined by Bill Wake – Taken from:

  • Independent – The user story should be self-contained, in a way that there is no inherent dependency on another user story.
  • Negotiable – User stories, up until they are part of an iteration, can always be changed and rewritten.
  • Valuable – A user story must deliver value to the end user.
  • Estimable – You must always be able to estimate the size of a user story.
  • Small – User stories should not be so big as to become impossible to plan/task/prioritise with a certain level of certainty.
  • Testable – The user story or its related description must provide the necessary information to make test development possible.

Fig. 3 – Patterns for splitting user stories by Richard Lawrence – Taken from:

  1. Workflow Steps – It can work well to build the simple end-to-end workflow first and then add the middle steps and special cases.
  2. Business Rule Variations – Allow for several different business rules, each of which can be a good story on its own.
  3. Major Effort – Split user stories by the amount of effort or complexity involved. For example, create an “epic” user stories, with ‘smaller’ but related user stories hanging off it.
  4. Simple / Complex – As soon as you feel that a user story is getting too big or too complex, come up with some initial acceptance criteria to start breaking down the big story into smaller stories, splitting off variations.
  5. Variations in Data – When you don’t know the data variations upfront, the best thing to start with the simplest version first. You can start with a ‘good enough’ version first an then add more stories just-in-time after building the simplest version. Naturally, this can be different when you know the data variations up-front.
  6. Data Entry Methods – Complexity sometimes is in the user interface rather than in the functionality itself. In that case, split the story to build it with the simplest possible UI and then build the more usable or fancier UI.
  7. Defer Performance – The focus of the initial product or feature might be to just make it work, and not worry to much about scaling or a fast performance. You can come up stories for these aspect at a later stage.
  8. Operations – Sometimes you end up with stories that incorporate multiple operations or interactions. For example, a story about user account management can include creating, edit and cancelling an account. It can be worthwhile splitting these different operations into separate stories.
  9. Break Out a Spike – A story may be large not because it’s necessarily complex, but because the implementation is poorly understood. In this case, no amount of talking about the business part of the story will allow you to break it up. Do a time-boxed spike first to resolve uncertainty around the implementation. If you’re not sure about how to implement a story, the related story can read something like “Investigate how to ___” and the related acceptance criteria can be the specific questions that you want answers on.

Fig. 4 – A simple example of a user story and acceptance criteria, outlining a desired behaviour change

Given that we have at least 5 reviews on a particular product.
As a signed in user who wants to be able to look at the top 5 reviews, something which is currently not possible.
When I filter the reviews based on product score.
Then I get to view a summary of the top 5 reviews on a single product and scores, displayed in a descending order from high to low.
And the summary of each review contains a rating, positive and negative comments.
Fig. 5 – A simple example of a user story outlining desired system change to enable a user behaviour change
In order to enable users to look at the top 5 reviews, the system will need to collected all product scores for each individual product and rank them from high to low.

Related links:


Tags: , , , ,

App review: Do

I guess we all know how frustrating it can be to have to sit in meetings that just feel like a waste of time or that could have been dealt with in 30 minutes (instead of 3 hours). I know that there are quite a few apps out there which help us to run more productive meetings, but I decided to focus on Do:

  1. How did this app come to my attention? - I got an alert from Product Hunt about Tools for Product Managers, promising me a list of “the tools the pros use”. Do was only ranked 10th on this list, but I guess it was this comment from one of the Product Hunt voters, that intrigued me the most: “I was a Yammer PM. is the meetings platform I wished I had.” Especially given that it came from a guy who used to be at Yammer – who are all about collaboration within the enterprise – this comment made me want to find out more about the product.
  2. My quick summary of the app (before using it) - Do helps you to have more productive meetings; I therefore expected a tool which helps its users to make their meetings as efficient as possible. The tool doesn’t yet seem to be available on iOS or Android, only on PC.
  3. Getting started, what’s the sign-up process like? - I have to sign up to use Do. At present, Do only seems to support Google users; all non Google users will be notified as soon as they will be able to sign up (see Fig. 1 below). Once I’ve selected my Google account, I get presented with a permissions screen (see Fig. 2 below). I click “Accept” and my personal dashboard appears. All fairly straightforward.
  4. How does the app explain itself in the first minute? - The default page of my dashboard shows a simple timeline with meetings on the relevant dates and times (see an example in Fig. 3 below). To be honest, I felt a bit underwhelmed at first , thinking “is this it!?”. However, the subsequent overlay which consisted of six ‘how to’ screens was quite useful, explaining in a simple but effective way how to best get started on Do (see Fig. 4 below).
  5. How easy to use was the app? - Using the tool felt very intuitive and easy. The layout of the dashboard is clear and easy to understand. Adding a new meeting to the dashboard felt no different to doing the same thing in Google or Outlook (see Fig. 5 below).
  6. How did I feel while exploring the app? - Like I mentioned above, exploring Do felt incredibly easy and intuitive. The signposting used in the tool is self-explanatory and the navigation options have been kept to a minimum. A quick click-through on an individual agenda item highlighted a key purpose of Do; the ability to create and share a meeting outline, making it easy to collaborate around meeting goals and agenda items (see Fig. 6 below).
  7. Did the app deliver on my expectations? – Yes, it did. I felt a bit underwhelmed at first, expecting Do to provide more, ‘less obvious’ features. However, whilst playing with the application, I discovered features like “Invite” and “Takeaways”, which I believe are missing from most standard diary / meeting applications.
  8. How long did I spend using the app? - A few days to start with, but I expect to be using it a lot more in the future!
  9. How does this app compare to similar apps? – I had a quick look at MeetingHero which serves a similar customer proposition to Do. At a first glance, MeetingHero seems a bit less advanced and intuitive in comparison to Do. MeetingHero is, however, available as an app on iOS which means that the app can be used on the go.

Main learning point: Do is a straightforward and easy to use meeting app. I like its interface and its key features; the app makes collaborating around meetings very easy. It will be interesting to see how Do will perform in already crowded marketplace, with apps and systems that enable similar things. I’m now curious to see what the mobile version of the application will look like!

Fig. 1 – Screenshot of Do’s sign-up screen

Do 1


Fig. 2 – Screenshot of Do’s permission screen


Screen Shot 2014-09-30 at 05.09.57

Fig. 3 – Screenshot of sample meeting in my meeting calendar in Do

Screen Shot 2014-10-05 at 08.41.29


 Fig. 4 – Screenshot of one of the introductory ‘How to’ screens on Do

Screen Shot 2014-09-30 at 05.22.54


Fig. 5 – Screenshot of functionality in Do to create a meeting 

Screen Shot 2014-09-30 at 05.36.59


Fig. 6 – The ability  to share a meeting goal and agenda items

Screen Shot 2014-10-04 at 13.23.52


Leave a comment

Posted by on October 5, 2014 in Google, Startups, User Experience


Tags: , , ,

Luke Jerram and Playable Cities

I really like the concept of a “Playable City”. At a recent conference, Clare Reddington, Creative Director at Watershed, spoke about the concept of a Playable City. A Playable City is a city where people, hospitality and openness are key, enabling its residents and visitors to reconfigure and rewrite its services, places and stories. In other words, the concept of Playable Cities enable inhabitants to interact with their cities in a way which is very different to their everyday interactions. I guess the concept can be best explained through some great examples:

Luke Jerram – “Park and Slide”

Park and slide “Park and Slide”, a one-off interactive art installation by Luke Jerram which took over a Bristol high street last year, with people taking turns on Jerram’s giant water slide.

Jonathan Chomko and Matthew Rosier – “Shadowing” 


With this project by Jonathan Chomko and Matthew Rosier, Bristol’s city lights have been given memory, enabling them to record and play back the shadows of those who pass underneath.

Design I/O – “Faces”


“Faces” is an interactive installation that captures your portrait and sketches it at large scale, projected onto a building across the street. It was installed for six months as part of San Francisco Art Commission’s “Lights on Market St” Project. During that time, Faces captured and displayed 30,000 portraits, with an average of 160 portraits a day. Pan Studio – “Hello Lampost” 

“Hello Lamp Post” was a playful SMS platform project that ran in Bristol and which enabled people to strike up conversations with familiar street furniture using the text message function of their mobile phones. As a result, people shared their thoughts and stories with streetlights, parking meters, letter boxes, bridges and boats in Bristol, with over 25,000 text messages sent by players in just 8 weeks.

Main learning point: I love the concept of “Playable Cities”, enabling people to see their cities in a new light and to interact with their everyday environments in a completely different way. Apart from the playful element involved in some of the Playable City projects, I believe that we can also learn from the new ways in which people interact with everyday objects. We can apply these learnings to other product areas and interactions.

Related links for further learning:

Leave a comment

Posted by on September 23, 2014 in Design, Gamification, User Experience


Tags: , ,

Book review: “Agile Retrospectives”

I believe that retrospectives can be incredibly valuable to any team. Taking the time every now and then to take a step back as a team and to reflect. How are you doing as a team? What have you learned from the things you did or released in the past period? Where and how can we improve? Actually starting to do team retrospectives on a regular basis is an important first step. Then you can start learning how to get the most out of your retrospective.

If you want to learn more about doing retrospectives, there are two resources which I’d highly recommend. Firstly, the Agile Retrospective Wiki created by my brilliant ex colleague Rob Bowley. This wiki provides a great wealth of tools and tips that one can use to plan and facilitate team retrospectives.

Secondly, the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen is a great resource when it comes to learning more about retrospectives. These are the main things that I took away from reading this book:

  1. Common retrospective stages – I like the retrospective structure which Derby and Larsen recommend in their book: Set the stage, Gather data, Generate insights, Decide what to do and Close the retrospective (see Fig. 1 below). This is a very useful structure to apply to your retrospective. Not only does the book outline the core purpose of each retrospective stage, it also provides concrete activities that one can do at each individual stage.
  2. Planning a retrospective – Even if you stop reading “Agile Retrospectives” after its first two chapters, you’re likely to have learned a lot already about how to best plan and structure a retrospective. The book contains a lot of practical information on how to plan a retrospective, after which it offers some very useful dos and don’ts with respect to leading a retrospective.
  3. Include a variety of activities – With the “Agile Retrospectives” book, the Agile Retrospective Wiki and the great retr-o-mat, you shouldn’t struggle to come up with activities appropriate for a retrospective. Too often I hear from people that they end up doing the same things in their retrospectives. In “Agile Retrospectives”, Derby and Larsen provide a great number of activities to choose from, depending on the goal(s) that you’re trying to achieve with the retrospective.

Main learning: For anyone who wishes to learn more about how to plan or run a retrospective, “Agile Retrospectives – Making Good Teams Great” is a must read. It contains a lot of practical tips on how to best facilitate retrospectives, making them action focused and creating an opportunity for the whole team to get involved.

Fig. 1 – Common retrospective stages – Taken from: “Agile Retrospectives” by Esther Derby and Diana Larsen, pp. 4-13

  • Set the stage – Setting the stage helps people focus on the work at hand. It reiterates the goal for the time the team has together in the retrospective. It also contributes to creating an atmosphere where people feel comfortable discussing issues. For example, as a person facilitating the workshop you could start with a welcome and an explanation of the retrospective purpose. You can then ask people in the room to speak and you can outline your approach for the session.
  • Gather data – Gathering data is an important part of the retrospective as it will help to create a shared picture of what happened. Start with the hard data: events, metrics, features or stories released, etc. You can then focus on feelings, which will tell what’s important to people about both the hard facts and about the team.
  • Generate insights – This part of the retrospective is about asking “why” and thinking about what could be done differently. Lead the team to examine the conditions, interactions, and patterns that contributed to their success. Investigate breakdowns and deficiencies. Look for risks and unexpected events or outcomes.
  • Decide what to do – At this point in the retrospective, the team will have a list of potential experiments and improvements. The team will pick the top items, decide on what to do and will action them. You can take action during the retrospective. For example, as a team you can decide in the actual retrospective to change the “working agreements” (e.g. “Everyone will pair at least four hours a day”). Equally, you can create a number of story cards or backlog items to follow up on after the retrospective (e.g. “Change the font on the homepage” or “Simplify deploy procedures”).
  • Close the retrospective – End the retrospective decisively. Decide how to document the retrospective, its outcomes and actions, and how to follow up. Close the retrospective with an appreciation for the hard work everyone did both during the iteration and during the retrospective. Finally, before you end, take a few minutes to perform a retrospective on the retrospective. Look at what went well and what you could do differently in the next retrospective.

Fig. 2 – A retrospective custom-fit to your team – Taken from: “Agile Retrospectives” by Esther Derby and Diana Larsen, pp. 15-26

  1. Learning about the history and environment of the team - Especially if you’re working with a team other than your own, study their context. When you talk to people on the team, try to find out about topics such as these: What did this iteration produce? What was the team aiming for? How did the result meet (or not) expectations? What kind of outcome will achieve value for the time invested – both for the retrospective sponsor and the team?
  2. Shaping the goal for the retrospective – A useful goal provides a sense of why people are investing their time, without predetermining what actions or direction the team will take after the retrospective. Useful goals for retrospectives include the following: find ways to improve our practices, discover what we were doing well or understand reasons behind missed targets.
  3. Determining duration – How long should your retrospective be? Fifteen minutes can be enough – or not. There’s no set formula for this. Base the length of the retrospective on four factors: (1) length of the iteration (2) complexity (of the technology, relationships with external departments, organisation of the team) (3) size of the team and (4) level of conflict or controversy.
  4. Structuring a retrospective – The structure of the retrospective – Set the stage, Gather data, Generate insights, Decide what to do and Close the retrospective – helps to bring in perspectives from all team members, follows a natural order of processing information, and moves the group towards committed action. Look at the goal that you’re trying to achieve with the retrospective and allocate a set amount of time per activity. Also allow for some “shuffle time” for people to move from one activity to another.
  5. Selecting activities – After you have the bare bones of the retrospective – the goal, duration, attendees, room, and setup – it’s time to think about activities. Activities are time boxed processes that help the team move through the phases of the retrospective. Activities provide structure to help your team think together and have several advantages over freewheeling discussion.

Fig. 3 – Demo video of the print version of Corinna Baldauf’s “retr-o-mat” – Taken from:

Agile Retrospectives

Leave a comment

Posted by on September 15, 2014 in Agile, Book Reviews, Product Management


Tags: , ,

Electric Objects brings art from the Internet into your living room

I recently found out about Electronic Objects, “a computer made for art”. An Electric Object is effectively a wall-mounted device which comes without a mouse or a keyboard. It promises to bring “art from the Internet into your home”, and I can see that it will do exactly this:

  1. Designed for the home (1) – The problem that Electronic Objects are looking to solve is that of small devices not being great for properly experiencing art on the Internet. As Electronic Objects founder and CEO Jake Levine explained to TechCrunch recently: “The devices that we use to access the Internet (our tablets, our laptops, our phones, our computers), they’re designed not for contemplation, not to live in the background, not to be quiet or still, but to demand your attention and absorb you.” Reason why the Electric Object “01” is created in such way that users don’t have to worry about all the – utility and productivity related stuff – happening on their devices.
  2. Designed for the home (2) – In a recent Product Hunt podcast, Jake Levine mentioned how digital hasn’t yet made its full foray into people’s living rooms. There are products such as Nest which cater for the whole house or the kitchen, but the “Internet of Things” hasn’t quite made it into the living room yet. Electric Objects aims to provide a product which isn’t about utility but something that can become “a part of our lives fitting seamlessly into our familiar home and work environments” according to Jake Levine.
  3. Designed to fade away – On Electric Objects’ Kickstarter page it describes how the “01” has been designed to “fade away”, like a photograph or a painting. I like that the screen of Electric Objects 01 is effectively just a frame that you can stick onto your wall. There’s no keyboard, mouse or alerts, avatars, slideshows, feeds or docks. The frame is connect to your WiFi account, which means that you can directly control the artwork on the frame from your smartphone or any other device.

Main learning point: Electric Objects have created an exciting new product in this computer made for the display of art from the Internet. Their “01” computer is now available for pre-order and it will be interesting to see how many people will buy it to bring digital art into their living rooms. Separately, I’m keen to see how many product people and designers will start to concentrate more on the ‘living room’ as a place to create digital products for. Watch this space!

Fig. 1 – An Electric Object ‘in action’ – Taken from: 


Fig. 2 – Electric Objects Founder and CTO in conversation with TechCrunch’s Anthony Ha – Taken from:

Related links for further linking:




Tags: , , ,


Get every new post delivered to your Inbox.

Join 758 other followers