Tag Archives: visualization

Standard

Posted by

Posted on

May 1, 2013

Posted under

Ecosystem

Comments

3 Comments

Step 1) Understand the ecosystem – PART 2

“A wise car hears one word and understands two” is a line quoted by one of the characters in Cars 2 movie.

A designer precisely does that 🙂 and comes up with his/her ‘mental model’ of the ecosystem using a visualization technique.

Mind map is a visualization technique that was introduced by Tony Buzan (http://www.tonybuzan.com/). Google “mindmap” and you will get loads of links that explain how to create a mind map. A very detailed explanation of this can be found on Wikipedia: https://en.wikipedia.org/wiki/Mind_map

Mind you, mind map is just one of the techniques of visualization. There are entity-relationship diagrams, time-series data, statistical distributions, maps, hierarchy diagrams, etc. You can use any or combinations of these techniques to create your view of the ecosystem. As discussed in the last post, I am comfortable with mind maps. Sometimes, I create infographics to depict my understanding of the ecosystem.

An advanced mind can refer to Edward Tufte’s books (www.edwardtufte.com) for deeper understanding of visualization methods.

To express the ecosystem in a graphical form, one need not be a great artist. Content is an important as the treatment. The ecosystem infographic is generally designed over a period of time – fine tuned every day as you (designer) get deeper insights on what is happening, who is influencing what, etc.

Engage with stakeholders, development teams, book their calendars. Set up some lock-down sessions with them :). Encourage them to express their wishful thinking using whiteboards. White-boarding activity is a sort-of ice-breaking ceremony between designers and stakeholders, which define the course of product/service design. Sessions like white-boarding activities need to be orchestrated professionally. Stakeholders are short on time and attention – pick their brains that will help you understand what and how they envision the product.

Some examples of the white boarding activities that I participated are shown below:

Whiteboard Sample 1
Whiteboard_1_NEW

Whiteboard Sample 2
Whiteboard_3_NEW

Whiteboard Sample 3
Whiteboard_4_NEW

Whiteboard Sample 4
Whiteboard_5_NEW

In your ‘lock-down’ sessions and white boarding activities perhaps, you may discover key information that is not documented anywhere. Record like a dicta-phone and act like a Sherlock :).

Last year I participated in one of the stakeholder workshops to understand the business requirements. The business goal was to transform the legacy desktop application (serving 13 US geographical states’ telecom professionals) into a portal based solution.

I quickly sketched the following (an infographic) that captured the essence of that meeting:
Migration_NEW

On the left is depiction of PMO (present mode of operation) = old vendor’s engagement model with cost.

On the right is FMO (future mode of operation) = my development team’s engagement model with cost.

The picture was clear to me – My development team had to deliver a tough assignment at a very low cost in a less timeframe. We were at loss. As indicated by the management, we delivered in spite of all the constraints.

While I was on a teleconference call with one of the stakeholders for another project, I quickly drew the following, took a picture of it and shared with him in the call:
eM_NEW
The overall goal of the system design was captured correctly. In the call, we nailed down the granularities of processes represented by numbers.

Lets go back to our earlier thread – the mind map.

Mind-map is your view, how you see things and their relationships with other elements. It’s your ‘mental model’. A mind map starts with a goal (e.g. “reduce the no. of help-desk calls for the company”). This goal could be further broken down into sub-goals and sub-sub goals. Imagine a tree structure with the centralized goal radiating out branches (that represents sub-goals) that reach wide. Every sub-goal paves way for a sub-sub goal and so on. I think Buzan explains this better than me :). Copy-pasting the following 10 steps from Wikipedia, hope this helps.

Buzan suggests the following guidelines for creating mind maps:

  1. Start in the center with an image of the topic, using at least 3 colors.
  2. Use images, symbols, codes, and dimensions throughout your mind map.
  3. Select key words and print using upper or lower case letters.
  4. Each word/image is best alone and sitting on its own line.
  5. The lines should be connected, starting from the central image. The central lines are thicker, organic and thinner as they radiate out from the centre.
  6. Make the lines the same length as the word/image they support.
  7. Use multiple colors throughout the mind map, for visual stimulation and also to encode or group.
  8. Develop your own personal style of mind mapping.
  9. Use emphasis and show associations in your mind map.
  10. Keep the mind map clear by using radial hierarchy, numerical order or outlines to embrace your branches.

This list is itself more concise than a prose version of the same information and the mind map of these guidelines is itself intended to be more memorable and quicker to scan than either the prose or the list.

Too much of information overload? Don’t worry, have a look at the following mind-map I created for a financial software company:
InnovationCulture_2_NEW

Here are some additional mind maps I created for various enterprise portal dashboard assignments:
MigrationPortal_MMAP_NEW

