Let’s say you are holding the nail in place with one hand and the other is gripping the hammer. You swing and ‘thud’ - there goes the first hammering. And again and again. After a couple of swings, you are not thinking about the hammer anymore. You are fully focussing on the nail. Your hand could feel the 'thud' of the hammer hitting the nail, the sound, the resistance and the impact of it all. All these 'physical' signals goes back to your arm as tactile feedback. You can instantly recognise a soft hit and a hard one without even looking at the nail directly. Your aim is coordinated not just by the eyes but also by the muscle memory in your hand.

You and the tool's purpose are all aligned up in a way it all feels so natural and fluid.At this point, the hammer almost feels like an extension of your hand.

And that is what 19th century philosopher Heidegger referred to as 'ready-to-hand'. Modern day cognitive psychologists call this the 'continuity of mind'. Media theorist Marshal Mcluhan repeatedly referred to this as how 'every media is an extension of man' .

Alright, its fascinating.. but how is it connected to UX and designing softwares?

The answer is in 'effective feedback loops' in our UI.

The little error messages, the progress bar indicators, the change of the normal cursor to hand cursor when you run your mouse over a clickable component, etc are all valuable feedback loops to the user. Everyone of them has scope for tremendous improvement in all softwares that we use everyday.

Here is an example of colour & motion used ‘meaningfully’ to communicate 'error' even without calling it out as an error.

The sideways nod of the text box is obviously inspired by our human head gesture for ‘No’.

It is such a natural gesture that you can pick it up even if you don’t know the other person’s language. Natural enough for my dog piku to understand that without any training :P. And more importantly it is a relatively lightweight implementation in html5 or react front-end frameworks most apps use today. So it is a win from an implementation point of view too.

Animation doesn’t matter, but contextual and faster feedback matters!

Whether you choose a head nod like motion design for your error message or a big bold error text has smaller impact in the scheme of larger things. But what really matters is dependable, contextual and more importantly faster feedback loops in your UI.

If the user entered something wrong in the middle of a long form, don’t show the error message at the top of the form. We can do better than that. Show it closer to the actual error. That is contextual feedback.

If your error message just says ‘something is wrong’, that is more of a criticism than feedback :). So make it specific and actionable - so that the user can depend on your feedback to fix the issue.

Lastly faster is better. Always. Leverage many of the asynchronous tech available today to display errors instantly when it happens. Don’t wait for the user to press the submit button (unless there is a good ux reason for that). Remember the thud of the hammer and the real time feedback of that. Today’s software can learn a thing or two from that when it comes to faster feedbacks.

For the agile software world…

In agile world, where the mantra is to release fast and fix later, some of these cognitive nuances in UI could get missed. So what do we do? should we abandon agile and jump into deep meaningful UX processes all the time?

Hmm.. that may be a bit idealistic too. Instead the trick lies in identifying the critical user journeys in your product and make them super effortless and frictionless to the user. Do all these for that particular user flow. See how feedback loops can be integrated at the component level in your design system itself. Work with your front end developer to bake that improvement as part of the component code itself (in many ways this is the foundation for creating a design system).

Share

Subscribe now

If you are interested to learn more about 'ready to hand' and 'tools as extensions of the self', check this article from MIT press.

• When Objects become extensions of you | MIT Press

Special thanks to my friend and fellow designer Dharmesh Ba for his inputs on what user flows might be of reader’s interest. Check out his youtube channel India notes.

UX review: Report feature

Today we are going to look at report journey in two popular help-desk softwares, namely Freshdesk from Freshworks and ZohoDesk from Zoho.

Both of these softwares are poster-children of Indian SaaS ecosystem which is gaining massive global acceptance. Both of them are help-desk platforms. If you are new to help-desk softwares, in simplified terms, it is a sophisticated email handling tool for customer support teams. Incoming customer enquiries are called tickets and they get assigned to one of the support staff to be resolved in a finite time period. With brands embracing social marketing and omni-channel commerce, help-desk tools are increasingly transforming into hybrid platforms that can handle social media comments, voice calls and also store customer information like CRMs. With this background, let’s jump right in.

Meet dashboards, the tip of the reports iceberg

Not just for help-desks but for almost all enterprise softwares, the landing page is typically a dashboard of some sort. Both freshdesk and zoho desk starts with a dashboard.

