The Time Warriors

Your mobile phone is your savior. It tells you the time (and now you have a Watch to do that :D), it helps you plan your day and schedule your meetings for weeks in advance. Mash up this with cool tools that take away the pains from joining conference calls (the conference call app) and you will glide through your calendar effortlessly.

The ‘Up in the air’ personas expect more from their mobile / apps – they are on the road, have their calendars already planned days in advance and have to carefully accommodate the last-minute calls or meetings. Their productivity is defined by the time wisely used, and by the time wisely planned.

Here is a concept in the making – an app which gives anyone who wants to manage their work day efficiently. Right from the daily overview, to the weeks of business-as-usual, to the grinding monthly travels. The app syncs with your inbox and calendars on the device + in the cloud, reads your travel schedules and gives a unique view of your time.

Whether you are a CxO or a busy parent, this app will help the time warriors – on the road or off it.

The Time Warriors - Page1

The Time Warriors – Page1

The Time Warriors - Page2

The Time Warriors – Page2

Time is the essence

Bill Gates wrote a book called “Business @ The Speed of Thought”. I don’t remember exactly when I read that book, but it did impart me the sense of urgency one needs in business, and in design.

Fast forward to recent times when I was working in an agile software development project. User stories are the holy grail for design & development. People revolved around stories, epics, acceptance criteria and got the work done in sprints.

In one of my projects for a telecom operator, I was designing the reports module. I sketched two explorations of the UI.

Here is how the UI is supposed to work – It is a progressive disclosure (step wise reveal).

1) On the page, only Data Source choice is seen first. User starts with a selection of data source.

2) Report selector is then shown to the user. User chooses a report name.

3) The page shows up the report columns to build the query.

4) The user clicks “Generate Report” button and the report is shown to the user.

Exploration #1

Exploration #1

Exploration #1

Exploration #2

Exploration #2

Exploration #2

Notice the differences in the approach – in Exploration#1 report column selection can be done by drag-n-drop of column names. In Exploration#2, there are additional filters for reports, “Save as Favorite” action to the report, contextual data presented to the user as “related reports”.

Exploration#2 was finally chosen by the development team.

Time to create these two explorations, discuss and select was 1 hour.

Time is the essence.

“We want new concepts”

How often you hear these words from the bean counters? No need to dwell on the count. Just get the work done :).

The example I am presenting here is an enterprise dashboard application of a telecom operator. Dashboard gives a summary view of its enterprise customers – what contracts are expiring, no. of sales opportunities, escalations, ticketing reports, etc. It also gives the ability to dive down and see the granular details of enterprise customer data.

This was a legacy application created by mashups – typical scenario of multiple heads managing volumes of data with disparate technology platforms talking to each other. End result was a ‘patch-work’ application that suffered experience issues of the data (incomplete data, irrelevant data) and performance.

Imagine I am the user, a sales executive. If I log in to the dashboard application I see partial data on the CSAT, sluggish data on the contracts that are expiring and incomplete data on the new opportunities.

If I am a program manager and want to see escalations of a particular customer, selection of 1 year ticketing records would generate 11 million table rows. This would slow down the performance and hamper the user experience. Now imagine this scenario both in the web browser on your computer and on an iPad native application.

You might be thinking now, where are the user experience issues? Hang on to that thought.

This is what you are told –

1) You cannot contact users.

2) You can play around with the existing application. But remember, don’t break it.

3) We know user experience is not the problem. The real issues are data binding and performance.

4) “We want new concepts”.

Here is the concept #1 – Zoomable Interface

Zoomable Interface - 1

Zoomable Interface – 1

Zoomable Interface - 2

Zoomable Interface – 2

Zoomable Interface - 3

Zoomable Interface – 3

Zoomable Interface - 4

Zoomable Interface – 4

Zoomable Interface - 5

Zoomable Interface – 5

Zoomable Interface - 6

Zoomable Interface – 6

Zoomable Interface - 7

Zoomable Interface – 7

Here is the concept #2 – Spider Chart Interface

Spider Chart Interface - 1

Spider Chart Interface – 1

Spider Chart Interface - 2

Spider Chart Interface – 2

Spider Chart Interface - 3

Spider Chart Interface – 3

Spider Chart Interface - 4

Spider Chart Interface – 4

Here is the concept #3 – Data Visualization Interface (not a fully designed user journey).

