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.......................................................................................................................................2
2 Tables Of Contents And Diagrams...................................................................................................2
2.a Table Of Contents.......................................................................................................................2
2.b Table Of Diagrams.....................................................................................................................3
3 Overview...........................................................................................................................................4
4 Definition...........................................................................................................................................4
5 A Concrete Example.........................................................................................................................5
6 Why Mockups And Wireframe?.......................................................................................................7
7 Mockup And Wireframe Products....................................................................................................8
7.a Overview....................................................................................................................................8
7.b Old Fashioned.............................................................................................................................8
7.c Integral........................................................................................................................................8
7.d Desktop.......................................................................................................................................8
7.e Web.............................................................................................................................................8
8 Wireframing By Outcome.................................................................................................................9
8.a Overview....................................................................................................................................9
8.b Mockups And Wireframe Applications For Sales.....................................................................9
8.b.i Introduction..........................................................................................................................9
8.b.ii Desired Commercial Outcome............................................................................................9
8.b.iii Mockups And Wireframes In The Process........................................................................9
8.b.iv Key Techniques................................................................................................................10
8.b.v Practical Considerations....................................................................................................10
8.b.vi Problems...........................................................................................................................11
8.b.vii Selection Criteria For Wireframe Tools..........................................................................11
8.c Splitting The Purchasing Jury With A Mockup Or Wireframe................................................11
8.c.i Introduction........................................................................................................................11
8.c.ii Desired Commercial Outcome..........................................................................................11
8.c.iii Mockups And Wireframes In The Process......................................................................12
8.c.iv Key Techniques................................................................................................................13
8.c.v Practical Considerations....................................................................................................13
8.c.vi Problems...........................................................................................................................13
8.c.vii Selection Criteria For Mockup And Wireframe Tools....................................................13
8.d Software Specification By Mockups And Wireframes............................................................14
8.d.i Introduction........................................................................................................................14
8.d.ii Desired Commercial Outcome..........................................................................................14
8.d.iii Mockups And Wireframes In The Process......................................................................14
8.d.iv Key Techniques................................................................................................................15
8.d.v Practical Considerations....................................................................................................15

2
 8.d.vi Problems...........................................................................................................................15
8.d.vii Selection Criteria For Mockup And Wireframe Tools...................................................16
8.e Consultancy By Mockups Or Wireframe.................................................................................16
8.e.i Introduction........................................................................................................................16
8.e.ii Desired Commercial Outcome..........................................................................................16
8.e.iii Mockups And Wireframes In The Process......................................................................17
8.e.iv Key Techniques................................................................................................................17
8.e.v Practical Considerations....................................................................................................17
8.e.vi Problems...........................................................................................................................17
8.e.vii Selection Criteria For Mockup And Wireframe Tools....................................................18
8.f Customer Development By Mockups OF Wireframe...............................................................18
8.f.i Introduction.........................................................................................................................18
8.f.ii Desired Commercial Outcome...........................................................................................18
8.f.iii Mockups And Wireframes In The Process.......................................................................18
8.f.iv Key Techniques................................................................................................................18
8.f.v Practical Considerations.....................................................................................................19
8.f.vi Problems...........................................................................................................................19
8.f.vii Selection Criteria For Mockup And Wireframe Tools....................................................19

2.b Table Of Diagrams

Diagram 1 – Wireframe Example........................................................................................................5

Diagram 3 – Wireframe Example........................................................................................................5
Diagram 3 – Wireframe Example........................................................................................................5
Diagram 4 – Typical Mockup Or Wireframe Architecture..................................................................6
Diagram 5 – Controlling The Customer’s Mind..................................................................................9
Diagram 6 – Enterprise Purchasing Jury............................................................................................12
Diagram 7 – Splitting The Jury..........................................................................................................12
Diagram 8 – Wireframes In The Software Specification Process......................................................14
Diagram 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:
Visio
Illustrator
Photoshop
Omnigraffle
Axure
JustInMind

7.e Web

Mocking Bird
Hypernumbers
Balsamiq
Iplotz
Pidoco
Protoshare

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-2759964
4
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