Freshdesk shows a demo dashboard with actual numbers that paints a picture of a typical work day, for the first time users.

So instead of seeing all zeros in the real charts when you start, you see an image of a fully populated dashboard with a message that clarifies that this is only a demo dashboard. This is a clever and thoughtful user experience feature.

Zoho desk on the other hand shows a standard dashboard filled with zeros. Nothing wrong with it, but i like the user thought behind freshdesk's version.

Don't make me think, at least when it comes to navigation

Steve Krug's 'Don't make the users think' resonates with me in most cases. But in real world complex SaaS softwares, applying that principle in isolation is very tricky.

So instead of making every page intuitively simple, the practical mid point is to make key aspects such as 'navigation' to be outrightly intuitive and simple. And to some extent both freshdesk and zoho desk fell short.

Some observations:

• In both softwares, you see collapsed side navigation as default view. This makes it difficult to glance at the menu items to get a sense of it.

• Zoho has custom acronyms in their navigation menu. What does HQ mean? I am used to seeing 'Home' or 'Overview' as the first item in the navigation bar. And the icon is not helping me either. Then comes KB. Some items are written in full form and some are abbreviated. I couldn't see any rationale in the first glance. Why make me guess when it should have been simple and straightforward in the first place?

• Freshdesk menu is also a collapses one without text explaining what each one is. One easier solution is to show them expanded by default and allow the user to collapse it if needed.

Maintain consistency in layout - basics of Usability 101

In Zoho desk, when i click on reports from the top navigation bar, it loads a new page in which the left navigation menu is not present. It loads a different navigation menu with different set of items.

Consistency in layouts helps the user establish a mental model of the software and how to navigate it.

It is same as how we humans make a mental model of a mall that you visit for the first time. For example…

• All escalators are placed one above the other.

• Shops are in different levels.

• There is signage to tell you which floor you are in now and how to reach other floors.

All this is valuable information to make a mental model of that physical space. Same is applicable for a software and even more so since it is limited by your computer screen and you can see only one screen at a time.

So UX principle here is to insist on consistency and have a rationale for that consistency. ( aka information architecture in UX parlance )

Enable quick choice making...

Once you land on the reports menu, you see a long list of text menu in Zoho desk. The visual design for some strange reason doesn't seem to be emphasising on the section headings of each groups. Instead the emphasis is on the table header (which is anyway same across all sections)

Whereas in Freshdesk,

• you see well spaced out icons separated into its own categories.

• It is far more readable, easy to scan and eventually develop a muscle memory for quickly picking a report item.

• Although i did not understand the reason behind color coding each section differently. Are these colors consistent across the software (if so, that will be great ) or is it just a styling element in this page ( then ... they can very well do with a single color icons )

Smart search in Freshdesk

The one feature that stood out for me was the smart search at the top of the page in freshdesk. When you have a long list of items ( more than 7 as per many UI studies) to choose from, give an option to search for the items quickly with a search bar.

Freshdesk has gone one step further here and made the search super smart and suggestive. It gives you meaningful suggestions on typical search cases that you will ask for. that is smart.

Once you are in the actual report page- what UX flows are important ?

Let's say you land on the particular report that you want to look into, what features should i build to make my UX better? I am going to consciously stay away from discussing the correct metrics and its visualisations. To meaningfully do that, i need more understanding of the user persona and the business use case. Instead we will look at key customer experiences that you can build here.

Reports are meant for SHARING !

Reports typically exist for someone to share it to someone in the organisation to make some analysis. Alright i have used lot of 'some's in that 😂

So make it super easy for someone to share a report. Best way is to send a quick link to that particular view and the recipient can click and see exactly what you are seeing. In some cases, the report will have data only for a limited period of time (like 7 days or 30 days based on pricing tier). So there you may need a permanent storage of that report view. So allow options to export the entire report as PDF.

Both zoho and freshdesk allows for that but freshdesk has a much easier one click PDF export, which is nice.

Provide proactive guides or help articles

Don't take your user to be dumb. At the same time, don't assume that they know everything. Reporting is a technical feature. And it is common that some of the graphs or metrics may be new or unclear to your users. So take that extra step and proactively tell them what each one of them is about.

Freshdesk has this nifty link on the top of the page which says "how to use this report"