Data Visualization Interface - 1

Data Visualization Interface – 1

Data Visualization Interface - 2

Data Visualization Interface – 2

Data Visualization Interface - 3

Data Visualization Interface – 3

So what concept was finally chosen? None. The development team cited issues related to time and tweaked the existing UI. Even the low hanging fruits in the UI turned out be sore.

Infographics – Resource Utilization Summary

When you are part of a corporate ladder, you are bound to do things you do NOT want to. If you are a designer acting like a design manager in a software services organization, then brace yourself for challenges ahead.

One of the duties that you assume in this role happens to be team management. Imagine there are 5-6 designers report to you and you need to ensure that they are 100% billable. Services organization needs granular data of employees like utilization of employees, what business any employee is accountable for, how much back-dated billing has happened for an employee, etc.

Team management was one of my duties in my earlier job. The tool used to track my team members was not helpful at all. It did not give me any idea about RUS (Resource Utilization Summary). Confused navigation and inappropriate content of the RUS tool drove me to maintain my own spreadsheets of data. But something was still missing.

As always, necessity is the mother of invention. Getting lost and landing up on wrong floors of the TechMahindra building through elevators had made me design infographics for elevators. This time, I took the same approach for team management and created an infographic.

This is how it looks:

Infographics : Resource Utilization Summary

Infographics : Resource Utilization Summary

The header section shows summary of the team member. The 5 columns show the overall utilization of the team member across 5 months. “RUS” means Resource Utilization Summary generated by team management tool (a customized tool in TechMahindra). PMTs are project codes assigned to the team member.

As always, sketching on paper helps :).


“Sell this pen to me…” says Jordan Belfort in the movie “Wolf of Wall Street”. Let’s put aside the personality profile of Jordan for the moment, and concentrate on the “selling” aspect.

“Designing a solution is 30% of your job. Communicating and selling your design is 70%” were the wise words of my mentor.

You can be a great designer, doodling in isolation and toying the product with great tools. Your design will never make it to the market if you are not able to showcase your designs with a story.

That’s right. You have to orchestrate your story about the design to your audience – who are willing to guide it, nurture it with their money and resources.

Let’s say that you have quickly sketched out user journeys for key user tasks. You might be working in a agile model of software development. You want to validate the designs created – e.g. iPhone app for banking consumers. There are 3 key tasks in your sketches – view balance, bill payment, add a new credit card.

This is how I would present the paper prototypes to the audience and get their feedback:

1) I will invite all key decision makers & influencers (product manager, development lead, business analysts, system engineers, etc) in a conference room with a 30 minutes time slot.

2) On the soft board, I will pin up paper sketches in a sequence.

3) I will have another design team member, preferably UX researcher – to take the notes of the discussion. It is important that one talks (me) and the other (UX researcher) jots down the points as design inputs.

4) I will summarize what the session is all about to the audience. I will set a context first, when and how the user is going to use the app – what time of day, what place, and what is the trigger point of launching the app.

Since we are talking about a mobile app, I will use specific usage behaviors to weave the story and the sketches – e.g. how users people are motivated to finish a goal, how users prefer shortcuts, how the content takes precedence over navigation in mobile apps, how users’ mind wander 30% of the time, how users make mistakes, etc.

When you cite these examples, it is good to have a workable solution in your sketch. The audience is there to hear you narrate different scenarios they have NOT visualized. As a designer, it’s your job to make them VISUALIZE and give their inputs.

Do not just restrict your presentation to pinned up sketches. Take out the phone from your pocket and show your audience some noteworthy examples. If needed have another photo-essay running that connects the sketches with the user context. You may also compile and get some user research data and quote. Get anything in terms of products / examples / packaging designs / tools / applications that connects with your sketches and triggers the audience’s reaction.

So what do you once you have gathered inputs from your audience?

Tweak. Tinker. Iterate.

Build a story, and sell.

Once you have a feeling that design on paper is great, step into Axure, Adobe Fireworks, Sketch and iRise to create digital wireframes.

That concludes all the segments of how to create paper prototypes. In the following posts, I will share the actual sketches I have designed for some projects.

The anatomy of paper prototyping

Over the years, I have witnessed the change in how I approach any design problem. And create design explorations for the problem.

The change could be credited to factors like new tools being available, understanding the deeper sense of design, adding more granularity to the design deliverables, interconnecting the relationships between different variables, etc. This is an ongoing process and the learning never stops :).

