New Notebook: White Piece of Paper Syndrome!



Just Enough Design

Working within Agile, Lean UX and Lean Product Development, one of the biggest shifts away from the  previous ntion of  Big.Design.Up.Front thinking is another question. The question of how much design is enough? How much ‘design’ do I need to produce and what form does this need to be in? When is a project finished? How do I know what I am working on is getting better and not getting worse? These are confusing questions.

Just enough is about right for right now
One of the biggest challenges I initially faced was to realign my main design deliverables. Even in non-waterfall processes, design is still sectioned off as a finite process that then is (usually badly) fed into the product. Its a one way street, you design it, it gets implemented. Product shipped.

Now I look as being the product itself as being the final design document. Whatever design artefacts I produce, then need to go directly into the product over many many times in the product development trajectory. What comes from this is an understanding that the product is always evolving and always moving forward, and my design work would feed and nourish that process.

In the past, I would be heavily reliant on producing thorough and comprehensive design documentation to describe features, interactions and use of the product. I would try to think about the entire ends of a project and use visual design artefacts to describe this this. This comes at a potential cost. Even if you are working in agile, if you work like this then it’s a proxy version of BDIF as you’re layering on too much design for that stage of the product. The risk is that the features you are designing the interface to support those features, without a direct need from a customer than its a potentially wasted effort.

Its almost impossible to understand every context in which the interface you are designing is going to be used and in many cases these wont be relevant anyway. Basically, new product development operates in a world of massive uncertainty. Many times, the actual use of the product throws up new questions and new scenarios that you have not thought about. Inversely, you may think that the certain facets should be mandatory in the design, but find out later that this assumption were thoroughly wrong. The time to fix those situations is when they occur rather than trying to guess at a products potential use and use those guesses to inform the design work.

Refocusing design work

The general approach I am trying to implement is to Onion skin design into the product, which a colleague and co-worked used in reference to a product we were working on. It refers to  the continual layering of both the fidelity and sophistication of design work over time, into a product.

The first simple rule is that any design artefact that’s produced needs to have direct value to the UX and UI of a product.  In a lot of cases the immediate  design requirements are pretty small as the greater context is still yet to be defined.

It could initially be a over-arching grid structure for the layout of UI elements on a screen, or  It could just be a design detail about a nav-bar, or a suite of icons to be used,maybe a couple of button states or a page showing a master-detail relationship between a parent and child. The fidelity may also vary,it may be a sketch, agreed on by the group as part of a joint design session attended by the whole team. Later, it may be wireframes through to high fidelity screen mockups.

What this means is that as a designer, you can continually produce design and interface refinements that both continually increment the products value and are implemented within the product. This is rather liberating. It means you embrace a willingness to make mistakes, to be wrong, and a willingness to change your thinking if required. You initial ideas may change with each increment as feedback from each iteration the design should should feedback into the next round of design work.

This is how I know how much I need to produce, it is always just enough for that stage of development. Just enough to provide value to the product in the most efficient way possible and Just enough to not hold up the development team so they can also keep moving forward. From rough group sketches through to complete UI Component libraries and screen designs, just enough is the incremental improvement of product through many many many design iterations, each one better than before.

The Pixel Painter from The Pixel Painter on Vimeo.

Pixel Painter – its not the tool but the maker

Cormac macarthy sold his pultizer prize winning typewriter for over a quarter of a million dollars, and then proceeded to get exactly the same model or $20.

I sort of know how he feels….


Haba – Animal on Animal

A copy of Haba’s Animal on Animal arrived this morning and it was a hit in the 5 mins we played before going to school.



I have been wireframing and building the iOS prototype for this new phonics game I am planning to release through Bottlerocket. With this identity beingthe first bit of hi-fidelity visual design work that I will produce for the app.

I am a firm believer in the lean product methodologies written by Eric Reiss in Lean Startup, but find it a struggle as a designer with the discomfort of low-polished work.

Doing non-crictical aspects of the presentation layer of a product (such as the identity) helps formulate the product story better and plant in your mind and others, the possibilities of what this product could be. Mixing low-fidelity prototypes with a single piece of identity work helps the potential customer fill in the missing details about what they are seeing right now(which may well be a bit rubbish) and what the product might be.


Initial sketching

As a side thread to some of the consulting product development, and my children’s publishing venture Bottlerocket ltd, I also have developed a number of other products that fall outside of those two main areas. As a way of showing its humble beginnings, most ideas a born from a thought jotted into a notebook and then worked up to from there. This can take the form, as in BitBusyNow, as not just the basic UI but also showing the environmental position of the device as this was critical to recording the context of that particular idea.

Prototyping with Briefs for Mac

One of the issues that always presents a challenge when developing an MVP is not only working out what the MVP should be (what the hypothesis it is testing and what form it should be) but beyond that, if a viable product requires a prototype, whats the easiest investment in terms of time and money to get something that can elicit some valid feedbak.

Briefs, from the demo video looks pretty good based on the above demo. However, it doesn’t seem to currently have anything to offer other than simple hot-spot assignment to move through a gallery of pre-canned screens. An author adds hotspots to each scene (read:screen) and then links them all together by assigning actions to each hotspot to load in.

This could produce some pretty unwieldy prototypes. Especially if you were wanting to test anything with any deeper interactivity than simple touches? At this stage I have no idea if Briefs can handily basic variable assignment through to the authoring of reusable widgets. A 30 day trial would have been really helpful here.

Start at the end.


The above is a basic coloured in ‘framework’ I did for a storytelling maths game I was developing with my daughter. It was based a a finger counting game that we used to play, that helped teach basic addition and subtraction. The issue with it though is that it never made it into deployment stage, because there was a focus on getting the story modules right which meant the learning modules were never completed.

This approach is fundamentally flawed because for a product like this, as the key element really was making the interactive learning elements as fun and engaging as possible. This should have been the highest priority. It is also understandable why I fell into that trap. When building a product, as especially as in independent design and development house, it’s really great to look at the whole product and mapping out the entire application and then back-fill in the interactive modules. That way you can focus on aspects like scalability and start providing an answer to the question “how do I add in more modules later on?”

However, If I had the time again, I would simply build the learning modules first. Kids, don’t care about scalability.Making the learning as fun and engaging as possible is really all that matters and should be the highest priority.

Pills here by Robson#

Once a day

At LegUp yesterday, daily blogging of just 15 mins per day was a key marketing recommendation for not just people working in the edu games market, but for all entrepreneurs as key for self promotion and getting your message out there.