This is brilliant UX approach particularly because of the 'conversational' tone of the words. It is not saying help doc -which sounds super serious and boring or blog- which sounds super casual or extra information. Instead this phrase captures the intent beautifully. I would love to see how many people landing on this page actually click on that link.

In zoho, such user centric features are terribly missing. And particularly when the list is so long in zoho, i would expect some kind of user guidance to help in the user experience.

Make it easy to compare and correlate

Use colors, spacing and arrangement to help in making comparisons easier for your user. In this case both zoho desk and freshdesk can improve a lot.

All elements of Gestalt principles when used mindfully, can greatly enhance how well your data can be presented in your software. More about various design principles that you can use in data rich software design in another post.

Do let me know what else you would like me to write about. Until then, singing off, the enterprise UX Guy :)

Share

Part 2: Story Mapping for feature prioritisation

What is it?

This is a fusion of agile stories and user journey mapping process from the UX world.

The key idea is to breakdown any product into critical user journeys that a user has to undergo and map them visually as a step by step process. Each of the steps gives you an idea of critical features and good to have features, that are necessary to achieve the end goal. Thanks to its simplicity, it is super effective to get alignment within product teams. Also it is super visual and highly suitable for a team sprint workshop.

Step by step method to implement this technique

1. Jobs to be done: List the key tasks or jobs that a user has to accomplish by using your software. For example, for a CRM tool,

   • Critical job 1 is to enable users to create leads and contacts.

   • Critical job 2 is to enable them to send emails or make phone calls to the leads created.

   • Critical job 3 is to track a lead's progress in the sales pipeline etc etc.

   

   In UX parlance, they call this as Jobs-to-be-done framework. Essentially it breaks a large software into simpler user jobs and user journeys to get them done. This is based on the belief that users are interested in getting a job done and not necessarily thinking of your software in terms of its individual features.

2. Pick one of the key jobs from the list above.

3. On a piece of paper or on a digital jam board, along the horizontal axis, write down the sequential steps that a user has to go through to get that particular job done.
   
   For the CRM example above, 'creating a new lead' is an important jobs to be done for the user. Now for this job, the hypothetical steps could be something like this…

   

   Now this is the basic flow. Reserve the details for the next step.

4. Now think of additional rich features that each of the above steps would have in a matured software. For instance, there could be option to add additional information to the form or instead of just saving , there could be an option to "save and add another"
   

   

   I am just guessing feature improvements here based on my limited experience of having used a CRM tool. I guess you get the point here. As a product member you might be able to come up with more items for each of the steps. Now keep adding them below the bare minimum step as shown above.

5. each of the swim-lanes added below the main sequence of actions are additional features needed to be prioritised.
   
   But the key advantage is that we have added a user-journey lens to all the individual features. Now the discussion within the product team is not about 'autosuggest feature in search bar' , it is about giving more ways for the user to discover the product that they were looking for in the first place.

The product discussion has moved to user journey based wording. And thats a win already in the right direction for your product.

Pros of Story mapping

1. Deeply centred around user's experiences. So every feature becomes a user story in itself.

2. MVP identification becomes super easy in this method. The top items on your user flows automatically becomes the release zero or MVP as you call it.

3. Suitable for products in all stages.

4. Also the story map developed becomes a visual asset for the product team to refer to at any stage.

Cons of story mapping

1. Business value, competitor features and complexity of the features listed are not taken into account at all.
   This is particularly important for products that are fundamentally complex to build. One good example is building a 3D video game. Even the basic user journey in such a project would take enormous engineering effort and complexity which is not factored in this method.

When to use it?

Use it when you want to quickly release a MVP or proof of concept for your idea. It helps you identify the core tasks very effectively.

Isn't this the responsibility of a PM? What does UX has to do with it?

In an ideal situation, the entire team including engineering, UX, marketing and support staff should be involved in this process with the PM leading and curating the inputs. But for all practical reasons, Product managers (PMs) end up doing this in most companies.

Designers can add unique value by bringing the most relevant user research inputs to assess what emotional impact a particular feature will have on the user. Users may not spell out the exact feature that they may die for but understanding their underlying motivations, fears, needs and desires will give you a fair idea to make a close guess of the potential impact. It is always iterative process but at least a UXer make the starting point so much closer to the sweet spot and also give a sense of direction to improve further.

Share

Subscribe now

