A White Paper: Mockups, Wireframes And Realistic Prototypes In Customer And Product Development

by Hypernumbers

1 Introduction

This whitepaper examines how you might use software mockups, wireframes and realistic prototypes in customer and product development.

Mockups and wireframes are predominately a communication tool and the various uses cases are described in terms of the desired outcomes of communication with mockups and wireframes – the desired outcomes are usually desired commercial outcomes.

2 Tables Of Contents And Diagrams

2.a Table Of Contents

1 Introduction.......................................................................................................................................22 Tables Of Contents And Diagrams...................................................................................................2

2.a Table Of Contents.......................................................................................................................22.b Table Of Diagrams.....................................................................................................................3

3 Overview...........................................................................................................................................44 Definition...........................................................................................................................................45 A Concrete Example.........................................................................................................................56 Why Mockups And Wireframe?.......................................................................................................77 Mockup And Wireframe Products....................................................................................................8

7.a Overview....................................................................................................................................87.b Old Fashioned.............................................................................................................................87.c Integral........................................................................................................................................87.d Desktop.......................................................................................................................................87.e Web.............................................................................................................................................8

8 Wireframing By Outcome.................................................................................................................98.a Overview....................................................................................................................................98.b Mockups And Wireframe Applications For Sales.....................................................................9

8.b.i Introduction..........................................................................................................................98.b.ii Desired Commercial Outcome............................................................................................98.b.iii Mockups And Wireframes In The Process........................................................................98.b.iv Key Techniques................................................................................................................108.b.v Practical Considerations....................................................................................................108.b.vi Problems...........................................................................................................................118.b.vii Selection Criteria For Wireframe Tools..........................................................................11

8.c Splitting The Purchasing Jury With A Mockup Or Wireframe................................................118.c.i Introduction........................................................................................................................118.c.ii Desired Commercial Outcome..........................................................................................118.c.iii Mockups And Wireframes In The Process......................................................................128.c.iv Key Techniques................................................................................................................138.c.v Practical Considerations....................................................................................................138.c.vi Problems...........................................................................................................................138.c.vii Selection Criteria For Mockup And Wireframe Tools....................................................13

8.d Software Specification By Mockups And Wireframes............................................................148.d.i Introduction........................................................................................................................148.d.ii Desired Commercial Outcome..........................................................................................148.d.iii Mockups And Wireframes In The Process......................................................................148.d.iv Key Techniques................................................................................................................158.d.v Practical Considerations....................................................................................................158.d.vi Problems...........................................................................................................................15

2

8.d.vii Selection Criteria For Mockup And Wireframe Tools...................................................168.e Consultancy By Mockups Or Wireframe.................................................................................16

8.e.i Introduction........................................................................................................................168.e.ii Desired Commercial Outcome..........................................................................................168.e.iii Mockups And Wireframes In The Process......................................................................178.e.iv Key Techniques................................................................................................................178.e.v Practical Considerations....................................................................................................178.e.vi Problems...........................................................................................................................178.e.vii Selection Criteria For Mockup And Wireframe Tools....................................................18

8.f Customer Development By Mockups OF Wireframe...............................................................188.f.i Introduction.........................................................................................................................188.f.ii Desired Commercial Outcome...........................................................................................188.f.iii Mockups And Wireframes In The Process.......................................................................188.f.iv Key Techniques................................................................................................................188.f.v Practical Considerations.....................................................................................................198.f.vi Problems...........................................................................................................................198.f.vii Selection Criteria For Mockup And Wireframe Tools....................................................19

2.b Table Of Diagrams

Diagram 1 – Wireframe Example........................................................................................................5Diagram 3 – Wireframe Example........................................................................................................5Diagram 3 – Wireframe Example........................................................................................................5Diagram 4 – Typical Mockup Or Wireframe Architecture..................................................................6Diagram 5 – Controlling The Customer’s Mind..................................................................................9Diagram 6 – Enterprise Purchasing Jury............................................................................................12Diagram 7 – Splitting The Jury..........................................................................................................12Diagram 8 – Wireframes In The Software Specification Process......................................................14Diagram 9 – Mockups Or Wireframes In Consultancy......................................................................17