EnterpriseApp_NEW

Practice the mind mapping technique or any other visualization technique that you are comfortable with. Do it on paper first. Spend some time with your visualization, talk to people, refine your visualization based on insights gathered. There is a digital tool too to create mind maps, Mindjet Mindmanager (http://www.mindjet.com).

That brings me my tools for paper prototyping. Here are they:

  1. An A5 size notebook (plain paper). I use notebooks by Nightingale (http://www.nightingale.co.in/Social_Stationery/Hand_Book.htm) – good paper & packaging quality).
  2. Stock of A4 papers
  3. 0.7mm mechanical pencil (I am currently using Camlin Klick Pro pencil – http://www.ithinkstore.com/camlin-klick-pro-0-7mm-mechenical-pencil-pack-of-10-pencils.html) Why 0.7mm? Because you can get thicker lines on paper prototypes :).
  4. Color pencils (any make, no preference).
  5. Eraser (Staedler – http://www.staedtler.com/en/products/pencils-accessories/erasers/tradition-526-t-eraser/#id=250&tx_solr[page]=1)
  6. Post-it notes (3M, of course)

This 1st step (understanding the ecosystem) is a crucial one. This is the foundation of your building. Plan it well.

Get the picture?

Standard

Posted by

Posted on

April 29, 2013

Posted under

Ecosystem

Comments

3 Comments

Step 1) Understand the ecosystem – PART 1

Regardless of the steps involved in creating the paper prototypes, an important point to understand is that one has to think visually. We are taught to think in a structured way, question and get answers in a logical way, conditioned to rationalize everything. That’s good. But you have to use imagination too – things that may defy the conventions and make you connect the dots. It’s okay if there are some things that remain unexplained, things that you cannot make connections with. Like all mysterious things, let the discovery awe you in the design process, while designing the product / service. You are not going to get all the answers at one go.

Whenever in doubt, bank upon your imagination and visualize those aspects that make things ‘believable’. When you understand the ecosystem, knowledge is as important as imagination.

Ecosystem could be a vast sea and probably you might be designing a very small yet significant part of it. E.g. In a financial institution like Citibank or HSBC, your design goal could be to optimize the online self-help documentation that will minimize the helpdesk telephone calls (eventually reducing the cost to the company). If you are new to finance domain, you are lucky. You could be in a position to imbibe the best knowledge of the finance world and design solution accordingly.

User experience designers often say that they design technology-agnostic and domain-agnostic solutions, i.e. whether is a life science project or a telecom project or any educational project, their design process & deliverables will remain the same. Regardless of the organization & the market segment, they work ‘horizontally’. However, there is no harm in being a little vertical about the domain. Having deeper insights about technology, undefined rules, sensing the interplay between different stakeholders will always help you.  We call this horizontal and vertical approach as the “T” approach – the alphabet signifying the horizontal direction designer undertakes project-wise (across all departments of the organization) and the vertical direction signifies the direction designer seeks domain-wise (deep probing a specific area). Team up with a systems engineer, a marketing expert, or corporate communications or public relations manager and get those great insights.

This T-approach will help you understand the ecosystem. Understanding is not just asking questions to stakeholders and users. Nor it is just about doing contextual inquiries of the users. It is also about sensing things. It is not reading and deducing the written material. It is also about ‘reading between the lines’. A designer already has the gift to imbibe things, a keen eye and attentive ear, an imaginative mind and visual thinking. To understand the ecosystem is to commission all the senses and orchestrate the data, information and the insights that one gathers from all the customer touch-points.

Remember Sherlock Holmes? Have you read ‘Tinker Tailor Soldier Spy’? Have you seen the Jason Bourne trilogy of movies? Its all the detective and spy stuff, which might excite one – all the protagonists of these fictions think and act differently. Their ‘view’ of the problem at hand and the ecosystem is what makes them successful.

So what is actually an ecosystem? It is the designer’s view of how he/she looks at the things that influence the design. This will tell the designer how certain things work. Who makes them work? What happens if a certain parameter is missed out? What will happen if the output is overshot? Will users abandon the ship if a certain task is vaguely defined?

There are many questions that one comes across in designer’s mind. As discussed earlier, there might be answers to few. For unanswered questions, it’s good to use your imagination. Some questions might be answered during the later stages of design (prototype iterations or user testing).

As a designer, you either facilitate or make a disruptive change to the system with your designs. Most designers take the pleasure in breaking the system by being in the system. That’s what ‘T-approach’ is all about.

In the next post, let’s look at some examples of mind-maps that define the ecosystem.

Standard

Posted by

Posted on

April 19, 2013

Posted under

Uncategorized

Comments

Leave a comment

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.