There are different ways to start off and design for any context. End to end user experience design lifecycle is expressed in different forms by different design agencies – the sub processes change a bit, but the essence remains the same. On a high level, any user experience design project will fall into four distinct buckets – (a) requirements understanding (b) conceptualization (c) prototyping (d) implementation / deliver.

Paper prototyping falls into activity (c). Some might be inclined to slot into (b) as well, its acceptable. May be it falls in both areas. Purists will never stop arguing, pragmatists will get the paper, sketch it out and pitch the design :).

I have used paper prototyping technique most of the times in presales process. It helped me a lot. While I do this step in the detailed design activity (low and high fidelity prototyping), it’s the pre-sales paper prototypes that have garnered the customer ‘wow’. Once you go past that stage and enter the delivery cycle, wow is replaced by ‘now’ (“I want this to be designed now”). Nevertheless, paper prototypes will never let you down.

So how does one go about designing the paper prototypes?

Here’s a 4-step approach.

Step 1) Understand the ecosystem
Get answers to these questions – Who is the real user of the product / service? What are the dependencies? What is the overall goal? What are the controllable and uncontrollable variables involved? Who are the stakeholders? What are the different business processes?

Once you get the answers, be as visual as you can. Create mind-maps, information graphics or any other graphical form that expresses “the big picture”. Yes, the big picture.

Step 2) Create the information architecture
Understand the different “information buckets”, the hierarchy of information and create information architecture. Some might be comfortable to see and depict the relationships among data, which serves well too.

Information architecture will help you understand the length and depth of the information the product / service holds. Having information architecture ready is like having a blueprint ready of your product.

Step 3) Create the user task matrix
Write down these questions – How many times a user is going to perform a specific task? What is the input user needs to perform this task? Will the product / service break down if the user does not do the task? What are the dependencies of this task with other tasks?

Some designers might consider skipping this step and creating “task flow” – its perfectly fine. The idea is to understand the nuances of user tasks – who does it, when and how.

Step 4) Understand the target device considerations
Is it an iPhone app? Or an enterprise dashboard seen on a tablet? A good-old fashioned desktop application used by legacy users whose keyboards squeak every time they press any key?

Of course, connect this point with real-life usage context too. E.g. this is a point-of-sales application to be used by a sales agent in a crowded grocery store on a monitor with screen resolution 640×480.

You are welcome to add your steps in between or skip some of these steps. Whatever works for you, works better. These 4 steps have worked for me, so far. And as I said earlier, I may refine these steps as I learn new things down the line.

We will expand these 4 steps in coming posts.

Examples of paper prototypes

Before we get down to the actual process of creating paper prototypes for the digital products, I would like to share some samples. These samples gives the spectrum of the different domains that we can apply paper prototypes to. As a matter of fact, paper prototype is one of the de facto steps of user experience design process.

Here are some sketches I did for different design problems:

Example #1

Cricket based iPad application

Cricket based iPad application

Example #2

File format convertor desktop application

File format convertor desktop application

Example #3

Enterprise portal for interaction design pattern library.

Enterprise portal for interaction design pattern library

Example #4

Enterprise portal application for payment cards industry

Enterprise portal application for payment cards industry


Windows tablet application for educational repository

Windows tablet application for educational repository

Check out the way these prototypes are done – the elements that make up these prototypes. What is the starting point? How to visualize the flow? What things need to be taken care of before building the prototype? What is in scope / out of scope?

Let’s discuss this in our next post.

Before you start…..

Paper prototype does have its advantages over other visualization techniques. It is a carefully crafted activity that transforms all the “blah blah blah” into concrete form.

I have been the proponent of paper prototyping for many years. Though this design tool helps you to design technology-agnostic solutions (enterprise portals, dashboard, mobile apps, interactive television program, etc.) there are some aspects of this process which you want to consider before you start sketching.

1) A mature customer
User experience activities are generally driven by user experience practice managers or product managers or the CxOs of the organization who really care about product they want to design for mass consumption. A mature customer is the one who will encourage to go deeper down the fundamentals of requirements (talk about user psyche and cultural memetics), sit down with the designers in brainstorming activities (.e.g. card sorting, quick and dirty concepts, etc.) and help UE designers understand the big picture (ecosystem, processes, inputs and outputs). Its fair to assume that in practical scenarios all these tasks are divided between different team members and you rarely come across a customer who will provide you inputs at one go. The bottom-line – revealing key information to UE designers is a must. Some nuances of user information directly determine what you are going to put on the paper.

