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: 


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


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. The scenario should consist of a Given, an Event and an outcome – When describing a behaviour change or a scenario, the following elements should be included: a Given (some context), an Event (‘when I do this’) and an outcome (‘then this happens’). In addition, I like adding a sentence to outline the ‘so what’ of a certain outcome, describing the intended benefit to the user.
  4. 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).
  5. 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.”
  6. 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.
  7. 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.
  8. 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 – More examples of good user stories good and scenarios – Taken from:

Story: Account Holder withdraws cash
As an Account Holder
I want to withdraw cash from an ATM
So that I can get money when the bank is closed
Scenario 1: Account has sufficient funds
Given the account balance is \$100
 And the card is valid
 And the machine contains enough money
When the Account Holder requests \$20
Then the ATM should dispense \$20
 And the account balance should be \$80
 And the card should be returned
Scenario 2: Account has insufficient funds
Given the account balance is \$10
 And the card is valid
 And the machine contains enough money
When the Account Holder requests \$20
Then the ATM should not dispense any money
 And the ATM should say there are insufficient funds
 And the account balance should be \$20
 And the card should be returned
Scenario 3: Card has been disabled
Given the card is disabled
When the Account Holder requests \$20
Then the ATM should retain the card
And the ATM should say the card has been retained
Fig. 6 – A simple example of a user story outlining a 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:

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