3

3 Overview

A mockup or wireframe is typically a design artefact used during part of the overall development process as a communication and engagement tool. Its use can vary from an internal perspective:

lets build a mock up of the end-to-end process to ensure that the technical team is all on the same page

to a thoroughly outward-facing perspective:

lets do some customer development and make 15 'fake' products and go and show them to prospective customers on an iPad

As a mockup or wireframe is a communication tool it is best to categorise its use by the desired outcome of the communication: buy – mockups and wireframe applications for sales buy from me - splitting the purchasing jury with a mockup or wireframe tell me what you want - software specification by mockup or wireframe can I help you think through what you want - consultancy by mockup or wireframe would you buy this - customer development by mockup or wireframe how would you buy this - customer development by mockup or wireframe from whom would you buy this - customer development by mockup or wireframe

4 Definition

A mockup or wireframe is a simplified version of an interface which can be used to simulate the provision of a software system, service or product.

It can be used in the development of a software system, service or process for testing, asking or selling (both externally and internally).

4

5 A Concrete Example

A concrete example of a basic selling wireframe is shown below. The sales target is a carpet shop 100 yards from the author’s front door. The wireframe consists of 2 pages, one of which has a slideshow of photographs of flooring:

Diagram 1 – Wireframe Example

Diagram 3 – Wireframe Example

The wireframe was built on the Hypernumbers1 platform.

Diagram 3 – Wireframe Example

1 http://hypernumbers.com

5

In architectural terms a wireframe is traditionally seen as below:

Diagram 4 – Typical Mockup Or Wireframe Architecture

6

6 Why Mockups And Wireframe?

Mockups and wireframes are generically used to achieve a number of outcomes: clear planning of software products by testing before committing resources better and more concrete communications – work activities and prices are represented by

wireframes of systems and not documents leading to better understanding of all parties as to what is to be done

brainstorming with business people to identify better ways of working reducing the cost of experimentation easing the friction of implementation supporting rapid iteration

This paper will look at specific use cases of wireframes in various business contexts and tease out more specific and localised concerns regarding the selection and use of wireframe tools.

7

7 Mockup And Wireframe Products

7.a Overview

There are a range of commercial products and techniques available for mocking-up and wireframing, some are desktop applications and some are web-based, and some are neither. They can approximately be grouped into: old-fashioned integral desktop web

7.b Old Fashioned

Pencils (and paper). Wireframing techniques owe a lot to the old-fi practice of paper prototyping – which is not strictly in scope of this paper. The standard work on Paper Prototypes2 is well worth reading by a prospective wireframer.

7.c Integral

Integral wireframing is when the wireframe is built in the same product that the final software system, service or process is going to be – and the production of the wireframe is integral to the chosen development process – a wireframe will be produced a the beginning of the development process and morphed into the final product by the addition of functionality. In this case the mockup or wireframe will pass seamlessly into a partial prototype and onwards into a full production system incrementally.

7.d Desktop

There are a number of conventional products that are used for producing mockup and wireframes – in many cases repurposed products:VisioIllustratorPhotoshopOmnigraffleAxureJustInMind

7.e Web

Mocking BirdHypernumbersBalsamiqIplotzPidocoProtoshare

2 http://astore.amazon.com/hypernumbersc-20/detail/1558608702

8

8 Wireframing By Outcome

8.a Overview

This section will look at the following desired outcomes and how to select and use wireframe products to achieve each of them: buy – mockup and wireframe applications for sales buy from me - splitting the purchasing jury with a mockup or wireframe tell me what you want - software specification by mockups and wireframes can I help you think through what you want - consultancy by mockups and wireframes would you buy this - customer development by mockups and wireframes how would you buy this - customer development by mockups and wireframea from whom would you buy this - customer development by mockups and wireframea

