1. Data in your hand. Using mobile internally.
Richard Owen, Founder & CEO, CrowdLab
Anna Tozer, Senior Insights Manager, EE
Abstract
Everything Everywhere was formed in 2010 as a joint venture between Orange
and T-Mobile. Initially it was just the corporate presence for the two brands’
operations in the UK, but in 2012 it become EE and the public face of the
organisation, Britain’s first 4G brand and the network that services both the
Orange and T-Mobile brands.
CrowdLab is a new kind of research agency, launched in April 2011 with a
mission to fuse research and technology, initially via a mobile application.
CrowdLab was founded as a joint venture between partners offering research
expertise of twenty years and a decade of software development and UX
design experience. CrowdLab offers software applications to research
agencies and corporate insight teams. With an in house development team it
flexes its core offering to provide bespoke mobile/research services for a
variety of purposes.
This paper follows the journey of EE’s mobile intranet. EE’s Insight Team held
a wealth of data, but needed to find an effective way to disseminate that data
across the various constituents of a geographically dispersed company. We
start with a discussion of the excellent Insights Site intranet, the “wow
moment” of seeing their technophobic CEO immerse himself in a tablet, the
development of a big vision for the first ever EE internal app, through the
evolving development journey and the impact on users in the organisation
since its launch.
With twists, turns, tips and tricks, we hope the reader enjoys the story and
finds plenty to ponder and inspire them on unleashing the power of insight in
their own companies in smart, mobile ways.

2. Chapter 1: In The Beginning
The Insights team is a large and critical cog in the EE organisation. They have a
wide remit and cover the collection, distillation and dissemination of insight
across four core areas:
1. Market Intelligence – who look at the broad industry picture, keeping an
eye on operator movements and KPIs.
2. Market Research – who look after information from the ongoing studies
that track customer experience, brand health and market sizing, through
to ad hoc projects ranging from product development to proposition
testing.
3. Base Analytics – who perform strategic analysis using the information
held about the customer, such as transactional and behavioural
information.
4. Segmentation, Trends & Planning – which pulls together all the other
areas of information to tell a more holistic story about the consumer from
a macro level down to very specific behavioural information.
There is a huge appetite at EE for insight, and the organisation sits on a large
amount of information; from research studies, market intelligence reports, as
well as data created out of customers’ mobile usage habits. There is almost no
end to the data that the company can play with, but the tricky part is
synthesizing that data into manageable chunks, to make it accessible so that
end users can do something useful with it.
Spreading The Love
As the first stage in the process of giving people access to this wealth of
existing data, the team launched the “Insights Site”, which sits on the
corporate intranet and acts as a knowledge bank of all of the Insights Team’s
output.

3. The site allows users to access all currently available insight without the need
to contact the team, or wait for the team to respond to queries. The site is a
significant library of debriefs, presentations, summaries as well as containing a
rich array of video content and news feeds from the press and internal
management.
It is a widely used resource, with around 3,500 users who visit the site each
month, and it also acts as a great piece of resource management which saves
the team lots of time in answering queries from colleagues. It opens up insight
to the wider company, giving everyone access to the same information, in one
place and accessible from the multiple locations around the country that make
up the EE family.
A Moment of “Wow”
As one of Britain’s leading mobile technology providers, EE were well aware of
the rising tide of smartphone and tablets that were proliferating the market,
and were already looking for opportunities exploit the potential of mobile in
research; whether this was conducting research on mobile or using mobile to
push information around the EE network.
One moment did however, light the touch paper for this initiative, and that was
seeing their then CEO interact with an iPad for the very first time. He was a
man who didn’t have a laptop or any form of computer in his office, and didn’t
find presentations and debriefs a particularly engaging way to absorb
information and learn new things. When people saw him completely absorbed in
a tablet, the light bulb went off around using such devices as a means to
connect and communicate with senior audiences in the business.