2) Technology is a magic box
We are familiar with all types of UI patterns around us. The ubiquitous widgets, controls, patterns have made us wiser in picking and applying those UI patterns in familiar situations. E.g. we will not choose art cover pattern for address book. Sometimes it does help to take out these patterns from your library, print them and take them with you.

Even its good to have data visualizations with you. iOS, Android, Windows mobile and other OS-specific UI controls will be handy too. The idea is that you can create a fusion of available patterns that justifies the user journeys. If you are that brilliant, you can even invent one :).

When you put down these patterns on a paper you are creating a technology-agnostic solution. You don’t care about whether its going to work or not (that will be done after you put things on paper, by the development team). For you, technology is a magic box. And you are the magician.

3) Time keeping & granularity
Regardless of the software development life cycles that you are participating in, paper prototypes are designed in a very fast and effective manner.
It may be good to go with a team size of at least 2 UE designers who can divide the user journey amongst themselves. What level of details you incorporate in your paper prototypes will directly determine the overall timeline of your work.

While designing the paper prototypes, keep in mind the verbiage/content/user vocabulary. Its better to draw granular details on paper – it removes abstraction, helps in exploring design options (if you want to chose from UI patterns) and makes the design believable. You are the best judge of what will go on to the paper. Aid paper prototypes with your comments, Post-it notes, etc.

It is possible to compact the paper prototyping activity in 3/4 days or a week. It depends upon how much time your customer is willing to put in this activity. For all the ideas that are emerged in these days, take a judicious call about what you want to sketch.

4) Tools of the trade
Papers, pencils (0.7mm is my preferred choice), color pencils/pens, highlighters, markers, Post-it notes, scales, cutters/scissors (to cut papers), push-pins, soft-boards (to put your paper prototypes for discussions), cello tapes, double-sided tapes, camera (to capture white boarding activities) and a scanner (for scanning the paper prototypes).

5) Beyond paper prototyping
Paper prototypes are generally throw-away prototypes. Meaning, that these prototypes will get mature over discussions and time. One should not get too much attached with these paper prototypes. Their existence and usage is limited. One has to churn many iterations of the same prototype over weeks before latching on to a concrete idea.

Involve development team from the start – they also have a say in what we design. But don’t kill your ideas on paper. Paper prototypes that survive and mature over the time are finally taken to the wireframing stage – you digitize everything that has been recorded on paper. One of the pitfalls of paper prototyping is that it does not have interactivity. Wireframe design is the next logical step once you are done with paper prototypes.

It all starts on paper…..

During my design school days (8 yrs ago) when I was working on interaction design projects, paper prototyping helped me a lot in giving the concrete shapes to my abstract ideas. Paper prototyping cleared a lot of ambiguity. I was able to demonstrate how the digital product would look like and how it will behave.

Since then, I have been an ardent follower and practitioner of paper prototyping. I have seen that some interaction designers have an inclination to skip this step and jump directly to tools like Axure, iRise, Visio, etc. The interaction design students too have tendency to disregard the power of paper prototyping and the possibilities that it opens up.

Paper prototype helps you to give concrete form to the user task flows. It is a starting point of everything related to your digital product design. A social app, an iPad app, a desktop widget, enterprise applications or dashboard – everything can be designed on paper.

I was designing an astrology portal four years ago. The product manager did not have any clue of what design process I followed. I did exhaustive sessions with his development team to arrive at the information architecture. When the first sketches (paper prototypes) of the portal started to emerge, the manager got curious. Subsequent discussions on the paper prototype ensured that all the “requirements” had been addressed and we finalized the user journeys. Only after that visual design mockups were produced. The development team harnessed the utility of paper prototypes and saved a lot of development cost, in this process.

Known web entities too champion for the need of prototyping (some root for paper prototyping & some for iterative prototyping). 37signals recommends to prototype fast and often. I have worked as a consultant to eBay and eBay gives thumbs up for paper prototyping. So does AT&T.

Whenever in doubt, go back to paper. It will help you a lot. Just take out the paper and pencil, sketch it out. If you are convinced, you will convince others about the next ground breaking product. And paper prototype will help you to just do that.