8.b Mockups And Wireframe Applications For Sales

8.b.i Introduction

This is kinda what it says on the tin – using a wireframe in a normal sales process.

8.b.ii Desired Commercial Outcome

The desired commercial outcome of using wireframes in the Sales process is to make the sale.

Wireframes are only useful in selling when what you are selling is software development services.

If you are selling commoditised and productionised products and services on top of a software platform then you simply use a demo – and all the associated skills of pricing, free trials and other inducements to commit.

8.b.iii Mockups And Wireframes In The Process

Wireframes help the selling process by huckling the target of the sale attempt further down the road to purchase. The psychological process is akin to trying on clothes in the changing room of a shop. Once someone has looked at themselves in the mirror wearing new clothes they are so mentally committed to purchasing that almost nobody backs out.

The key role of wireframes is to control the terrain of the conversation – to psychically move the customer from one position in the sale process to another.

Diagram 5 – Controlling The Customer’s Mind

9

8.b.iv Key Techniques

There are three key techniques here.

The first is ‘affect’. The wireframe needs to convey the ambience of possession – my software, the solution to my problem. This is typically achieved by one or more of the following: using the customer’s name (or their organisation’s name) in the wireframe using the customer’s branding and colour scheme using other customer artefacts

their actual telephone number photo’s relevant to their business maps that actually show their business location live integration with their other online personalities

Twitter account Facebook page etc, etc

running the wireframe in the customer’s physical context: on their computer

which is on their desk beside the photos of their kids etc, etc

on their iPhone

The second technique is to give the simulacrum of completeness – a working process by using a wireframe that is as realistic as possible, one that ‘appears’ to work.

The third technique is best described by the old purchasing joke we’ve got them right where they want us – the sales technique that involves the salesman making a sham concession or admitting that they were wrong in such a way as to move the customer down the sales path – ideally over the purchasing line.

In wireframing this involves getting the customer to actually change (‘correct’) the wireframe. By doing so the customer changes their mental state from considering buying to specifying software development that has already been commissioned.

8.b.v Practical Considerations

There are some practical considerations: there need to be cost/benefit calculations

the price of sale versus the cost of wireframing who is doing the wireframing and what is the impact on company business

techies sales people

The discussion of wireframe techniques in selling are all about the psychology of purchasing – with nothing about the technical merits of different wireframe options.

10

8.b.vi Problems

The major problem here is that too successful a wireframe can depress the final price – if the customer ‘feels that the solution is there’ they will cavil at paying the actual price of you writing it.

Balsamiq address this problem by using ‘cartoon’ wireframes that give the ‘affect’ whilst at the same time making clear that the work still has to be done (and the price paid).

8.b.vii Selection Criteria For Wireframe Tools

The key selection criteria are: in what physical context will the sales person deploy the wireframe? who will actually build the wireframe? does cost of using the wireframe tool meet the cost-benefit ratios for the sale?

8.c Splitting The Purchasing Jury With A Mockup Or Wireframe

8.c.i Introduction

This is also a sales-based problem – more typically in a larger enterprise class sale. The scenario is this. A Request For Proposal (RFP) has gone out, a number of companies have responded. A short leet has been drawn up.

A number of companies (lets say 2) are now vying for the affections of the would-be purchaser. The people within the purchasing company who have a say (formal or informal) on the selection of the winning product are known as ‘the jury’ and the tactical deployment of a wireframe is an important technique in splitting the jury.

This only works if the object of the RFP requires a degree of custom development work such that a wireframe is useful because there is no actual demo to be had.

8.c.ii Desired Commercial Outcome

The desired commercial outcome is to win the bid.

11

8.c.iii Mockups And Wireframes In The Process

The typical jury process is as shown in Diagram 6:

Diagram 6 – Enterprise Purchasing Jury

The ‘nominal’ purchaser is an executive with budget – in some instances that Executive is the COO or a direct operational manager and is the same person as the Business Owner, but sometimes they are not. The jury above is shown as being made up of departments, but actually it is a jury of individuals, one or more of whom will come from each of the departments above.

The jury is divided into active members – ones who will be expected to deliver business benefits by way of operating the new software systems and blockers – people who can only prevent a particular solution being chosen but who are not active in the selection.

The strategic goal is ‘transference’ to have the key active jury members take ‘possession’ of your bid and switch the game from one of choice between equals to one of replacing ‘their’ system with another one.

Diagram 7 – Splitting The Jury

12

8.c.iv Key Techniques

The enterprise sales process is a long and painful one. Splitting the jury in this way requires that the sales team organise the bidding process to allow the wireframe team in with the key business operators. Sometimes there will be a formal pilot process whereby all competitors produce partial products, sometimes not. It is preferable from a sales perspective that only ‘our side’ wireframe with the jury.

The key technique then is to have the key jury members build and specify a wireframe to the point that they take possession of it – and psychic ‘transference’ is achieved. If the process is done surreptitiously enough, the competitors can be left completely unaware and unable to riposte.

8.c.v Practical Considerations

This situation only occurs in large purchasing decisions which usually have appropriate pre-sales budget and resources.

The practical considerations mostly pertain to the relationship between the wireframe and the final product being sold (assuming that it is not a completely bespoke software development opportunity). There may be strong practical reasons for using an integral wireframe approach – to produce mock-ups in the production deployment technology.

8.c.vi Problems

The major problems here are identifying the just and negotiating access to the appropriate jury members – this is substantially a sales team problem.

8.c.vii Selection Criteria For Mockup And Wireframe Tools

In this context mere ‘affect’ isn’t enough. Branding, using the customers name and telephone number is not an appropriate technique. The target of the wireframe activity is well along the purchasing road and has produced a detailed operational specification of the desired outcome.

Transference will only come by producing realistic operational workflow and the key selection criterion is how realistic that workflow can be made.

13

8.d Software Specification By Mockups And Wireframes

8.d.i Introduction

Software specification by wireframe is when the purchasing decisions have been all made and is the normal way in which the business people specify their needs to their dedicated IT team. That IT team can be an internal team or an external team brought in as consultants via a sales process.

8.d.ii Desired Commercial Outcome

It is well known that the cost of fixing problems in the specification of software rise exponentially. A ‘bug’ fix at the specification stage is 3, 4 or 5 orders or magnitudes cheaper than one fixed at the production stage – this is doubly true of architectural ‘bugs’

Often the business people specifying the software solution have no formal training in IT methods or techniques and are generally poor at the task.

The desired commercial outcome is reduce costs of building, running and maintaining software.

This is achieved by assisting the business people specifying the desired software to do a better job by using wireframes.

8.d.iii Mockups And Wireframes In The Process

The place of wireframes in the process is shown below:

Diagram 8 – Wireframes In The Software Specification Process

The business objectives – what the purpose of the system should be is decided. The business owners are trying to finalise the Function Specification – what the systems (software and associated manual processes) should do. The Technical Architecture states how the non-functional requirements are to be met (5,000 hits a second, deployable in the cloud, under a continuous build, with a secure sign-on, and so on and so forth).

The wireframe is used to tease out the edge cases and possibilities of the final state with a view to improve the functional specification. One of the core things is that the wireframe can be used to educate the developers about what the business does and what is important and what is unimportant from a business perspective.

14

It might appear from Diagram 8 that wireframes are useful in a waterfall development approach only – but this is to misread the diagram. A waterfall approach is basically a once-through process with a single monolithic business objectives document, a single functional spec and so on. More flexible iterative process (agile and so on) can be considered as multiple passes through the same sequence: what are we trying to achieve? (business objectives) what does it actually do? (functional spec) what technical environment are we doing it in (technical architecture) what does the tech do? (technical spec)

