[Workshop Deck] PART-1: Applying DesOps in Your Enterprise

[This is the first part of the half-day workshop titled “Applying DesOps in Your Enterprise” I conducted at the “UX India Conference 2018” on 4th October, 2018, Bengaluru. This part focused on ‘Process’ aspect of DesOps, and tried to address the challenges of bringing the designers to the same page to that of diversified subject-matter experts (SMEs) during the ideation phase of an Design Thinking workshop, by collaborating on “Petal Process Diagram”(PPD) . PPD is a mind-mapping kind of activity with the focus to involve all the entities involved in and around a touch-point in a feedback-loop, and helps everyone in the room to be on the same page on the potential possibilities, feasibilities involving “props” and “process” components.

You can explore more at http://desops.io/2018/10/03/workshop-at-ux-india-international-conference-2018-applying-desops-in-your-enterprise/ ]

Continue to the next part of the workshop, in the next post.

Meanwhile, you can explore more here:

https://youtu.be/J5Igx25pj5A

(c) Samir Dash, 2018. All rights reserved. This content including the images are licensed under a Creative Commons Attribution 4.0 International license

 

 

Workshop at UX India International Conference 2018 : Applying DesOps in Your Enterprise

 

Applying DesOps in Your Enterprise

3 hrs Workshop | Category: Design Practice & Process | Target Audience: Anyone who is interested in optimizing the processes used in the enterprise or building solutions that focuses on process re-engineering is the most suitable audience for the first part of the workshop.   Any User-Experience pro,  Design Thinker, Service designer, and product-management professional can be benefitted. The second part of the workshop is helpful for the designers and UI developers who use the design system or would like to build a scalable design system for their organization or team. Basic understanding of HTML and CSS is good enough for the 2nd part of the workshop.

 

The workshop will focus on two aspects of DesOps, namely the process and eco-system. The process aspect will be identifying touch points in the enterprise, and try to optimize that with some solution using technology. The ‘eco-system’ part of the workshop will focus on building a sample design system using Nuclear Design Model to make it scalable and extensible.

Three key takeaways:

  1. Basics of DesOps from process and eco-System Angle.
  2. Learn about how to identify touch-points in the process /workflow that can be optimized to bring automation or technological solutions.
  3. Learn about the basics of Nuclear Design Model and applying to build open, scalable and extensible design systems.

Date & Time: 10:AM – 1 PM  on 4 October 2018
Venue:  4, 5 & 6 October 2018, ITC Gardenia, Bangalore

 

Event: UX India International Conference, 2018, A day full of inspiration and learning for user experience designers, UX leaders, visual designers, user researchers, front-end developers, program managers, startup founders and design students. Grab an opportunity to grow and network with UX Design industry experts. It brings engaging industry leaders to present a combination of inspirational talks and personal experiences.

More: https://www.facebook.com/UXindiaBangalore/

UPDATE

Slides :

https://www.slideshare.net/MobileWish/applying-des-ops-in-your-enterprise-04-oct-2018-v10-slides

Sample code of the CDN based Design Eco-System POC using CSS Variables:

https://github.com/OpenDesignSystem/ODS-CDN 

 

Two Parts Articles:

[Workshop Deck] PART-1: Applying DesOps in Your Enterprise
https://www.linkedin.com/pulse/workshop-deckapplying-desops-your-enterprise-samir-dash/?published=t
[Workshop Deck] PART-1: Applying DesOps in Your Enterprise
https://www.linkedin.com/pulse/workshop-deck-part-2-applying-desops-your-enterprise-samir-dash/

 

PHOTOS:

 

 

Infographic: The 3 Dimensions & 3 Characteristics (3Cs) of DesOps

©2018,”The 3 Dimensions & 3 Characteristics (3Cs) of DesOps” by Samir Dash.
Creative Commons Attribution-Share Alike 4.0 International License
Read about 3 Dimensions

Team’s Vicious Circle and Avoiding the Organization Turning into a Pack of Zombies

On the theoretical level, the interaction can be modelled based on various entities like tasks(i.e. activities users perform to reach their goals), dialogues (i.e. interaction between user with users and machines and vice versa ), rules or instructions (i.e collection of behavioural instructions ) and states (i.e. conditions present in the system ) etc. Broadly, the interactions in the team/organization involving communications and sharing among members or more specifically among the roles, though is part of the Process dimension, constitutes the components that are part of the core of Cultural dimension of DesOps.

Basically, this is all about getting answers to two questions that a typical Product Manager or a CEO of the startup has in mind :

  • Do I have the right team?
  • How do my team can be effective in communicating and collaborating at different spheres with different types of entities involved?

In the previous article, I was primarily referring to two levels of the interaction were human-to-machine and machine-to-human and how minimization of the touch-points where the translation of value happens. This is primarily about “consciously and proactively considering the exchanges between people and organizations in the enterprise, and supporting these interactions with automation and tools” (Guenther, Millan Intersection, 2013 ). Solving the challenge to minimize such touch-points are relatively easy, as it involves some aspect of technology and toolchains associated. However, the level which is about human-to-human interaction is the most complex to deal with as it does not have any technology involved in it. In the last article, we slightly touched upon the full-stack roles, that handled some aspects of it. This aspect is more about involving knowledge, skill and expertise attributes of humans involved, and some aspect of it is also involved with human-to-machine & machine-to-human levels, which are partially solved by the redesigning the process involving the technologies. However, the human-to-human interaction is more complex, because it involves the attributes of human emotions, attributes and bias and cognitive fixedness that are counter-productive for any organization heading for disruptive innovation.

Broadly these attributes are part of forming a right set of team, with the right mindset. This is broadly about what kind of team members you should be looking for and also about to implement a set of practices and rules which would help grow each team members towards the self-awareness about there cultural fitment as well as motivate and guide them to grow themselves to overcome their fixed mindsets if any.

Fixed mindsets are the roadblocks to innovation in any organization. The fixedness is part of the human attribute that acts as the vitamin for a pre-defined process oriented no-brainer’s job to bring effectiveness, but at the same time acts as cancer for innovation. Typically, the key types of fixedness that hinder having effective human-to-human interactions in DesOps organization are as follows:

Cognitive Bias: The Cognitive Bias is typically defined as a mistake in reasoning, evaluating, remembering, or another cognitive process, often occurring as a result of holding onto one’s preferences and beliefs regardless of contrary information. The cognitive bias is a kind of fixed mindset that sometimes also manifest itself as a tendency for people to evaluate ambiguous information in a way beneficial to their interests apart from the aspect (popularly known as Confirmation Bias) that induces the tendency to search for or interpret information in a way that confirms his/her preconceptions. This leads to the premature closing down of options in a creative process, as the person affected by this only seeks out the evidence from the information he has that was pertinent to his argument, and remains blind eye purposefully to any other information.

HiPPO effect or Authority Bias: HiPPO (highest paid person’s opinion) is one of the popular terms in the organization-productivity domain. Basically, this is more about having authority biases and the team’s tendency to attribute greater accuracy to someone how holds a higher position in the organization. Beware of the HiPPO (highest paid person’s opinion) in the room as it means that the team has fallen foul of the law of the HiPPO — When a HiPPO is in play, the organization is most likely not relying on data to inform decision-making, rather the HiPPO (highest paid person’s opinion) tends to win out. In large corporate environments, it’s easy to experience it first hand. Usually, when a group of people are trying to make a difficult decision, for which there are lots of opinions, the person in the room who is further up the hierarchy (and therefore typically paid more) expresses what they think and tries to hijack the spirited discussions to steer towards forming an opinion among the team to follow what he thinks and labels it as the team’s decision.

HiPPO effect is the biggest roadblock in interaction aspect of DesOps. If you remember in previous articles of this series I had mentioned how one of the key philosophies of DesOps is to advocate and put a data-driven decision making into practice. HiPPO Effect actually is cancerous to DesOps culture. All the efforts to implement the right process and toolchains as a part of having an effective DesOps in the organization can fail, even only this cancer is still there as a part of the work culture.

Authority Bias is in similar lines with the HiPPO effect, but this may not necessarily about the person who is higher in the organizational hierarchy or paid more, rather it is about the person, who is “seen as experts” or even as an authority in the organization or even in the team. We have an inbuilt tendency to believe those who we perceive as “experts” and usually have a deep-seated duty to authority, and tend to comply when requested by an authority figure.

For example, in typical design or UX team meetings, it is the most difficult situations for young members who are just fresh out of colleges and had to present certain aspects of their solution that are in opposite directions to what the leader of the design team thinks or beliefs. In many cases, these ideas are brushed aside by the authoritarian leader or manager sighting even some frivolous reasons e.g. “it has to improve”, “immature and not practical”, “you need to understand our design process first”, “can’t use that to discuss with stakeholders as it is half-baked design” and so on. And in such cases, most of the “faithful” designers to the leader, echo the leader’s decision and even some start advocacy to explain the logical reasons behind the leader’s reasons. Some may be “yes-men” to the leader consciously, however, some do so as they perceive the leader as the “authority” or “expert” and this allows the authority bias to be successful in killing new ideas and fresh thinkings. In many cases, the member does not realize that they have already fallen prey to such bias.

One of the most famous psychology experiments of all time, known as the Milgram experiment, provides a terrifying example of that a very high proportion of people would fully obey the instructions. Read about this 1961 experiment here: https://en.wikipedia.org/wiki/Milgram_experiment ) and here is a video of that experiment:

 

The Bandwagon Effect is typically a psychological phenomenon in which people do something primarily because other people are doing it, regardless of their own beliefs, which they may ignore or override.

The Herd Mentality The Heard mentality and mob mentality, also lesser known as gang mentality, describes how people can be influenced by their peers to adopt certain behaviours on a largely emotional, rather than rational, basis. Basically, when the Bandwagon effect is blended with the catalysts of emotions, it takes shape of the herd mentality. This is the most negative extreme of the Bandwagon effect.

Also, the Cognitive Bias is more induced by the Herd Mentality as the persons involved turn blind eye to the factual information which can be used for making data-driven decisions. Rather, the persons depend on the emotional ripples for taking decisions and develops a strong Cognitive Bias, thereby contributing to form the Vicious Circle in the team.

(Download the PDF of above at http://desops.io/2018/05/13/infographic-the-vicious-circle-in-teams/ )

The Vicious Circle, refer to complex chains of events that reinforce themselves through a feedback loop, and it is interesting as feedback loop acts as the essential spine for any DesOps organization. The fixedness attributes in persons involved in the team essentially turn the feedback loop into the Vicious Circle that gradually cuts-off the supply of oxygen to the innovation in the organization.

In many cases, HiPPO effect or Authority Bias makes the team meetings ineffective and counter-productive. The members either fall prey to these bias, or they try to avoid conflict in the team and keep themselves safe in the organization by remaining silent (mostly by seeing the large mob of the zombies of these bias in the team. In such situation when some spirited members typically lower in the organizational ladder counter the argument of the upper ladder persons or the leader, the conflict arises, which is in most of the case becomes counter-productive for the team and the organization and becomes suicidal for the those at the lower ladders. Else, the typically the long silence follows in the team meetings when the leader explains his/her idea or viewpoint to a problem (in a tone of judgment in many cases). In both the cases, when it becomes a regular trend that when a leader of the team’s or the ideas or viewpoints from the those who are placed on the upper ladder are praised or unanimously advocated without a few valid questions and some set of team members regularly remain silence, this is a very symptom of the cancer. In another scenario, if the young minds in the team who used to have questions earlier when they had newly joined the team, have no more show any interest in questioning or ask the obvious questions where most probably they do not really need an answer or seems to know the outcome of the questions they asked, that is another alarm for the cancer.

If the team does not have a diverse-voice or the team members mostly ask questions which do not really going to impact those who asked those, and fall in the graph in questioning opinion of the leader in a productive way or some members in the team remaining silent who used to be more creative in the past (and for a long time their opinions were brushed aside and never mattered ) then the team or the organization has already become a totalitarian state and is in a serious condition that requires the fix of the culture.

This is important to remember here, that the foundation of DesOps is based on interaction and collaboration that is productive and supports innovation from grass-roots. In the trueDesOps organization, the ideas flow from bottom to top, like the seed of ideas germinate and grow as plant and gradually through continuous nourishment from the surrounding culture which turns it into a big tree with the fruits of innovation. All the process improvements, toolchain support and the technologies act as the catalyst to support such a culture. Going DesOps is about adapting to change, being flexible, adopt disruptive innovation in a measurable and informed approach. For such eco-system to be successful, it is essential to ensure the work-culture is supportive and provides motivation to the actual people who are part of it.

So where is the way out? One of the fundamental tasks of DesOps, as a Service Designapproach, is to prepare the work culture of the product team for more positive interaction in context to hum-to-human communication and collaboration so as to prepare them for the process changes that might follow up along with the aid of automation and new technologies supporting radically new toolchains. And in such cases, to avoid the team falls prey to fixed mindsets, mostly three steps can be taken:

  1. Choosing the right people with more open personal traits at the time of hiring. During the hiring process, there are many popular psychological tools and methodologies can be employed to avoid personal traits with higher index in the person, which is less willingness to take the risk, or avoid the person too much structured-perosn who is more prone towards process-oriented obedience. The new age innovation in organizations needs the product team with the people with more open and inquisitive mindset — those who have lot of questions in them with passion than the structured minds who always define the box as the red line for him as well as his team members, to play within.
  2. Always keep an eye on symptoms of Vicious circle getting formed within the team or organization. Mostly it starts with the persons who are at the top of the ladders. And the most commonly it starts with HiPPO effect. Evaluate internally if there is any change in the behaviour of the team during meetings — try to find answers to question like “Has the spirit of some members have changed?”, “Is there fewer questions in meetings and especially fewer questions to the people at a higher hierarchy? “, “Has the agreements to the top leaders’ views have increased without much discussions over last few meetings?” “Has some set of members are regularly putting up silence since a period whenever the leader of the team or people on the higher ladder is throwing the ideas?” “Has there been an increase in rejection of ideas from the grassroots ?” — These will help in forming the timely suspicion to avoid the Vicious Circle. Note, that these may seem like addon work, but this timely diagnosis is worth it, as it helps to ensure that the organization is not got cancer at its’s brain and heart.
  3. Another key aspect is to bust fixed mindset is to enable un-learning. The systematic un-learning is a key to fixedness that is more functional or structural in nature. Unlearning helps in fostering a sense of willingness that helps in opening up minds. Especially this is effective as well as critical to have the managers and the members of the top hierarchy, to develop a sense of willingness to unlearn and learn something new. Unlearning helps to put team members out of their comfort zones so that they are more willing to pursue the unfamiliar and fosters curiosity.

We will be exploring these in details in forthcoming articles of the series. Be in touch, and do not forget to share this post.

(c) 2018, Samir Dash. All rights reserved.

[Originally published on May 14, 2018 at https://www.linkedin.com/pulse/desops-next-wave-design-part-12-teams-vicious-circle-avoiding-dash/]

 

Translating Value at Different Stages of Design with Minimal Waste

In 1967 Ronald Barthe published Elements of Semiology, which stands as a temporal marker of post-structuralism, where he gave rise to the idea of “Meta Language”, which in fact “beyond language” or “Second-order language” which is used to describe, explain or interpret a “First order language”. Each order of language implicitly relies on a metalanguage by which it is explained. And it is obvious that the translations between the first order and the second order never loss-less and the true meaning of the first order language is lost or deteriorates when it is represented in “Second-order language”. Design process involving multiple intersections of information communication and sharing through translation of the value (e.g. vision, idea), loses its original meaning while being translated through different tools into various forms of expressions. Also, the different roles (e.g. Product stakeholder or product manager, information architect, interaction designer, visual designer, prototyper and developer etc. ) contribute to the infinite regression of “meaning” of the value.

That’s why one of the key factors that working with developers in terms of the realization of the design has always been a big pain and non-stop iterations, and this turning in favour of the term Full-stack Designer that shares the same spirits as that of the term Full-stack Developer.

(Download PDF from http://desops.io/2018/05/10/infographic-the-full-stack-roles-in-desops/ )

Typically the phrase “full-stack” (or full-stack developer) refers to someone who is someone comfortable and could single-handedly tackle every layer of software development. Typically DevOps engineers and full-stack developers share the same philosophical traits — they strive for greater agility and flexibility and hint at a trend towards greater generalization in the skillset of technical professionals. In case of the full-stack designer, he grows into a cross-disciplinary professional who can handle across Interaction Design, Visual Design as well as UI Development or prototyping. This helps to reduce the gaps between the outputs from these different and the effort that goes into the translation of concept flowing from one stage to another, where there are many roles assigned to more than one persons are involved (And remember that one of the key principles of DesOps is to remove waste by applying practices like Lean models).

So if we see that one of the major focus of DesOps in this aspect involving the work-culture is to reduce the gaps between the roles and wastage thereby. The translation from one role and discipline to another makes the meaning second-hand interpretation and such process is never loss-less. Something or the other gets lost in translation, as we progress towards the realization of the value or the product.

So by implementing Lean methodologies and by striving towards having minimally sized team members with as diversified expertized to help to minimize the intersections or touch points among disciplines and roles where the translation happens. In short less need to translate the value, the less information gets lost and less is the waste in terms of value, effort, cost and time.

Going “full-stack” is one approach to avoid the waste that happens in the process that Barthe has termed as indefinite regression or Aporia . This is mostly from the roles perspective. The other approach is through process or work practices redesign to reduce the number of intersections where the translation happens. In the context of DesOps, this is significant, as it involves the interactions at various levels between the primary two entities i.e. human (i.e.people or user ) and machine, namely — from human-to-human, human-to-machine, machine-to-human and machine-to-machine.

So one of the key factors involved while implementing the DesOps in the organization is to look for process re-design to “minimize the touch points of interaction” through the principle that advocates to minimize the gaps between the roles.

Sometime back, I was evaluating some of the design systems and tools available to study the pain-points while transitioning the design concept from one tool to another and moving from one role to the other. I got in touch with many of my friends who were designers by profession in different enterprises and were at different levels of comforts with existing design and wireframing toolsets, starting from Adobe Suite to the Sketch based eco-systems. Based on the discussions, the interesting thing that I found was many of the tools being used at different organizations, are selected based on the pricing and what the team is comfortable working with, rather than with a focus to have a seamless workflow. In many cases, the cost played a bigger role and due to licence cost, some had switched from most popular design tools to the cheaper replacements. However, the biggest struggle that was there was never solved i.e. the iterations in the design process remained challenging despite the change in tools. Every change in design aspect that was iterated was facing the overshoot of the effort, time and cost. The transitions of value from one set of tool to the other e.g. the quick wireframe created in Powerpoint during the stakeholder workshops were being translated into Photoshop was actually about relooking at the layout due to the constraint that popped up while working with the specific widgets in a specific resolution that never went well the wireframe concept. In one organization, the team replaced the Powerpoint with Sketch and tried to use that to complete the process, which turned into a nightmare as the sessions ended with the people struggling with the tool.

In search of a tool that can minimize the translations of values, I was toying with an idea of Ditto, a simplified version of the tool that can look familiar to the different roles involved in the process and at the same time it will align with a process that is about having the same source files at any of the stages of the process and can align with any design system with easy configuration mechanism.

(Figure : The common pain-points in typical Design-process  )

 

(Figure : Typical Design process based on various touch-points where translation happens )

Ditto is a conceptual vision of a design tool that uses UI pattern Library (which is configurable ) and understands the relationships among the components of the design system configured to create and maintain its own objects that can be rendered on a super simple easy-to-follow and familiar looking interface with drag and drop kind interactions enabling the users of different role to focus on their goal rather than figuring out how to use the tool. Conceptually Ditto was capable of taking any type of inputs and exporting different types of outputs on demand e.g. the wireframes, visual comps and ready to deploy UI coded with HTML/ CSS/JS.

(Figure : The conceptual solution, Ditto is based on a “Single-Source” based process )

(Figure : The conceptual solution, Ditto  is based on a “Seamless Workflow” based process )

 

Watch a video demo that elaborates the concept in context to these use-cases —

The benefit of such a tool would be to reduce the critical – dependency on any particular role in the team in order to carry out with the project. For example, assuming a startup is only having a visionary guy with a developer, he can go into the tool to drag-drop few shapes and objects in a traditional Powerpoint / Keynote kind of interface which he is familiar with and export that as a barebone interactive code/prototype that can be tested. He can continuously test and get feedback, based on which he can tweak the same source and iterate. His developer friend can use the same source to export the code in a click to use in the production. And interestingly if he makes any change, that would be updated back to the same source. Later if a visual designer’s help is taken to customize the look and feel, it would allow updating the same source that’s running in the production where the necessary changes to the code will be managed by Ditto in the background. And despite the fact that the visual designer modified the source, (which affects the internal code) he is doing that in a Photoshop kind of environment familiar to him.

If we look at this “Single Source Based Design Eco-System“, any role can enter and come out with a production-ready code, be it a product owner or CEO of the startup, or an interaction designer, visual designer or a UI developer.

The benefits of such a tool are many:

  • Seamless work-flow for Design – Developer collaboration
  • Saving on license cost as no longer it is required to use multiple design tools
  • Single source makes it maintainable.
  • The omini-change process ensures that any changes happening at any stage of design stage will automatically take effect on other stage deliverables. (i.e. assuming at if UI html code is tweaked, it will also reflect in wireframe and visual design stages without any extra manual work!)
  • Zero learning-curve
  • Single user – Single Tool: makes it easy for any of the roles can login and generate implementation ready UI output.
  • Significantly reduces Cosmetic / UI compliance issues
  • Significantly reduces the time to implementation of the design concepts
  • Boon for Agile projects where the changes are common.

Some of the components of the conceptual design tool Ditto, you might have noticed are already available in some of the design tools. For example, similar in Sketch, you can create a custom pattern library theme and use drag and drop to add them while you are designing. But, its more about customizing themes based on existing ones and exporting shapes specific CSS at the end, which is at a very lower level of maturity from a design system standpoint. Similarly, exporting existing design to HTML feature from Adobe’s Creative Cloud Extract in some sense does not take account into how certain design systems of high maturity can be fit into it so that the output can have functional interactions as a part of business flow for the UI.

But certainly, Bootstrap Studio is much closer to the concept of Ditto. It can be improved around the areas configurations and there is a need to move away from the traditional Application type UI and interaction layer so that it can align to one of the core attributes i.e. to make each user role feel familiar with the interface or rather making it easy to follow. The UI widget based WordPress-page builder tools like Elementor are closer in this regard. While talking about Eco-Systems the tools and technologies, I will write about what are the tool-chains that we can combine for different levels of DesOps implementation looking at the maturity levels of Design Systems in play in the organizations.

Well, the thoughts presented above is a practical example of conceptualizing a value communication using improvements in processes and using technology to applying regression to the touch points where the translation happens, and thereby reducing waste and avoiding loss of meaning of value throughout the design process. We will explore the aspect of communication aspect of human-to-human, that is an important part of DesOps culture. Stay tuned.

(c)2018 , Samir Dash. All rights reserved.

(This article is originally published at on May 12, 2018 at  https://www.linkedin.com/pulse/desops-next-wave-design-part-11-translating-value-different-dash/ )

Infographic: The Left-Right Brain Analogy for Incident Tracking in DesOps

 

Download the PDF version here: https://www.slideshare.net/MobileWish/infographic-the-leftright-brain-analogy-for-incident-reporting-in-desops

©2018,”Infographic: The Left-Right Brain Analogy for Incident Reporting in DesOps” by Samir Dash.
Creative Commons Attribution-Share Alike 4.0 International License

Engineering and Design Processes: Usability Engineering vs. Usability Design


(Originally first published on July 2, 2014 at https://www.linkedin.com/pulse/20140702065138-9377042-engineering-and-design-processes-usability-engineering-vs-usability-design/ )

Also, this article is a part of the title UX Simplified: Models & Methodologies by Samir Dash (ISBN: 978-1-3115-9110-4 / ASIN: B00LPQ22O0 ).  Available at Amazon: http://www.amazon.com/dp/B00LPQ22O0/


Usability Engineering

Usability Engineering began to emerge as a distinct set of “professional practice” in the mid- to late 1980s. The majority of the professionals of this practices were from varied backgrounds such as Computer Science or in a sub-field of Psychology such as Perception, Cognition or Human Factors. Today this field is being populated from some newer discipline such as Cognitive Science and Human-Computer Interaction.

Usability engineering, is defined by Preece as

‘an approach to system design in which levels of usability are specified and defined quantitatively in advance, and the system is engineered towards these measures, which are known as metrics.’

The whole concept of Usability Engineering focuses on the “metrics for measuring usability”.

As the emphasis on usability metrics through “analysis and evaluation”is mostly the soul focus of this process, there is not enough focus on the actual design process. In this process the usability is tried to be attained through “engineering and quantifiable methods and techniques” rather than “designing the way to usability”.

Also the “usability engineering”focuses only on providing range of techniques to analyze users, specify usability goals, evaluate designs, but it does not address the whole development process.It has more of a focus on “assessing and making recommendations to improve usability than it does on design, though Usability Engineers may still engage in design to some extent, particularly design of wire-frames or other prototypes”.

The usability engineering mostly seen as a separate activity that can be plugged into different SDLC models as a separate set of activities from a process-oriented perspective.

The Usability Engineering conducts evaluations through the following tools and methodologies:

  1. usability testing
  2. interviews
  3. focus groups
  4. questionnaires/surveys
  5. cognitive walkthroughs
  6. heuristic evaluations
  7. RITE method
  8. cognitive task analysis
  9. contextual inquiry
  10. Think aloud protocol

User-Centered Systems Design (UCSD)

User-Centered Systems Design (UCDS) is set of “usability design” process focusing on usability throughout “the entire development process and further throughout the system life cycle”. It is based on the following key principle:

  1. User focus: The goals of the activity, the work domain or context of use, the users’ goals, tasksand needs should control the development.
  2. Active user involvement: Representative users should actively participate, early and continuously throughout the entire development process and throughout the system life cycle.
  3. Evolutionary systems development: The systems development should be both iterative and incremental.
  4. Simple design representations: The design must be represented in such ways that it can be easily understood by users and all other stakeholders.
  5. Prototyping: Early and continuously, prototypes should be used to visualize and evaluate ideas and design solutions in cooperation with the users.
  6. Evaluate use in context: Baseline usability goals and design criteria should control the development.
  7. Explicit and conscious design activities: The development process should contain dedicated design activities.
  8. A professional attitude: The development process should be conducted by effective multidisciplinary teams.
  9. Usability champion: Usability experts should be involved from the start of project to the very end.
  10. Holistic design: All aspects that influence the future use situation should be developed in parallel.
  11. Process customization: TheUCSDprocessmust be specified, adapted and implemented locally ineach organization. Usability cannot be achieved without a user-centered process. There is, however,no one-size-fits-all process.
  12. A user-centered attitude must be established: UCSD requires a user-centered attitude throughout theproject team, the development organization and the client organization.

The typical process flow of UCSD can be visualized as the following steps (based on ISO/TR 18529:2000):

  1. Pre-study and business analysis: It can be anything from a comprehensive analysis of work procedures, business processes, etc., to a brief statement or vision.
  1. Planning the user-centered systems design process: includes setting up the project with resources, activities, roles, methods, etc.
  1. Do iterative UCSD /Usability DesignActivities: The usability design process approximately.
  1. Formal Summative Evaluation: It covers the usability of the resulting system, as opposed to the formative evaluations used in the usability design process to learn about details in the design .
  1. Introduce and Operate the System: includes installation, change management, user training, evaluating long-term effects and so forth.

The focus of UCDS is all about “changing the attitude among all professionals involved in the software development process” and these set of 10 principles are key for the “user-centered systems design process” which helps in giving “equal weight to interaction design, analysis and evaluation, combining interaction design, and usability engineering”.

Usability Design

The Usability Design is roughly a subset of the UCSD process that matches the “Do Iterative UCSD” step of the UCSD process.

Further study

The usability design outlines the steps in the development process involving usability design aspects. The process can be divided into three main phases:

  1. Requirements analysis: This step is synonymous with planning and analysis phase of typical software development life cycle(SDLC).
  2. Growing software with iterative design: This is the design and testing phase and development phase of typical SDLC.
  3. Deployment: This is same as deployment phase of typical SDLC.

http://samirshomepage.wordpress.com/2013/09/23/dont-get-confused-ucd-vs-ucsd/

(c) 2012-14, Samir Dash

Don’t get Confused: UCD vs UCSD


(Originally first published on July 4, 2014 at https://www.linkedin.com/pulse/20140702070019-9377042-don-t-get-confused-ucd-vs-ucsd/ )

Also, this article is a part of the title UX Simplified: Models & Methodologies by Samir Dash (ISBN: 978-1-3115-9110-4 / ASIN: B00LPQ22O0 ).  Available at Amazon: http://www.amazon.com/dp/B00LPQ22O0/


In my last posts I discussed about Usability Design and User-Centered Design (UCD) and User-Centered Systems Design (UCSD). But many confuse between these two. So in the following I am trying to differentiate these two:

UCD vs UCSD

UCD is differs from the UCSD in the following areas:

  1. Goal: The goal of UCSD is more on the process than the user so as to make the final product/system more usable. UCD rather focuses more on “users” of the product and not the design process. More focus is spent on understanding the user and their need.
  2. Process vs. Techniques Set: UCSD is about system development where as UCD is mostly a set of tecniques and process sets to be used with in UCSD
  3. Perception: The DNA of UCSD is about changing the mindset of the professionals in the development process so that the designing aspect of usability can be put into practice freely and with higher priority. The UCD process is not about the changing perception about the priority of the design in the whole process.
  4. Broadness: UCSD covers the whole process that includes the areas which are even not part of “designing” whereas UCD can be seen as a subset of UCSD focusing of the “design process sets”.

UCD Models and Process

There 3 different models that support UCD in varying degrees and follow the ISO standard Human-Centred Design for interactive systems:

  1. Cooperative Design: This involves designers and users on an equal footing.
  2. Participatory Design (PD): Inspired by Cooperative Design, focusing on the participation of users
  3. Contextual Design: “Customer-Centered Design” in the actual context, including some ideas from Participatory Design.

All these UCD models involve more or less a set of activities grouped into the following steps mentioned below:

  1. Planning: in this stage the UCD process is planned and if needed customized. It involves understanding the business needs and setting up the goals and objectives of the UX activities. Also forming the right team for the UX needs and if needed hiring specialties fall into this step.
  2. User data collection and analysis: This step involves data collection through different applicable methodologies such as user interviews, developing personas, conducting scenarios , user-cases and user stories analysis, setting up measurable goals.
  3. Designing and Prototyping : This involves activities like card sorting, conducting IA, wire framing and developing prototyping.
  4. Content writing: this involves content refinement and writing for web and similar activities.
  5. Usability testing: This involves is a set of activities of conducting tests and heuristic evaluations and reporting to allow refinement to the product. However Usability Testing can have its set of steps involving similar activities such as planning , Team forming, testing , review and data analysis and reporting.

All these are similar to most of the steps that fall under Usability Design as UCD can be seen as a subset of process with in Usability Design.

So many processes: What is where?

After going through multi relation models in all these processes and sub process discussed in this post and the previously discussed posts, it might be little confusing to visual all the overlapping and dependable process sets. So here is a simple representation diagram that roughly shows the overlapping relations:

 

(c) 2013-14, Samir Dash

 

 

Linearity Matters: Rethinking eCommerce UI

(Originally published on August 24, 2014 at https://www.linkedin.com/pulse/20140824143435-9377042-linearity-matters-rethinking-ecommerce-ui/)

“Linearity” plays a strong role when it comes to usability of any e-commerce checkout. Many theories supporting this concept have been proved by numerous statistics. UX sites which talks about the best practices to follow while designing the checkout process, always advocate maintaining linearity. It’s make sense when we see multiple principles in human factors indicate that in most of the time when users are “walking on the path” in a multi-step process they want to move forward. But only designing the checkout process is not enough, as from the views of typical goal oriented design, the whole experience of shopping starts with user’s objective to “find something that might influence him enough to buy”where the whole experience is a flow-state which maps to the mental model of the user where “finding” and “buying” are the major component of buying. The former being the “cause” and the latter being the “effect”, the design of the experience should always be linear in order to avoid the situation where the user is distracted by something else to break that state.

If users think of your multi-step process as a straight path, then the sequence of your views must be linear else you will break people’s expectations that will result into a bad experience and usability.

Traversing from user needs the towards the task flow

“I need” –> “I buy”–> checkout

is equivalent to

“I need” –> “I find it ” –> “I buy”–> checkout

is equivalent to

“I need” –> “I browse for it ” –> “I search for it ” –> “I buy” –> checkout

is equivalent to

“I need” –> “I browse for it ” –> “I search for it ” –> I compare –> “I buy” –> checkout

There are two major task clusters now:

1. “I need” –> “I browse for it ” –> “I search for it ” –> I compare –> “I buy”

2. “checkout”

Note the goal stating “I buy”, is the logical point that is represented by the behaviour of the user through the act of “adding to basket/cart”

Meanwhile the act of comparison of the products can be spanned from what is in the browsable and searchable views and what is already existing in the cart (which the user has added to the card already through a previous loop in this category of task). It is similar to the way that you might have added a deodorant “Old Spice” to the cart and suddenly decided to go for an “Axe” that offers 10% extra in the same price (Note that the user’s mind wanders 30% of time). So it helps to allow the user to be in the loop with in the first task group and then jump to the checkout while making the transition to checkout seamless. In order to achieve, the more the mental model matches to the conceptual one and indicate the user’s state in the flow and encouraging him through “progression” in the linearity path.

Here is a sample flow that takes the benefit of the linearity as a part of the process for the experience that covers the pre-checkout and checkout process to complete the flow state.

The target of the solution is primarily a tablet, which is acting as a catalyst as being a touch enabled swipe gesture controlled device it provides the user the effortless approach to move between the “browse/Search” <–> Cart <–> Checkout , once he has reached the entry point to the system.

Explore the complete project at
https://www.behance.net/gallery/19044315/Flip-the-Cart-Reimagining-Social-Commerce

(c) 2014, Samir Dash. All rights reserved.

What the Failure of Google Glass Teaches About UX?

(This article was originally published on February 9, 2015 at https://www.linkedin.com/pulse/what-failure-google-glass-teaches-ux-samir-dash/ )

In mid of January I saw the headlines making official announcement of the death of Google Glass. I was not surprised. I knew lot of issues ave to be addressed before Gass could make it to the expectations. Many of them are issues related to UX. All of them related to an grey area of UX space, which was never given the prime consideration when designing a seminal product like Glass and many other legends.
Back in 2013, I had wrote a few posts on the usability in context to the social aspect of Google Glass that was being ignored. When I read now the article saying “privacy concerns” is one of many reasons of failure, it certainly louds the many of the design approach concerns I had raised.

Google Glass is not evil product, everyone agrees. Even all agree that it has immense potential. However, it certainly needs a facelift from product design point of view — and there by from UX point of view.

We saw, the raise and fall of Google Glass carrying it’s pattern where we can notice how with the emergence of Google Glass, the topics related to devices infringing with personal privacy became hot cakes for tech-debates. Many social scientists, human rights activists had started to see the ‘Glass’ as the evil that reminds them with George Orwell’s ‘1984’. The fear of a ‘Google Big Brother’ controlling the major shares of the information world is seen as the intruder to private aspects of ‘the public’. The “Glass Hole” incarnation of the Glass is equally seminal as the product “Glass” it self, due to bring out the topics like “user privacy”, “social context” and certainly what I believe as the “Context of the Other”.

It is not the case that Google has not spent money on user research and usability aspects before going ahead with the concept of persons using glass that may change the way we interact with systems in our daily life. Usability wise, it is definitely a super gadget that has the potential to catapult the device industry into next century. But the new features and interaction methods implemented in the device in a manner that is actually a decade old approach that is only fit for human-computer-interaction (HCI) in case of smart phones and tablets which have less tendency to hurt sentiments of those who do not directly interact with the device when the user might be performing some actions in a certain socio-cultural context. These sentiments could result in the fear of losing privacy , cultural distrust and humiliation among the second-hand users of the device who are impacted indirectly in some way by the device actions in the context.

Historically, the product design process while following the check and balances with heuristics and usability models, has never given prime importance to the user’s relationship to the ‘Other’ in his environment. And this is the missing piece that needs to be re-discovered and fit into standard usability matrix when Google might give “Glass” a face-lift to bring it back with a new incarnation that is more friendly and less intruder to user’s privacy and is compatible with SX model (Socio-cultural Usability Model) which I had proposed earlier.

Socio-Cultural User Experience (SX) – the missing piece in UX


‘Socio-Cultural User Experience to represent the aspect of Usability Design or User Experience (UX) that deals with usability aspect of products/ software in a social context. This is the same “Context of Other”

Considering the ‘Others’ in the User’s Social circle:

The existing UX model does not analyze the need beyond the current user and his ‘type’ to do a usability test — it never considers how it is impacting the other members of the society while the target user set is using the app/system.
For example, using car horn is a safety measure, but using it near a hospital or school is considered as unsocial and disturbing. There are many social check points that bar users of any system from using it in special socio logical context.

Criteria of a Good ‘SX’ Compatible System

Criteria of a sound usability design of an app on socio-cultural context:

1. Universal—has design elements that are universal.
2. Ethical – follows principles and approach that has positive ethical value
3. Non-racial – non biased and non-provocative attitude to user’s race and beliefs.
Socio-cultural User Experience (SX) and Social Interaction Design (SxD)
4. Respectful – towards user’s culture, social beliefs and ethnicity
5. Safety – has it’s social impact that is safe for the User.
6. Non-abusive – must not exploit the user and the environment he is in .
7. Common Sense – has geared towards common sense – behaves and reacts to the user in a sensible way
8. Protect Privacy – App’s feature and interaction must protect user’s privacy and other humans in the social circle.

Let’s take the case of Google Glass.

Google Glass is designed in a way that can act as more personal than a mobile handset, as it is a spectacle and can be indispensable accessory for the user once he gets addicted to it by replacing his conventional glass with it.

But the support for camera to take picture can pose a problem for the user to enter private areas, industrial areas, secure zones and offices where cameras are not allowed. In some places of earth, the cultural restrictions are in practice to ban cameras in certain places — most of the temples in India do not allow cameras inside. Now imagine, if the user has replaced his traditional spectacle for it , then he may find it difficult to manage without it in these scenarios.
So by following SX approach in usability design, the glass will require to have a “detachable set of camera” used in the glass so that the user can detach the camera and which would power it off and at the same time allow the user to keep on using the glass as a conventional spectacle.
This example may be just one of many features that Google glass might have, but it is enough to illustrate the approach in thought.

Points to Focus on while designing a SxD Compatible System

1. Provide multiple alternatives to the interaction methods to control the same functionalities in different socio-cultural context.
2. User should have total control over enable/disable of interaction methods for different scenarios.
3. The default interaction method must follow ‘SX’ approach.
4. Provide options to the user to switch between interaction methods with the system as and when needed.
5. Alternative mechanisms should be provided for physically challenged users. Rethink on the use of gestures and other interaction methods in the Article 508 context as everyday the new devices with unpredictable (not necessarily negative!) interaction methods and features.

Gesture and other Interaction Medium of SxD:

The ‘Social Interaction Design’ approach has the following major facets in the system interaction towards the user in socio-usability context:

1. Facial Gestures—The selection of Human triggered facial gestures (e.g. wink, smile etc.) to activate the system or trigger any action in the system must be judged based on the canonical meaning of those gestures in social and cultural context of the user where he is going to use it. For example, in case of Google Glass , the feature of “winking” (the gesture developed by Google Glass developer Mike DiGiovanni http://news.cnet.com/8301-1023_3-57582500-93/google-glass-code-lets-you-snap-a-photo-with-a-wink/ ) at someone to take a photo can pose a problem if the user is in India or Middle East countries. Even in western world winking at a lady or group of ladies (even though it is unintentional for any kind of abasement) can be taken as a negative action (e.g. weakness in character) and evoke anger and misunderstanding. So even if the winking to take a feature is a ‘cool feature’, in social context SxD will suggest the usability/interaction engineer to rethink on it to implement some options to ‘keep it disabled by default and allow the user the total freedom to use his judgment to enable and use the feature in any given socio-cultural context. Fig5: The ‘wink’ gesture developed by Google Glass developer Mike DiGiovann allows user to take a snap of the surrounding with just a wink of an eye.

2. Sound Gestures — The selection of sound gestures – the use of voice or sound pattern to control the system should be examined for different user environments. For example blowing a whistle to activate a play functionality on a portable music player, or to open an SMS on the cell phone can be an interesting feature, but on the other hand if it becomes useless in a busy street or in a meeting room where a discussion is going on.

3. Touch-based Gestures – Touch, swipe and pinch are popular now a days as most of the tablets and smartphones offer this as a user friendly interaction method for the user. More devices are coming up which do not have any physical button rather a few multi-touch gestures are enough to fully control them. However ‘SxD’ stresses that the devices must be designed and developed with the interaction method that can allow alternative to the available touch triggered interaction mechanism. For example , while developing a digital medical instrument with touch sensitive display, the interaction methods should be carefully planned so that the surgeon can use the system without touching to avoid infections through contact with it while conducting any mission critical surgery.

4. Hand/Finger based 3D gestures – ‘SxD’ approach encourages to conduct a social analysis of the hand/finger based gestures that are planned to be used in a system – the gestures should selected / innovated by carefully studying the cultural context avoiding common gestures used in daily life that are considered abusive to others. In addition to this practical usage resulting out of user’s environment and work culture must be given consideration. For example the middle finger gesture commonly used by youths to represent the crack humiliating pun on the other should not be used for any app that is expected to be popular among the users from the similar demography. But note that only considering the demography is not enough to decide the gestures.

5. Mouse /Keyboard Control – Similar to the gesture, voice and the related interaction method with system, mouse, keyboard, joystick and other typical input device based methods should be considered with in the context in which they are going to be used. As this group of interaction method are very old, many standard guidelines are already in there in practice. They However we need to rethink on them and make sure they are upto date with the ever-changing human –computer-interaction domain.

Our world needs products that are not only usable but also safe to use socially. It is high time, we need to consider the “Other” in our social context to improve the products and thereby our future.