4. After The Watershed
Separately, there was an understanding that since smartphones were going to
change consumers’ lives, they would also impact internal clients (since internal
clients are consumers too). The final catalyst that propelled the growing desire
into full bloom was a segmentation that launched into the business in 2010:
As most readers will no doubt agree, if it is not fully embraced by a company,
even the most insightful segmentation will fall flat. Too often segmentations
are conducted and then left on a shelf, gathering dust, instead of being
absorbed into the fabric of the company. Continuing to drive momentum
around the segmentation was key, as was being able to tell clear and coherent
stories about the performance of the business against the segments over time.
Fortunately, this segmentation had a consistent presence across a number of
the many data sources in the business - from the customer experience
tracking, to the base analytics - so if an information system was anchored
around the segmentation, it could be the glue to stick a large number of data
sets together, to produce one cohesive whole. Smart devices could then be the
vehicle to propel this information out around the organisation.
The other impetus for the drive to mobile was that one side effect of the
success of the Insights Site was that nobody was printing things off to read
on their way home anymore. Whilst the environment was thankful for this,
there seemed like a missed opportunity to further engage people in the
information outside of sitting at their desks, and reach them whilst they were
on the go.
As mentioned, , with offices in places as far afield as Oxford, Darlington,
Hatfield, Bristol, Plymouth and London, keeping people in touch with the latest
information from remote places was critical – the intranet had started this
process, but there was no doubt that mobiles and tablets would take this even
further in terms of mobility and convenience for internal clients.
With all of this thinking in place, it was time to write the brief, find the right
partner, and get building the first ever internal EE app: exciting times.

5. Chapter 2: The Journey
When CrowdLab met EE, it wasn’t quite like when Harry met Sally - we couldn’t
afford such amazing sandwiches for one thing - but it did bring together two
parties who shared a common view of how technology could power research,
not only to gather insight but to share it too.
We agreed there were four key requirements to the system:
1. It needed to be anchored in the new segmentation and engage users
consistently in it
2. It needed to offer simple, at a glance, views of the business KPIs
3. It needed to allow users to be able to create and customise their own
pieces of analysis.
4. It needed to pull in the four key areas from the four divisions of the
Insights Team into one simple source
These last two points were particularly important:
• Customise Content – Talking to external customers frequently about how
they interact with EE products and services, increasingly highlighted to the
team that the things that worked best were those they could tailor to
their own needs, to customise and personalise. The team wanted to take
these same principles and apply them to the way they talked to their
internal clients. While the data needed to be easy and simple - so KPIs
could be viewed in an instant - it was also important to be able to
manipulate and cross analyse sources of data in ways that were never
previously possible.
• Cohesive Curation – Tying together data from research, market
intelligence and base analytics had been done before on a sporadic and ad
hoc basis, but nothing had been put in place to standardise this process.
Using the segmentation as the central pillar would give further traction to
this and give the team the opportunity to present insights in a holistic
way to the business.
User Centered Design
Whilst the general vision and requirements of the app were set, we knew that
the most important part of the process would be engaging with end users. So
nothing could begin until we had convened a series of meetings with
stakeholders across the organisation.
CrowdLab designs products along the principles of User Centered Design. User
Centered Design is (or should be) a key part of any development process, and
can be defined as:

6. “An approach to interactive systems development that aims to make systems
usable and useful by focusing on the users, their needs and requirements, and
by applying human factors/ergonomics, and usability knowledge and
techniques. This approach enhances effectiveness and efficiency, improves
human well-being, user satisfaction, accessibility and sustainability; and
counteracts possible adverse effects of use on human health, safety and
performance”
(ISO 9241-210:2010 Ergonomics of human-system interaction --
Part 210: Human-centred design for interactive systems).
In creating our own software for Market Research, CrowdLab always works
closely with the University of Leicester, and in particular with Dr. Will Green to
talk to researchers and participants to ensure it are user friendly, intuitive and
offer the features that users require.
Dr. Green gained a Bachelor’s degree in Ergonomics from Loughborough
University, and worked as a usability and user experience consultant at IBM.
His PhD at Loughborough University was awarded in Human Factors and
Ergonomics. Subsequently, at Philips Research in the Netherlands, he carried
out a fellowship, studying social intelligence as an approach to development
and as an attribute of home healthcare technology. Just before joining the
School of Management, he worked as a senior design researcher within
Vodafone Global Marketing, in the user experience strategic design team.
Dr. Green interviewed a variety of EE staff and from those depth interviews
embarked on a series of meetings with Anna and CrowdLab to start to draw up
the user journeys that people would take; from logging in to the app and then
through all of the functions and features that were desired. From this process,
changes were made in terms of the scope and scale of the app, and the
navigation layouts were devised and wireframed so that the development team
had a design to start to build from. Things were beginning to take shape.