8.d.iv Key Techniques

The key technique here is capturing the data model and operational volumetrics correctly. The end-user has a better understanding of the overall process flow, its bottlenecks and barriers than either the business process owner (the commissioning executive) or the developers.

The major operational cost savings and improvements arise from aggressive process mapping and using data management techniques to eliminate or simplify the business processes. But in order for the business analyst or technical specialist to be able to perform this role they need to acquire the detailed operational understanding that the business users have. Identifying that the data item used here in the process is the same one that is used there is key.

Another key process is ‘disassociation’ making clear that the wireframe isn’t the final solution. A nice way of doing this is the ‘cartoon’ technique of Balsamiq, where the hand-drawn aesthetics of the wireframe make it clear that it is not an operational system.

8.d.v Practical Considerations

The practical considerations are largely determined by the type of project.

If the software is to be delivered in a mature environment then the technical architecture might be heavily determined already and an integral wireframe approach might be appropriate – wireframing the same technology that the final solution is to be written. Integral wireframing, however, is done by technical staff. If the project is highly iterative, and the technical staff are in short supply, this might prove an insuperable resource drain.

In a new environment where the technical architecture is not yet determined, then an interim wireframe technology is called for.

8.d.vi Problems

The problems remain: misrepresenting progress by wireframe fidelity and the consequent mis-setting of expectations who does the wireframe – business analyst versus software developer inability of the wireframe to capture data and data issues correctly

15

8.d.vii Selection Criteria For Mockup And Wireframe Tools

The key selection criteria are: business versus technical users of the wireframe can the wireframe capture and annotate data appropriately? is the final architecture fixed, and does the team and implementation structure lend itself to

integral wireframing?

8.e Consultancy By Mockups Or Wireframe

8.e.i Introduction

Consultancy is typically the exploration of strategic options for change within an organisation.

The consultancy can be an ‘internal’ consultancy where there is a strategic review exercise undertaken by existing members of staff, or an external one where the consultants are brought in from outside to support the process.

Each type has slightly different commercial outcomes.

Clearly, in only a small subset of consultancy work is wireframing a suitable option – primarily when an attempt is being made to tackle core business processes with a view of transforming them in the round – a process which requires a coherent picture of a whole systemic process to be built.

8.e.ii Desired Commercial Outcome

The desired outcome is that the end client explores the options for change in their operational environment and produce optimal business objectives as a result of a specification process that is both experimental and analytic.

If the consultancy is an external one the consultants may have the objective of winning the follow on work (if it is to be outsourced). May large companies specifically exclude companies who have worked on the production of a RFP from following on and bidding for it – precisely to eliminate the temptation for the consultants to steer the purchasing towards their company and its technology strengths.

16

8.e.iii Mockups And Wireframes In The Process

This is related to software specification by wireframe – it merely takes place earlier in the process as shown below:

Diagram 9 – Mockups Or Wireframes In Consultancy

8.e.iv Key Techniques

The key techniques here is to stimulate the creative thinking by exploring the potential landscape of change – mocking up new process and identifying potential changes in the cost model afforded by each of them.

The wireframes need to display and represent data items which can be captured and mapped to existing systems and process and used as the basis of an analytic exploration. They key is to identify redundant data and processes and work out how to eliminate them.

The problem here is the same as in specifying software by wireframe. The business owners with the operational and cost knowledge lack the technical skills to perform data and process analysis and the consultants with the technical skills lack the operational knowledge to analyse, assess and prioritise the changes appropriately. The wireframe technique allows the operational experts to reify their knowledge in a form that that the technical specialists can push back suggestions.

Involvement of the Management Information or Analytics team is critical to this process and they alone have the ability to price up the cost and benefits of the various options – and in an ideal world there will be a plethora of options thrown up and explored (so-called blue sky options).