Knowing WHAT to build is more difficult than HOW to build.

Every product feature is a commitment of time and money, thus an important decision for any product team. And in most companies this is the project manager's (PM's) responsibility. But how do PMs know what features are important for their product? This is where domain knowledge often helps. In established domains, PMs may have enough domain knowledge to make a prioritised feature list without breaking a sweat. But in emerging domains where either the product is new or the user segment is new, it becomes a real challenge. Most startups face this issue from day one. Googles and facebooks of the world face this challenge when they launch a new product or enter an unfamiliar market segment.

Thankfully, there are a bunch of product prioritisation frameworks that one could make use of. Frameworks are template-ised value systems which you can apply to your use case( with a bit of tweaking). Many of these frameworks are extensive analytical exercises. I am particularly interested in frameworks that are based on user understanding, user needs and desires.

So in this series we will deconstruct four UX based frameworks and how to practically apply them to your product/project.

1. Kano model (simplified version)

2. Story mapping

3. Buy a feature

4. R.I.C.E framework

Share

Part 1: Kano model (Simplified lite version)

The key idea of kano model is to rate features based on their "expected impact on customer satisfaction". It defines customer satisfaction on a linear scale with these different emotional states…

In simple terms, terms, it is super bad, bad, Ah..its ok, good and amazing. Similarly it breaks down product features into 5 categories from worst to best as follows…

So for each of the features, we have two choices, whether to include it in our product or not. If included, what is the emotional response we expect from the customer? and if not included what is the emotional state we expect from the customer? Let us look at all possible options here.

Simple steps to apply kano for your project

1. Make a list of all features that you would like to build for your product.

2. For each of them, ask yourself how your user would feel if that particular feature is present and works very well. Pick one of the emotional states described above.

3. Similarly, if that particular feature is absent, how would your user react? Pick an emotional state.

4. Based on the emotional states picked for feature being present or absent, your feature list will fall under one of the following "value" categories.

Basic features

Basic features are bare minimum things that users anyway expect from your product.

If present, they are not going to fall in love with your product, but if absent, definitely they are going to get frustrated. Consider this as basic hygiene check and include all features from this category.

Satisfiers

These are the core set of features that forms a bulk of your product offering. They are the prime reasons why your customer is paying for your software or coming to your website. There is a direct correlation to customer happiness here.

If present they are satisfied. If absent, they are dissatisfied. So try to include as much as practically possible from this list.

Delighters

These are super amazing features that either the customer is not actively expecting from your offering. They may be a novel way of doing something that they are not aware of and hence not consciously expecting.

But if you do give them these features, it may delight them. If you don't give them these features, since they are not actively expecting them, they may not be disappointed by it and the reaction would be neutral. Include a few of them in your product. They are your differentiators.

Negative is self explanatory.

These are the features that will annoy the users. So don't even think of investing time in them. One classic example of this (if you are from 90s) is the Clippy from MS Office products that we all instantly close.

It is a smart assistant tool that answers anything you ask and was very difficult to turn it off. It may sound like a precursor to today's siri or google assist, but may be the execution or the tacky animation of this clippy made it so annoying that most folks close it within few seconds of it popping.

Pros of Kano model

• Encourages the product team to think "consciously" of the user and their needs. It is a good exercise in creating user empathy within the team. Shifts the focus from 'what i can do' to 'what users will like'.

• Works well for products of all stages and lifecycle. Works equally well for new launches and existing product improvements.

Cons of Kano model

• Does not take into account engineering effort and time value. It is largely about what is best for the user.

Isn't this the responsibility of a PM? What does UX has to do with it?

In an ideal situation, the entire team including engineering, UX, marketing and support staff should be involved in this process with the PM leading and curating the inputs. But for all practical reasons, Product managers (PMs) end up doing this in most companies.

Designers can add unique value by bringing the most relevant user research inputs to assess what emotional impact a particular feature will have on the user. Users may not spell out the exact feature that they may die for but understanding their underlying motivations, fears, needs and desires will give you a fair idea to make a close guess of the potential impact. It is always iterative process but at least a UXer make the starting point so much closer to the sweet spot and also give a sense of direction to improve further.

Coming next…

Stay tuned for part 2 on Story mapping technique and how it can help you prioritise your product features.

Share

Leave a comment