7. Simple & Robust
One of the interesting findings from the user design conversations was the
conflict between the big vision the Insights team had and the reality of
implementation both from a technical perspective, but also the end user.
As you’ll recall (it was only a few pages ago after all) we described a key facet
was to bring four data sources into one. This means that we had 61 different
data points, each by the 9 segments of interest, leaving the user with a
possible 549 data points to choose from.
Add in the fact these would be updated monthly and in one year, and you would
have 6,588 bits of data to potentially navigate.

8. Our user design process had told us that we needed to build something that
you didn’t need to be a data geek in research to navigate, and although the
desire to be able to cut everything by everything was high on the team’s list of
requirements, the reality was that it would both create a major data mining
exercise that users who were unfamiliar with data would not then be able to
quickly create their own charts or view things at a glance.
So we had to pare back expectations.
There are many philosophies and approaches to technology and software
development, and you could choose from any number as your guiding principle.
Almost all, however, will say the same thing: keep things simple and robust.
Take, for example, the UNIX philosophy, originated by Ken Thompson: a set of
cultural norms and philosophical approaches to developing small yet capable
software based on the experience of leading developers. The most pertinent to
this discussion are:
• Rule of Transparency: Design for visibility to make inspection and
debugging easier
• Rule of Simplicity: Design for simplicity; add complexity only where you
must
• Rule of Robustness: Robustness is the child of transparency and simplicity
Let’s take each in turn.
Transparency:
A software system is transparent when you can look at it and
immediately understand what it is doing and how. At a minimum, this
implies that debugging options should be designed in from the
beginning — the program should be able to both demonstrate its own
correctness and communicate to future developers the original
developer's mental model of the problem it solves.
For a program to demonstrate its own correctness, it needs to be
using input and output formats sufficiently simple so that the proper
relationship between valid input and correct output is easy to check.
Transparency should also encourage simple interfaces that can easily
be manipulated by other programs — in particular, test and
monitoring harnesses and debugging scripts.

9. Simple:
Many pressures tend to make programs more complicated (and
therefore more expensive and buggy). Excessive complexity comes
from project requirements that are based on the whim of the month
rather than the reality of what customers want or software can
actually deliver. Many a good design has been smothered under a pile of
“checklist features” — features that, often, no customer will ever use.
The only way to avoid such traps is to encourage a software culture
that knows that small is beautiful, that actively resists bloat and
complexity: an engineering tradition that puts a high value on simple
solutions that looks for ways to break program systems up into small
cooperating pieces.
Robust:
Software is said to be robust when it performs well under unexpected
conditions which stress the designer's assumptions, as well as under
normal conditions.
Most software is fragile and buggy because most programs are too
complicated for a human brain to understand all at once. When you
can't reason correctly about the guts of a program, you can't be sure
it's correct, and you can't fix it if it's broken.
It follows that the way to make robust programs is to make their
internals easy for human beings to reason about. There are two main
ways to do that: transparency and simplicity.
We observed above that software is transparent when you can look at
it and immediately see what is going on. It is simple when what is
going on is uncomplicated enough for a human brain to reason about all
the potential cases without strain. The more your programs have both
of these qualities, the more robust they will be.
Taking all of this on board then, we designed the creation interface around a
set of rules that would only allow certain combinations of data to be displayed;
this was largely based on what would make sense in terms of output (there
were many combinations you could have potential done that would be illogical
or that would plot a nonsensical graph). In essence, we wanted to protect the
end user from making data errors.
We also restricted the choices people could make so a graph wasn’t plotted
that, for example, had 17 columns of bars which would be almost impossible to
work out what it was showing.