8.e.v Practical Considerations

The practical considerations are that the wireframe outcomes are destined to be thrown away – they are not connected with implemented operation software in any way.

8.e.vi Problems

The may be a problem with participants mistaking the wireframes for prototype operational systems but this can be obviated by using ‘cartoon’ techniques such as those pioneered by Balsamiq.

17

8.e.vii Selection Criteria For Mockup And Wireframe Tools

Consultancy teams are typically light on technical resource and the wireframing needs to be done by business-focussed team members – the wireframe tool must be selected accordingly.

8.f Customer Development By Mockups OF Wireframe

8.f.i Introduction

The purpose of customer development is to test a wide range of hypotheses pertaining to a business in as cheap and effective a way as possible before committing large amounts of capital investment to the proposition.

Customer Development as a discipline largely takes its inspiration from the book Four Steps To The Epiphany3 by Steven Blank, although its popularity has been driven by people such as Eric Ries4 and other lean practitioners. It is also heavily driven by the metric-orientated viewpoint of key investors like Dave McClure5.

The various hypotheses which may be tested y mock ups and wireframes in customer development may be as varied as: product ideas and customer propensity to purchase them customer problems and putative solutions channels to reach customers demand creation techniques – processes that turn people are made into customers business model issues – how the product intercepts the flow on money in service provision

(There are other hypotheses to be tested in customer development but they are not strictly relevant in this white paper – for a fuller understanding please read Four Steps To The Epiphany.

8.f.ii Desired Commercial Outcome

There is a janus-faced outcome to customer development – build something people want and will pay for/don’t build anything people don’t want and won’t pay for.

8.f.iii Mockups And Wireframes In The Process

Mockups and wireframes can be used in a variety of different ways in the process, for: stimulating customer discussion building online systems for testing propositions

propensity to use propensity to buy

prototyping ecosystems

8.f.iv Key Techniques

One of the key matra’s of lean startups using customer development is there are no facts in the building, only opinions – the notion that learning from the customer is very important.

3 http://astore.amazon.com/hypernumbersc-20/detail/0976470705/185-7932152-27599644 http://www.startuplessonslearned.com/5 http://500hats.typepad.com/

18

The key technique then of mockups and wireframes is to use them to be able to stimulate the interest of the potential customer to the extent that they are willing to talk about their problems, the solutions they have in mind for them and the role the putative product might play.

The customers’ responses to propositions, their thoughts and observations need to be captured in a systematic way and fed back to the team to ensure that the product development encompasses them. The mockup or wireframe should capture customers intent, either automatically, or by allowing annotation of the proposed application or process by the potential customer of the interlocutor.

Sometimes ‘getting out of the building’ means getting test systems online and driving potential customers over it using Google Adwords or the like, the same principle pertains – present a proposition to potential customers and measure their reactions to it, both quantitative and qualitative.

8.f.v Practical Considerations

The practical considerations pertain to access. How will the potential customer interact with the mockup or wireframe: on their own computer at work or at home? on their iPhone? alongside the person doing customer development? anonymously on the internet?

And how will their feedback be captured: from the intent they display by using the mockup or wireframe tool? via formal information capture built into the mockup or wireframe tool? through observation

8.f.vi Problems

The major problem is identifying and access the appropriate potential customers and building a mockup or wireframe that appropriately matches their circumstances without undue cost and delay.

8.f.vii Selection Criteria For Mockup And Wireframe Tools

The selection criteria are based on: the delivery mechanism

whose computer or iPhone where the user will consume the mockup

who is to create and test the mockup or wireframe usually non-technical numbers of the team but increasingly startups are insisting that all team members, including techies, be in front of

potential customers at some time or another

Integral wireframing often appears the natural medium for this but that can dramatically skew activities in the team by sucking up technical team which may induce the non-technical members of the team from avoiding customer discovery activities on the ground that we don’t have the bandwidth which is entirely counter-productive.

19