Off late I am noticing that when recruiters call to pitch their design openings, they unwittingly toss the word "design system" as one of the job responsibilities. Some even say that we expect you to come on board and create a design system for our startup. While it all feels like music to designers' ears, the real question is "Do you really need a design system on Day 1 for your startup?"

The answer would be yes if you think a design system is a bunch of standardised buttons and UI elements for your product. Such a standardised UI library would make UI development faster for sure. But technically that is a style guide or UI library. It is not a design system yet.

Design systems are created in the first place to scale design-development cycles across the many teams in the company. And for that, you need a supporting frontend UI codebase for the UI library that your designers have developed. So that any frontend engineer can just use the codebase and its configurations right away in his/her project.

Design systems that are not available as coded components is equivalent to driving a Lamborghini on a traffic filled city road. It is not totally worthless but definitely doesn’t serve the purpose of the vehicle.

So for all practical reasons, follow this simple evaluation

1. If you are just starting out with a formal design team for your company, start with the idea of a unified Style guide with re-usable UI components. Create variations for the use cases that you currently know. For sure this will change as your product matures. But at least your team will not use 10 different buttons in 10 different product pages.
   

2. As your product matures and you see yourself creating similar layouts or flows again and again, persuade the leadership to invest in dedicated frontend engineers to convert all your Figma/XD components into readily usable Frontend code. Make this as configurable as possible, so that tomorrow if your brand color scheme changes, the assets can be modified in the actual code without major breaks. Modularising a workflow into components is not a trivial task and more than talent or experience, this needs a small dedicated team of UI designers and a frontend developer.
   

3. And assuming the company matures into a large organisation with multiple design teams, then think of creating design principles rather than UI components. Because after a point of time, you may not be able to predict all the use cases that your product will require. You have to let the teams decide on that themselves but with guiding UX principles. This step is applicable for large legacy companies modernising their design operations too.
   

This is a super simplified checklist to know when to create a design system for your company.

Let me know some of the best and worst design systems that you have come across in your experience and help me understand why you feel that way. We will talk more about UX in enterprises in the future posts

• To get your rightful seat at the product strategy, UX designers have to add value to various product development stakeholders. Coding knowledge is not must. But good to have. Applies to everything else that goes into shipping a product.

• Individual buy-ins are more successful and practical than grand swooping presentations to the entire team or company.

• UI is worth 1000 words. But a prototype is worth 1000 UIs. So always show the user journey, user pain point and the overall experience over static screens.
  

Full story

User experience design is gaining its rightful place in many product companies today. Thanks to the success stories of design led companies such as AirBnB which uses thoughtful user experiences as a business differentiator. In Indian contexts, we have examples such as Cleartrip, that uses clutter free design as a differentiator in a tooth & nail market. Dunzo is another example in last mile delivery space and both big and small companies are catching up with this trend.

While this is already happening and set to grow, in reality many designers and design teams are still struggling to get the design inputs respected within their organisations. Let alone long term product strategy, the challenge lies even in getting alignment within their own product direction for many reasons. While the individual situations may be different, here are some broad principles or practical tips to get the elusive seat at product strategy table in your company.

#1 Make yourself valuable at every stage of the product development

As UX designers we know that UX practice can add value to every stage of the product development. And designers often crib when their work teams bucket them into UI buckets and approach them only when there is a clear cut UI requirement.

But at the same time, I often see designers limiting their own impact space. Designers are not expected to write python code for an actual production release. But knowing what REST APIs are and how a basic python code is written will give you the necessary foothold to make sense in cross functional meetings. Same applies to business side of things and project management. Design thinking at the core is about structured common sense. And in real world complex use cases, getting that structured common sense is very rare and valuable to the product.

So designers out there, add more tools to your design tool kit. Learn basic programming. Get a “hello world” app published in app store and you may appreciate the developer pain points far more than before. And this empathy will soon translate to frameworks and mental models which a designer is fluent with and can add value to the overall product development. Play to your strengths but also expand your bases (constantly).

#2 Individual buy-ins more effective than grand swooping presentations:

Many of us in design are knowingly or unknowingly influenced by the grandeur of Steve jobs’s type product launches. It is the perfect mix of story telling, user connect, and technology explained in such simple terms.

Undoubtedly amazing!