10. We therefore developed an iterative approach to chart selection, whereby you
could choose between:
• One segment, one brand and multiple metrics
• One segment, multiple brands and one metric
• Multiple segments, one brand and one metric
This step by step process gave people the choice to create multiple variants of
output suited to their needs, but also gave them clear guardrails so they
wouldn’t career off the analytic road.
By keeping everything simple yet robust, we were able to launch on time, on
budget and most importantly, with a much more user friendly interface than
was originally conceived.
Evolve & Grow
Part of the reasoning behind “simple and robust” is also that you want to put
out early versions of applications and then allow users to shape the experience
as they get familiar with it. You’ll never create the perfect tool, even with
extensive user centered design research, or if you attempt it, the more likely
scenario is that you’ll never launch anything.
Leaning on software development philosophies again, we employ an “Agile”
approach rather than a “Waterfall” one. “Agile” divides the tasks to be done
into small sprints of work, which are then reviewed on a frequent (fortnightly
in our case) basis. At the end of each sprint, it becomes clearer what works,
what needs adapting and what the next sprint needs to achieve. By taking this
approach, we can also incorporate user feedback and adapt and evolve as we
go. By contrast the “Waterfall” approach seeks to build towards a bigger
launch, and may involve the team agreeing the brief and then going off for
months before anything emerges – by which time it may not be quite the thing
the client wanted anymore.
Taking this spirit to EE, we agreed to launch in the simplest way possible on
the most popular devices. Thus, instead of starting by building for every
possible handset in the organisation, we built only for iOS (most popular) and
desktop (most familiar). We also decided to launch with a web app for iOS
rather than a native one, again purely for simplicity.

11. Once launched, we were able to receive feedback on the experience and start
to make adjustments to optimise the user experience. We also had to discuss
with EE the levels of engagement in the app based on Google analytics. This
suggested that whilst the uptake of the app was strong, in depth usage was
limited, largely because once you’d seen the data when updated, you could
easily forget the app existed until the next large announcement.
We also started to see the rise of Android in the business, so the focus of the
next major release was to launch an Android version – but as a native
application, so that we could include push notifications; these would allow a
more direct way to inform users that new data was available and also open up
the possibility of sending other messages of encouragement or reminders to
use the app; a more engaging engagement strategy.
Finally, once the Android version had been rolled out with success, we upgraded
the iOS version to a native app in order to provide Apple users with the same
levels of engagement and communication as Android.
It’s not an unfamiliar process; Facebook launched its mobile app as a web app –
a single build to cover all smartphones but learned that users were not having
such a great experience - with slow load times and poor navigation - due to
some of the limitations of web apps versus native apps. They then rebuilt their
iOS app entirely in 2012, followed soon by doing the same for Android. It
reaffirmed our on belief that native apps are a much better way to develop
than web apps or browser based mobile research, but that is for another paper
on another day.
Events, Dear Boy
It was Harold MacMillan that coined the above phrase, to President Kennedy, or
a journalist, or never at all depending on whose fuzzy recollections of history
you prefer to believe.
But it resonates because it’s true. The discussions about transparency,
simplicity and robustness and developing through the “Agile” lens, means that
we can quickly and easily react to changes in scope or client demands that
were not foreseen. If we build anything too ambitious, bulky or dense then
when events catch up with us, they can catch us out.
In our case, the launch and rebrand of EE, the new consumer facing brand was
a bolt from the blue:

12. So, with the new rebrand came the request to rework the app in all the new
brand glory.
The good news was, because of the way the system was designed this was a
relatively (always a good term to use in software development!) easy reworking
of the app given its simple and transparent design ethos. In fact, for the same
price as the original work (which was desktop and iOS web app only) we were
able to apply the design across desktop and two native app versions also.
The results of all our work to date can be seen in the overview of the user
journey below:
The Loading Page:

13. The Homepage:
At a glance scorecard with accordion style
“reveal and hide” device to keep on screen
information manageable
The create function with easy to select
“stepper” that only allows manageable
and sensible choices:
The visualisation screen that can then be
saved into personalised reports:

14. The segment carousel that can be flicked
through, zoomed in on and flipped for
further information:
The FAQ guide and notes:

15. Chapter 3: The Present And The Future
How has the app been received within EE?
The Insight app was the first internal app created within EE and remains so to
this day, which is something that the Insights team is extremely proud of. New
ways of adding further features or “chapters” are being discussed – for
example, sharing video content from films created around the customer
experience.
The app created a huge amount of buzz in the company and to this day, Anna
gets requests to come and speak at team meetings and other internal events
to explain it. People are genuinely wowed when they see it loaded up on her
phone or tablet. It has truly created a conversation round the data provided to
the organisation by the Insights team and given them real momentum and
presence at senior levels of the organisation.
The key benefit to most people has been to have instant access to key data
across a number of sources all in one place. Previously, to find out the latest
news and information from the customer experience tracker, one would have
to go and search and for and call up the last debrief or find the latest monthly
report. This exercise would have to be repeated for the brand tracker and the
other sources that the Insights teams provide.
Now, it is all in one place, easy to use and understand, and simple and visual in
design and interpretation.
For end users, they have this to say:
• “I really like the Insights App because it gives you access to lots of
different data sources all in one place”
• “Whenever I go into meetings, if someone asks me a question about a
certain number. I have it right here in my hand. I don’t need to say I can’t
remember or I need to get back to them anymore”
• “It’s really easy to use, really simple. It’s honed down to the information
you’re looking for right away”
What advice do we have for others?
The journey has been a success, but not without its twists and turns. There’s
always the benefit of hindsight and if we had to conclude with lessons for
others who want to embark on a similar exercise, then we’d have six things to
think about:

16. 1. Don’t overwhelm your audience – don’t try to cram everything into the
first build and be prepared to pare down ambitious visions. Getting out
there when it’s “good enough” is, well, good enough. This helps to not
overwhelm the end user in a way that launches something so complex it
puts them off engaging with it.
2. Engage with your audience consistently – the EE app wasn’t designed to
force people to interact with it every day, but to act as a tool for calling on
as and when required. The downside of this is that people aren’t always
using it and it’s not always top of mind when new data is released. Using
push notifications through native apps can help with this use, but try to
find regular ways to have a conversation with your audience about it so it
is being interacted with as often as possible and they are constantly
aware of its existence and usefulness.
3. Have a big vision then scale back – a big and ambitious vision is good, but
practicalities and pragmatism must rule the roost. Keeping things light
and simple not only provides for a better user experience, but it also
means that when things come along that you didn’t expect, and they will,
(such as the small matter of an entire organisational rebrand!) it is far
easier to deal with.
4. Play to your strengths – remember that you are an insight professional
(or a professional in whatever your craft is) and that technology
developers are experts in their field and will understand technology better.
It helps to accept that there will always be tension in the relationship
between what you want and what is achievable, so use that creatively to
work together, deferring to the relative strengths of each partner.
5. Put the end user first – if you are that insight professional that’s great; if
you are that technology developer, that’s awesome. Both parties need to
remember that the end user is likely neither, so make your applications
intuitive, easy, and designed so anybody can just pick them up and play
with them immediately.
6. The journey is better than the destination – knowing where you are
going is vital, but always know the journey is an evolutionary one where
you should learn and grow with user feedback. Only when you have
launched will you truly know what is the most useful information, what you
should do in further releases. Ultimately, be agile and don’t go chasing
waterfalls (or rainbows, or unicorns).
Thank you for reading.
Appy Days.