But we overlook the obvious that Jobs was a celebrated maverick in Silicon valley, well before iPhone or iPod or any of those grand launches. Moreover he is talking to an audience who already revers him as a visionary. That context is very different from you and I, when we present an idea to our cross functional partners, inspite of how good a designer we believe ourselves to be. In reality it is very much like this Dilbert comic strip.

For many of us in UX practice, the secret lies in getting small wins.

Small wins such as getting your frontend engineer sensitised enough to make sure that a popup window does-not look borrowed from a different app just for code-reuse.

Break down your grand re-design into smaller chunks. Pitch them to your engineering and PM peers as ‘workgroup sessions’ where they give feedback. Everyone will have their own perspective. But as designers you can abstract that and see where what benefits the user. Center your conversation around the user. Win one person or one functional team (backend engineering, frontend, PMs, Product owners etc ) at a time. And then bring the grand presentation to a joint meeting. Or even better co-present it with someone who has earned some reputation already. At this stage it no more your grand idea. It is something that each of the functional teams feel interested for various small parts. And that my friend is your ticket to get your product idea shipped in a large enterprise company.

#3 UI is worth 1000 words. A prototype is worth 1000 UI mocks.

Show a user-flow and not just a static screen. We talk so much about experience but sometimes fatally forget how much of it applies to presenting our own work. UI mocks are good. Definitely better than a PRD written as a word document. But a prototype is even better. Show the user flow. Show the journey of a user with your product and in the absence of your product. Elaborate the pain experientially. In enterprise products, it is common for a user to have discrete user flows where he uses a dozen tools from different vendors to get one major task done. Show this pain visually. And then propose your solution and see how fast it flies.

Something to note here is not to get lost in details. You don’t have to make a persuasive disney-type movie to explain that a software sucks. Keep it minimal to avoid feedbacks on things that are not the core idea.

These are some of the practical ways in which UX practitioners can get their rightful seat at the product strategy table.

Readers, let me know what other topics in the wide universe of enterprise UX and UX design that you are particularly interested in. Thank you.

While that definition is not entirely false, it is severely limiting the scope of enterprise software in this day and age.

In the prophetic words of Marc Andreessen from Andreessen and Horowitz,

'Software is eating the world'

Almost every inconceivable industry or physical business is being migrated to software & internet if not being transformed. He wrote this in 2011. And in the last decade this has only increased even further. And today we have enterprise grade software that runs on a 50$ android phone app. No longer enterprise softwares are about basic business processes. While Microsoft office and Salesforce continue to exist, there are hundreds of new age enterprise products such as Canva, Jira, Slack, Shopify, Figma, Postman to name a few, each boasting millions of enterprise users. All of these software look and operate fundamentally different from the legacy SAP softwares that we have known as enterprise softwares in the past.

Here is a super reduced version of modern day enterprise software products. Some of them cater to both individuals and enterprises but the large business model is around enterprise use cases. Remember this barely covers 10% of the enterprise software universe.

So what does all this mean to Enterprise UX design? Almost everything.

The fundamental shift is from simple productivity to deeper user delight.

By user delight. I am not referring to a cute little animation for the loading screen or a mesmerising illustration for a cloud SaaS software. I am referring to empowering users to such an extent that the software is a delight to get things done better than he/she ever imagined.

It refers to the software being humane. Software that does not make you feel stupid. Software that does not play 'knock knock guess who' in its user flows. In a nutshell, a software that is mature enough to focus on the user and let everything fade in the background.

How does it affect me as a UX practitioner?

This natural maturity in the evolution of software puts UXers on the most advantageous position to influence the entire product and roadmap in any organisation. Knowingly or unknowingly the core of all UX processes are built on understanding users and their needs, which is the most difficult and ephemeral part in today's agile software development. The existing arsenal of User research can be far more effective in an enterprise context when you clearly know who are the real users of your product . UX benchmarking may not only provide the much needed ROI calculation, it could potentially identify an underserved niche for the software to expand. The ability of a designer to give the first shape and form for a product could really help a product manager in shaping the product vision so early in the product cycle.

All this and more are yet to be fully explored in enterprise space and the space is only growing further. In this blog, we will cover practical, no-jargon analysis of UX and its inevitable role in enterprise UX. Let me know your thoughts on what you think about enterprise UX and what topics within enterprise UX would you like me to write more about.

Cheers, have a good day.