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

 

 

Usability Design and User-Centered Design (UCD)


(Originally first published on July 2, 2014 at https://www.linkedin.com/pulse/20140702070557-9377042-usability-design-and-user-centered-design-ucd/  )

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/


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

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.

User-centered design (UCD) is a set of design processes in which “the needs, wants, and limitations of end users of a product are given extensive attention at each stage”. It is characterized as a multi-stage problem solving process involving designers who take the lead responsibility in foreseeing and solving the usability problems the users are likely to face while interacting with or using the system/product. UCD focuses on understanding the behavioral aspect of the user interacting for the first time so that the user’s learning curve in using the system can be evaluated in order to optimize and reduce it. User-centered design philosophy emphasizes on optimizing the product around “how users can, want, or need to use the product, rather than forcing the users to change their behavior to accommodate the product”.

Constantine and Lockwood define UCD as :

‘. . . loose collection of human-factors techniques united under a philosophy of understanding users and involving them in design’. . . ‘Although helpful, none of these techniques can replace good design. User studies can easily confuse what users want with what they truly need. Rapid iterative prototyping can often be a sloppy substitute for thoughtful and systematic design. Most importantly, usability testing is a relatively inefficient way to find problems you can avoid through proper design’. (‘. . . loose collection of human-factors techniques united under a philosophy of understanding users and involving them in design’. . . ‘Although helpful, none of these techniques can replace good design. User studies can easily confuse what users want with what they truly need. Rapid iterative prototyping can often be a sloppy substitute for thoughtful and systematic design. Most importantly, usability testing is a relatively inefficient way to find problems you can avoid through proper design’.

Putting it straightforward UCD is all about 4 factors which are mostly related to the end user :

  1. Needs of users
  2. Limitations of users
  3. Preferences of users
  4. Business objectives of the product.

This helps in achieving the following benefits:

  1. User satisfaction through more user friendly product experience
  2. Increase in customer /user loyalty.
  3. Making the product more relevant and valuable for the user
  4. Product / system is more value added as users

—–

(c)2012-13 : Samir Dash. All rights reserved.

The ABCs of UX: The Diverse Disciplines (Part 3/3)


(Originally first published on July 4, 2014 at https://www.linkedin.com/pulse/20140704153044-9377042-the-abcs-of-ux-the-diverse-disciplines-part-3-3/ )

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/


The current post is the 3rd in the series of 3 posts, where I would like to clarify the definitions and concepts that are core to our context covering User Experience (UX), Information Architecture(IA) and Interaction Design (IxD).

What is a “Mental Model” exactly?

A mental model is “a person’s intuition of how something works based on past experiences, knowledge, or common sense”. When you see a book you already know how to use it (i.e. read it) as this understanding of the usage of a book is bound with your past experience and the expectation aroused thereby using the book. This typical expectation of how a thing works or the expectation regarding the workflow of an object the user faces is all about a “mental model”. When it is the case of an online experience or a software usage, users expect a certain flow based on both previous experiences and an expectation on what the experience should be. Understanding and catering to this kind of user’s expectation in an intuitive manner is the most critical part of the UX design process.

During “usability testing” of a software product, it is measured against the following five important facets:

  1. Useful:if the product enables users to solve real problems in an acceptable way and as a practical utility whether it supports the user’s own task model.
  2. Findable: if user can find what he is looking for through his interaction with the system.
  3. Accessible:if the system can be used by persons with some type of disability such as visual, hearing and psychomotor.
  4. Usable:if system enables users to solve real problems in an acceptable way
  5. Desirable: if the user is emotionally motivated to use the system
  6. Meaningful: It must improve the value and customer satisfaction to be more meaningful in the context.

Fig : 1

On a close look it is clear that all of these are all related to the users’ expectations. If any of these aspects do not match the expectations of the users, the usability of the product/system decorates. So, in UX design process, the most important task is to match or at least bring the design closer to the mental model of the users.

One of the best definition about mental models as they relate to software and usability can be found out in a 1999 article by Davidson, Dove, and Weltz titled Mental Models and Usability:

For most cognitive scientists today, a mental model is an internal scale-model representation of an external reality. It is built on-the-fly, from knowledge of prior experience, schema segments, perception, and problem-solving strategies. A mental model contains minimal information. It is unstable and subject to change. It is used to make decisions in novel circumstances. A mental model must be “runnable” and able to provide feedback on the results. Humans must be able to evaluate the results of action or the consequences of a change of state.

Most-likely Mental Model

The problem with matching the interfacedesign and system flow with the mental model of the users is that :

  1. There is no fool proof approach that can provide insight into the target users’ mental models
  2. Different users have different mental models. Different users have different perceptions, past experiences, there by their mental models are most likely not the same.

In real life, an interface will never match up with every mental model because the number of possible models ranges from one to millions. So the trick is to create interfaces to match the most-likely mental models for the target users.

To determine what can be the criteria of a most likely mental model, typically different user personas, research, prototyping and user testing tools and methodologies are used.

Conceptual Model

“Conceptual Model” is a term used to represent the engineered interface that is provided to the user. For example, we can think about iBooks app on an iPad as a conceptual model being offered to the user

Fig: 2

To make UX successful, the “conceptual model” is designed to come close to the “mental model”.

If the user has read/seen any physical book, then, in this case, it will be easy for him to use iBooks app as it’s interaction approach is similar to a real-life book where the user can turn pages to read. However, iBooks has been designed by some engineer that presents a similar experience to the real book . This conceptual model in this case matches with the expectations of the user who has never interacted with the app, but has some preconceptions regarding it .His mental model about the app is formed from his past experience of interacting with the real physical book.

Challenges in Usability Measurement and Metrics

All the models and facets of usability described above have some limitations as it is not straight forward to implement them to some kind of metrics by which the usability goals can be measured. This is mostly because, there is comparatively little information about exactly how to select a set of usability factors to form a metrics to measure in the context of a software development lifecycle having aspects such as business needs and goals, management objectives, resource limitation on product development.

Even though in generic terms “usability” refers to a set of multiple concepts, such as execution time, performance, user satisfaction and ease of learning (“learnability”), taken together, it is still not been defined homogeneously to a level useful for creating a fool-proof metrics.

A challenge with definitions of usability is that it is very difficult to specify what its characteristics and its attributes should be, in particular, because the nature of the characteristics and required attributes depend on the context in which the product is used. (Alain Abran et. al. , 2002)

For such reasons, there is always a scope to create a consolidated usability model and its factors that can work for creating a metrics useful for software development life cycles.

A List of Factors for Generic and Consolidated Usability Model

As discussed above, here is a very generic consolidated usability model that can be used to create a metrics for a practical usability review.

The suggested model covers most of the commonly reviewed “factors” of different software products and systems which can be customized depending on the context or the need of the project:

  1. Effectiveness:This factor can be used to measure if the user is able to complete the tasks on product or the system (e.g. a website).
  2. Efficiency:It measures if the user is able to carry out the tasks, accurately and quickly.
  3. Findable: if user can find what he is looking for through his interaction with the system.
  4. Expectations: this measures if the user mental model matches with the conceptual model offered through the system.
  5. Emotions: This measures how the user feels while and after using the system.
  6. Satisfaction/ Experience:This measures if the overall system usage for the user is positive and if the user would like to revisit/reuse the system in case of the need (or will he look for alternatives).This is basically the subjective responses from users about their feelings when using the system.
  7. Productive: This measures if the amount of useful output that is resulted from user interaction with the system.
  8. Learnability: This measures how easy it for the user to master the usage of the functionalities.
  9. Safety: It measures the level of safety of the user and his information during and after the period of operation
  10. Accessibility:It measures the capability of the system to be used by persons with some type of disability such as visual, hearing and psychomotor.
  11. Usefulness:It measure is the product enables users to solve real problems in an acceptable way and as a practical utility whether it supports the user’s own task model.
  12. Universality: It measures if the system has universal appeal and enables the users from diverse cultural backgrounds and locale.
  13. Trustfulness:This especially measures if the user trusts the system for critical usage (such as using credit cards on an e-commerce site)
  14. Meaningfulness:It must improve the value and customer satisfaction to be more meaningful in the context..

Based on the above factors, usability metrics can be prepared to conduct usability testing on the system.

(c) 2013-14, Samir Dash

The ABCs of UX: The Diverse Disciplines (Part 2/3)


(Originally first published on July 4, 2014 at https://www.linkedin.com/pulse/20140704151444-9377042-the-abcs-of-ux-the-diverse-disciplines-part-2-3/

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/


The current post is the 2nd in the series of 3 posts, where I would like to clarify the definitions and concepts that are core to our context covering User Experience (UX),Information Architecture(IA) and Interaction Design (IxD).

Interaction Design (IxD)

Wikipedia defines Interaction Design as:

In design, human–computer interaction, and software development,interaction design, often abbreviated IxD, is “about shaping digital things for people’s use”

Interaction design involves attributes of several related disciplines such as :

  1. Design research
  2. Human–computer interaction
  3. Cognitive psychology
  4. Human factors and ergonomics
  5. Industrial design
  6. Architecture
  7. User interface design

Interaction design focuses more on human behavior through scientific tools and statistics, even when it is in fact is opposed to the disciplines which focus on “how things are” . Even when it uses tools that span across design and engineering domains, by it’s ability to perform “synthesis and imagining things as they might be” makes it a part of “designing” field.

In his book Designing Interactions. Gillian Crampton Smith, defined 4 dimensions of Interaction Design, to which Kevin Silver later added the 5 and the most important dimension (i.e. behaviour).

Fig:1

Fig. 1 represents the 5 dimensions of IxD namely:

  1. Words: This dimension defines the interactions. Words are the interaction that users use to interact with.
  2. Visual Representations: The visual representations are the things that the user interacts with on the interface. These may include but not limited to “typography, diagrams, icons, and other graphics”
  3. Physical objects or space: The space with which the user interacts is the third dimension of interaction design. It defines the space or objects “with which or within which users interact with”
  4. Time: The time with which the user interacts with the interface. Some examples of this are “content that changes over time such as sound, video, or animation”
  5. Behavior: The behavior defines the users’ actions reaction to the interface and how they respond to it.

Many confuse between Interaction Design with User Interface design, as in most cases interaction design is associated with the designing activities of interfaces. However Interaction Design focuses more “on the aspects of the interface that define and present its behavior over time, with a focus on developing the system to respond to the user’s experience and not the other way around”.

User Interface Design (UI)

Wikipedia defines it as :

User interface designor user interface engineering is the design ofcomputers, appliances, machines, mobile communication devices, software applications, and websites with the focus on the user’s experience and interaction. The goal of user interface design is to make the user’s interaction as simple and efficient as possible, in terms of accomplishing user goals—what is often called user-centered design. Good user interface design facilitates finishing the task at hand without drawing unnecessary attention to itself. Graphic design may be utilized to support its usability. The design process must balance technical functionality and visual elements (e.g., mental model) to create a system that is not only operational but also usable and adaptable to changing user needs.

User Interface design is somewhat “the form-giving counterpart to interaction design”. User Interface design differs from interaction design primarily in “ its focus on the behavior of artifacts rather than the behavior of humans”.In UI, the center of all the focus is artifacts that makes the interface, where as in case of IxD it is the human behavior that takes the center stage.

In case of a Software production process the UI is more associated with the Graphical User interface designer. In industrial design case, UI is more tilted towards the industrial designer.

Fig: 2

The Fig:2, shows various disciplines that contribute to User Interface Design.

Usability and Mental Models: Foundations of UX

What is Usability?

In 1998, the International Standards Organization (ISO),the organization well known for development of standards for industrial processes and product quality, defined“usability” as :

the effectiveness, efficiency and satisfaction with which specified users achieve specified goals in a particular environment. (ISO 9241)

ISO model prescribed the following 3 criteria as components of usability:

  1. Effectiveness: accuracy and completeness with which specified users can achieve specified goals in a particular environment
  2. Efficiency: the resources expended in relation to the accuracy and completeness of the goals achieved
  3. Satisfaction: the comfort and acceptability of the work system to its users and other people affected by its use.

Fig: 3

One year later , in 1999, Cosantine and Lockwood defined ‘usability’ as:

being composed of the learnability, retainability, efficiency of use, and user satisfaction of a product.

So basically it was an upgrade to the existing “usability” definition, with the addition of two new components:

  1. Learnability: the product usability can be learned by the user
  2. Retainability: the product usability an be retained by the user.

Basically the addition of the above two components gave rise to the concepts of “mental model” of the user and it’s role in usability.

System Models

During 1980-90’s many “system models” evolved. These models were actually representation of a system from different stake holders’ perception, namely: the user, the programmer and the designer.

Fig:4

Among the evolved models, the most notables were that of Norman , Cooperand IBM:

  1. The model based on the programmer’s perception:
    This was the way that a system works from the programmer’s perspective
  2. User’s Mental Model:
    The way that the user perceives that the system works.
  3. The model based on the designer’s perception:

The way the designer represents the program to the user, including presentation, interaction, and object relationships.

(To be continued)

(2) 2013-14, Samir Dash

The ABCs of UX: The Diverse Disciplines (Part 1/3)


(Originally first published on July 4, 2014 at https://www.linkedin.com/pulse/20140704013122-9377042-the-abcs-of-ux-the-diverse-disciplines-part-1-3/ )

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/


 

“To understand what the user is looking for in the things he is looking at.”

The current post is the first one in the series of 3 posts, where I would like to clarify the definitions and concepts that are core to our context covering User Experience (UX)Information Architecture(IA) and Interaction Design (IxD).

User Experience (UX)

User experience (UX) is a convergence of several disciplines. There is no final fool-proof list of disciplines which come together to form it. But yes, there are many popular explanations by social scientists, industrial designers and information architects which describe it as a combination of a verity of disciplines.

Fig: 1

The most popular and accepted compilation of disciplines is shown in Fig 1 where it is represented as a combination of :

  1. Information Architecture (IA)
  2. Visual Design
  3. Industrial Design
  4. Human Factors
  5. Interaction Design (IxD)
  6. Human – Computer Interaction (HCI)
  7. Architecture

There are variations available to this where commercial aspects are added to it . Fig 2 represents such a case.

In Fig:2, you can see the UX definition has been seen as all those disciplines which can work together to provide a solution that can deliver “customer with a harmonious and consistent experience”.

If you notice all the aspects such as “branding” and “customer service” are related with emotional aspect of human behavior. So user experience is also about emotions and psychological dimensions of customer’s perceptions about the product. Wikipedia also defines “User Experience” as :

User experience (UX or UE) involves a person’s emotions about using a particular product, system or service. User experience highlights the experiential, affective, meaningful and valuable aspects of human-computer interaction and product ownership. Additionally, it includes a person’s perceptions of the practical aspects such as utility, ease of use and efficiency of the system. User experience is subjective in nature because it is about individual perception and thought with respect to the system. User experience is dynamic as it is constantly modified over time due to changing circumstances and new innovations.”

Similarly ISO 9241-210 defines user experience as:

a person’s perceptions and responses that result from the use or anticipated use of a product, system or service”. According to the ISO definition user experience includes all the users’ emotions, beliefs, preferences, perceptions, physical and psychological responses, behaviors and accomplishments that occur before, during and after use. The ISO also list three factors that influence user experience: system, user and the context of use.

So basically, “User Experience” deals with the “How” factor of the product or system rather than it’s “What” factor. Most of the customers buy the product not because simply “what it does”, rather the “how” factor takes priority when it comes to choose from a several similar products.

We will dive deep throughout this series, but before that let’s see clear similar jargons.

Information Architecture (IA)

While exploring UX in previous section, we saw that Information Architecture (IA) is one of the contributing disciplines which form the total User Experience. During 1960’s ,Richard Saul Wurman, an architect by profession having skills of a graphic designer, author and an editor of numerous fine graphics related books, coined the term “Information Architecture”. He mostly developed concepts “ in the ways in which information about urban environments could be gathered, organized, and presented in meaningful ways to architects, to urban planners, to utility and transport engineers, and especially to people living in or visiting cities”. Later these impacted a set of disciplines such as library- and information-science (LIS) , graphic design and in recent years the world wide web (www). During 1990’s , with the evolution of the Web, there rose the need to rethink the presentation of library-catalog information as this information has been moved into online public-access catalogs, and in part to the proliferation of information on the Web itself. So during 90’s IA has taken on something of a connotation of applying especially to the organization of information on the World-Wide Web.

Basically Information Architecture (IA), all about organizing information in a meaningful way so that the user can easily find it when needed through proper organizationnavigation,labelingandsearchingsystems.IA also takes care of the process that ensures that there is no information breakdown or explosion with the scaling of information overtime.

Fig: 3

Fig:3 represents the 3 basic ingredients of IA, namely:

Users: This represents those who will use the product or system, their “information seeking behaviour” and their needs. Any of the following roles/skills/features can be applied to them:

  1. Personas
  2. Ethnography
  3. Usability Testing
  4. Expressing User Needs

Content: This is what is presented to the users through the product or system. This includes the data or information that is offered, along with its aspects such as volume, metadata, structure and organization. Sample skills/roles/features/concepts revolving around content are:

  1. Indexing
  2. Cataloguing
  3. Site Architecture
  4. Writing
  5. Content management
  6. Navigation
  7. Labeling
  8. Search mechanism

Context: This is what gives meaning to the content that is being served to the user. This can have the attributes like business model, business value, resource, resource constraints, culture etc. The following features/roles/skills are associated with context:

  1. Defining business requirements
  2. Project management
  3. Business model analysis
  4. ROI calculation
  5. Client management
  6. Technical constraints

(To be continued…)

(c) Samir Dash , 2013 -14

Specstra 2.0 : My Experiments in Cloud Based Design Process Automation

(Originally posted on August 1, 2016 at https://www.linkedin.com/pulse/specstra-20-my-experiments-cloud-based-design-process-samir-dash/ )

“Automation” is one of the trending phenomenon of the current technological world. Manufacturing industry has been pioneering it for decades. Other verticals are following it. In software development , testing and deployment field, automation is popularized by Dev OPS and Continuous Integration (CI) that helps speed up the software development life cycle (SDLC). But the SDLC is not only about the So what about the software design industry? What about the design phases of any SDLC? While design is getting more and more recognition across the entrepreneur world and many industry efforts like ‘IBM Design Thinking’ and similar frameworks and associated methodologies are trying to create a synergy between the ‘Agile’ approach of SDLC and the “Design Thinking”, it is an interesting crossroad in time, that can show ways of developing more usable and meticulously designed software and similar products. So when everyone is trying to bring automation to speed up process and speed up delivery, it is really interesting as well as challenging to come up solutions and tools that help in automation of designing phase of SDLC.

(Fig – It takes a minute or two for ‘Specstra’ to generate a print-ready 100 pages long style guide for any submitted design)

 

(Fig – The printable visual style guide generated within minutes from ‘Specstra’ comes handy for developers to make a pixel perfect UI)

In context of Software industry I always see “Design”  as an intersection between creativity and the technology where both shape each with the help from user needs and blending of these results into successful products. This also is the reason automating designing process is a lot more challenging than building solutions for automation of purely technology driven process. I accepted this challenge 2 years back during my short stint at an R&D center at Bangalore, of a leading mobile  brand, I was part of a large design team, where almost 70% of the crowd was visual designer and the rest belong to user experience and research team members. And many of these visual team who worked on different projects, complained about certain phases of the design process that involved creation of style guide of the app that they were working on. Every app project used to be developed for different flagship phones models with different resolutions as well as screen densities. And being developed in native languages for Android view-ports, designer used to develop each style guide for each project separately for each model of phone. Each style-guide has to be detailed to pixel level which the designer has to calculate and define taking calculation of the view port pixel density(PD). Many designers have to maintain different versions of the mock-up and the create specs for each version, which was more like a “drafts man’s job” with lesser creative moments for expressions and innovation than the previous phase where the designer has to follow the wire-frame and come up with pixel perfect mock-ups of the app screens.

Almost all the designers tried to grab their hands on the creative part of the job, getting engaged with the stake holders and
The senior designers prefered to avoid working on the style-guide, though they would love to review one. The not so seniors worked on the the drafting of the guide and churned out the specs document, yet do the crying that it is less creative even though it is one of the most critical part of the design process.

So I thought of calculating how much effort we are giving to a creative phase of creating a visual mock-up vs. a drafting work , i.e. creation of a specs document /style-guide. Roughly on average one view of a single screen to  be mocked up in something around 4-8 hours. creation of a very detailed spec. might need 4-6 hours of job. But if it is designed for multiple view-ports of an operating system with significant pixel density change along with varied resolutions, then this drafting time gets multiplied. So by creating 4 generations of phone models running different generation of Android might need 16- 24 hours. So the designer actually takes roughly one week of work for a view in this case from wire-framing stage to finished design with specs ready for the developer. Averagely an app can have 10 views , so the whole app would need approximately a month of work to be designed and be ready for 4 different models. Even though this is a very haigh level bare-bone calculation, it indicates a few things —

 

So in this context for a designer —
1. for the designer 1/4th of his work remains creative and gives him the scope to explore, innovate and express through his designs.
2. remaining 3/4th of his time is a purely drafts-man job.
So a designers job is actually boring as the volume of his output is not creative or inspirational.

For the organization —
1. It is paying higher fee for lower type of work. To exlain it — a creative work like that of coming of new designs is typically high paid job, where as the drafting job based on a creative guy’s is a low profile job , and should be paid less.
But interestingly this is the same designer, so the payment rate is actually based on his skill of how he performs in the 1/4th of the job where the creative juice flows and he is actually innovates.

2. Even though the 3/4th of the job is lower profile job, which could have been automated,consumes more from the delivery time. if we look at the timeline of the delivery of the design deliverables, we see that 1/4th of the delivery time is actually spent in creative way. So actually if there is a scope to automate the low profile manual work, where the designer does not need to use his right brain, then the deliverables could have been delivered in just 1 week instead of a month! Also note that time is money for industry, so the organization is actually spend 300% more than it should and that too on a higher price point.

Again apart from this there are other factor that contributed to a above problem. Being in a world of rapidly changing requirements, many industry are following “Agile” or “Iterative” approach of work. Which means in the short notice things can change even to the look and feel and UI aspect which would mean a change to the style guide if view of standard control lines are affected.This has a cascading effect that flows through the style guide work. So any change in such requirement means the wastage of effort and addition of new efforts to keep the specs aligned. Imagine, if multiple design centered projects are running on mission critical deadlines due to faster time to market needs, and such kind of scenario is happening to most of the projects. Looking at these kind of need, many design firms, keep a larger design workforce, to absorb such shocks. But that means more volume of cash burn at a higher price points for the enterprise and smaller startups do not stand a chance in such scenarios.

Another aspect that I think is important to notice here is that due to time crunch, many designers prefer to avoid granularity in the style guides. Provide common documentation and provide very high level change documentations to developers. Also in some cases there are gaps left in the document that go unnoticed, which forces the developers to get in touch with the designers during development phases. Also due to lack of a complete and meaningful style guide or specs, the software testing also gets impacted due to many blur lines among what is in and what’s out. Certain things the testers take as assumptions while completing the testing phases.

Specstra is a pet prototype that I had started working on, 3 years back (around 2013) to explore a possible solution for design related automation process.
The problem of design automation is most of the process blocks are related to creative aspect of the work the designer does. So I started with the blocks that were more aligned to less creative activity so that these blocks can be removed from the creative process flow . One of such area was creation of style guide design from the selected design where the designer has to spend hours to manually define specs.

 

SAMPLE STYLE GUIDE GENERATED FROM THE PROTOTYPE
https://samirshomepage.files.wordpress.com/2016/08/sample-generated-style-guide-output1418308769-en.pdf

 

The user can upload  Adobe Photoshop (  PSD), Adobe Illustrator (.AI), or PDF formatted exported from any design tool (Corel draw, Paint etc.) and within minutes Specstra can generate style guide which other wise would have taken the user days to complete and that with prone to error.

Typical Pain-points of manual approach of style-guide or a specs document creation are:

  1.  Tedious process
  2.  Lots of manual work 
    no creativity – draftsman-ship work is not fun for designer.
  3.  Time & effort consuming activity
  4.  Not scalable
    there is limit to how much a single designer can do
  5.  Comes with cost 
    Creative guys are paid to do these non-creative tings – however charges   remain the same.
  6.  Threat to agile projects 
    last moment changes in design can impact the software delivery

 

Specstra addressed all of these along with some additional benefits —

  1. Completely Cloud based
    N
    o software to install
  2. Not restricted to Adobe software solution
    Can support non adobe software
  3. Minimal user intervention is workflow
    Design automation is possible
  4. Quick to Delivery
    Reduces the designer time to delivery by 99% or more.
  5. Saves $$$$
    Saves money by 50% or more.
  6. Supports creativity
    Designer can save more time for creative stuffs and is saved from draftsman-ship.
  7. Multi-language support
    Helps a global team
  8. Supports Agile SDLC
    Quick iterations and design changes will not delay the time to development as style guide can be ready in a few minutes.
  9. One click User Experience
    One click GUI guide makes the workflow super easy.
  10. Automatically handles multiple device resolutions and screen densities.
  11. Scalable for any volume of works.
  12. No need to pay to reserve people for the work .

 

Overview of Features:

Multi Design file support:
Outputs from Photoshop, Illustrator, Corel Draw, In-Design, Gem  to be supported.

Super easy to use dashboard:
Dashboard that is easy to use and aligns with the design workflow.

Customized report builder:
Editor to add and remove details, renaming etc.

 

Detailed Report:
Font, Shape, Color, Grid, Absolute, Relative positioning. In every iteration the report  is complete in all respect.

5-10 minutes delivery  :
All reports will be generated in 5-10 minutes of upload.

 

 

Feature #1 – Complete details of the objects

 

  •  Supports text/font, shape, image objects
  •  Resolution dependent (Screen Pixel) units
  •  Resolution independent (Point) units (Auto conversion based on target pixel density of the device ) – example iOS Retina, Non-Retina, Android (LDPI, MDPI, HDPI, XHDPI, XXHDPI, XXXHDPI etc. ), PC Screen standard web resolution  etc.
  •  Font formatting information – size , family, style, color,

 

Feature #2 — Complete details of color, shapes, images & font

  • Supports text/font, shape, image objects
  • Font formatting information – size , family, style, color,
  •  Web safe / Non-web safe color analysis

 

SAMPLE STYLE GUIDE GENERATED FROM THE PROTOTYPE
https://samirshomepage.files.wordpress.com/2016/08/sample-generated-style-guide-output1418308769-en.pdf

 

LINK1:
https://www.behance.net/gallery/41228843/Specstra-2-Cloud-Based-Style-Guide-Automation

LINK2:
https://www.behance.net/gallery/26346085/Specstra-Extract-CSS-Assets-Info-from-PSD-Design-

Socio-Cultural UX (SX) in Context of Ontology, Information Architecture & Culture

(This article was originally published on March 24, 2018 https://www.linkedin.com/pulse/socio-cultural-ux-sx-context-ontology-information-culture-samir-dash/ )

During late 19th- and 20th-century, a set of European philosophers who, despite profound doctrinal differences, shared the belief that philosophical thinking begins with the human subject—not merely the thinking subject, but the acting, feeling, living human individual. This doctrine, more popularly known as Existentialism, started from Søren Kierkegaard who proposed that proposed that each individual—not society or religion—is solely responsible for giving meaning to life and living it passionately and sincerely, or “authentically“. After the Second World War years this impacted various discipline including theology, drama, art, literature, and psychology etc. and was carried over by the philosophers like Dostoyevsky, Nietzsche and Sartre.

Sartre claimed that a central proposition of Existentialism is that existence precedes essence, which means that the most important consideration for individuals is that they are individuals—independently acting and responsible, conscious beings (“existence”)—rather than what labels, roles, stereotypes, definitions, or other preconceived categories the individuals fit. So basically, “human beings, through their own consciousness, create their own values and determine a meaning to their life.”

Even though this doctrine was used and misused heavily in the disciplines like literature and filmmaking, it has elements that often helps to revisit and refining existing user experience and usability models, as the underlying concept has ontological aspects involved.

Ontology is even older philosophy, since the time of Parmenides (late sixth or early fifth century BC around the time or Aristotle), related to existence that is more of a study of the nature of being, becoming, existence and reality with the specific focus on the categorization of beings and their interrelationships. Basically, from the field of Metaphysics, it is the study or concern about what kinds of things exist – what entities there are in the universe. When we look at the whole gamut of ontology, we find three terms having the most practical context to user experience discipline – ontology, taxonomy and choreography.

Information Architecture is much more than a sitemap or wireframes. The classical definition of UX always points to have an aspect of “meaningful” to the context of experience for the user. This term “meaning” is more or less derived from the ontological perspective. The Theater of Absurd movement of 1960’s, revolved around the concept of the existence of human and the exploration of “meaning”. Samuel Beckett‘s Waiting for Godot(1966), where the two tramps waited for the Godot through-out the play, and who never arrived till the end, raised the debates that spurred many literary theories and views till the present day, tried to define what or who the Godot is. Many made the reference to archaic as well as biblical roots, where there was another sect who gave the Godot a new meaning as a saviour or a Christ of that age. Interestingly when it was asked to Beckett about the meaning of Godot, he answered “If I knew, I would have said so in the play”

Similarly, Jean-Paul Sartre wrote No Exit in 1944, an existentialist play originally published in French as Huis Clos (meaning In Camera or “behind closed doors”), which is the source of the popular quote, “Hell is other people.” (In French, “L’enfer, c’est les autres”). The play begins with a Valet leading a man into a room that the audience soon realizes is in hell. Eventually, he is joined by two women. After their entry, the Valet leaves and the door is shut and locked. All three expect to be tortured, but no torturer arrives. Instead, they realize they are there to torture each other, which they do effectively by probing each other’s sins, desires, and unpleasant memories. It reflects how ontology affects the meaning of entities/users.

In phenomenology, the terms the Other and the Constitutive Other each identify a cumulative, constituting factor in the self-image of a person; his or her acknowledgement of being real.As such, the Other is dissimilar to and the opposite of the Self, of Us, and of the Same. The condition and quality of Otherness, the characteristics of the Other, is the state of being different from and alien to the social identity of a person and to the identity of the Self.

-Wikipedia

So in user experience, specifically to communication context typically when we speak about ontological factors, we mostly mean language implies certain meaning to us, but may be confusing to others. One word can have a variety of meaning which may be simply opposite to what the user might need to communicate. This communication medium can be oral through any language, through gestures, through visual indicators over a UI etc.

As we know that a mental model of any user varies from another based on his prior experience and expectation of the subject in context. The user is always in the centre and reacts to another user or a subject through any mode of interaction and/or communication. The information that flows through this system (e.g. hypertext system or a social gathering at a certain point in time and place) is significant gets affected by the mental models of the users present and the ontological contexts they have about the others (including the users and the subjects) in that context. In information technology, an ontology is the working model of entities and interactions in some particular domain of knowledge or practices, such as electronic commerce or “the activity of planning.” In artificial intelligence ( AI ), an ontology is, according to Tom Gruber, an AI specialist at Stanford University, “the specification of conceptualizations, used to help programs and humans share knowledge.” In this usage, an ontology is a set of concepts – such as things, events, and relations – that are specified in some way (such as specific natural language) in order to create an agreed-upon vocabulary for exchanging information.

In recent years the awareness about the influence of culture on the UX practices have been increased. Day by day, Human Factor professionals are increasingly reviving the UX tools, frameworks and methodologies in the light of a better understanding of how culture influences user experience and how people think, behave, and feel. awareness of culture is extremely critical as the global community becomes interdependent economically, politically, and socially. To achieve success in the current international marketplace, Human Factors/Ergonomics (HF/E) professionals need to develop an understanding of people from other cultures, such as, for example, how psycho-social factors influence performance in the workplace due to cultural differences.

Power Distance Index (PDI) describes the degree to which less powerful members or a society accept an unequal distribution of power. The central question in this dimension is how a society handles inequalities among individuals. A high power distance means that people within a society have accepted a certain hierarchical order and the inequalities that come with it. In a society with a low power distance, people are constantly trying to equalize the distribution of power, especially those who have less power.

In the articles like Major cultural-compatibility complex: considerations on cross-cultural dissemination of patient safety programmes it is explored how the people from societies with a small power distance don’t like to be controlled. They only accept leadership if it’s based on true expertise.

So one of the popular approaches to design for cross cultural user experience is what Sabina Idler describes as — “Offer enough objective and detailed information on your website to allow people to make up their own mind. Meet your website visitors on eye-level, treat them with respect, and show interest in their needs. Communicate with this group in an informal, direct, and participative way to gain their trust and get them engaged”.

Similarly, it comes out from such research and explorations that website “visitors from societies with a big power distance are used to authorities and solid structures. Be prepared that they take you as an expert and trust you as an authority figure. Make sure you offer them facts and clear statements and don’t give them too much responsibility. Visitors from this group are less critical and less driven to search for detailed information in order to make up their own mind”.

Another cultural aspect that is critical while planning user experience for cross cultural segments is Individualism versus collectivism (IDV). The second dimension describes how much people in a group focus on themselves and on the group as a whole. The position of a society on this dimension is reflected in whether people refer to themselves as “I” or “we”. Individualist societies prefer a loose social network in which everyone is expected to take care of themselves and their immediate families. In a collectivist culture, people care as much or even more for others than for themselves. In exchange, others take care of them. visitors from a collectivist culture act in the interest of the group, rather than their own interest. They make decisions based on the opinion of others and on what’s common or popular, not so much on their individual desire. Consider this on your website and offer enough reference points, such as “most popular” categories, testimonials, or social media sharing options to gather instant and personal feedback from friends.

In Methodological Advancements of Cross-Cultural User-Centered Product Development  (2009) (https://books.google.co.in/books?id=uoReAer3ixgC&printsec=frontcover#v=onepage&q&f=false ) details, the outcome a research that aims at the further advancement of the methodological foundations of cross-cultural user-centred product development approaches based on a stable and profound theoretical basis. The research used approach to ‘study the applicability of six distinct user-centred product development methodologies’ and was ‘tested with 248 participants in total’ using ‘western concepts and theories, and their applicability in disparate cultural contexts of the Far East (China and Korea in particular)’.

The different components of influencing factors analyzed in the context of the result of the research for the cross-cultural method application were – Cognitive abilities, Creativity, Decision Making, Mental Models, Problem Solving, Emotion, Communication, Engagement, Extrinsic, Intrinsic, Ideals and Motivation.

“When asked about top three reasons for failure of International development projects experts mainly pointed out a lack of understanding about the target culture’s user, insufficient financial support and tight time schedules.”  [p. 26]

Also the dissertation suggests “ethnocentric biases” as the red flagged attribute that has to be avoided. “Consequently the experts’ top advices for being prepared for international product development refer to avoiding ethnocentric biases, to be aware of the importance of human factors, i.e. to know the user of the target market, to get the management to buy in and to allow for an appropriate time schedule“   [p. 26]

Back in 2014, I had coined “SX” to represent the overall changing practice methods in usability domain, in the context of cultural and social factors that influences. In the blog post “Socio-cultural User Experience (SX) in context of Google Glass” (https://www.linkedin.com/pulse/20140702135102-9377042-socio-cultural-user-experience-sx-in-context-of-google-glass ), tried to quantify the usability issues of Google Glass in context of the social and cultural context and deductive analysis gave a clue to the root of ‘public fear’ that was growing at the time against the Glass. It was interesting that starting from the later part of 2013, the topics related to The Google Glass infringing with personal privacy became hot cakes for tech-debates. Many social scientists, human rights activists have 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’.

Socio-Cultural User Experience (SX) is the missing piece or the component for the existing tool that helps in bringing in the quantifiable model that tries to bridge the current gap. SX is a framework that also helps to see the social influence on the user and tries to get the insight into the light.

SX provided the required handle for easy customization and tailoring of the Cognitive Task Analysis (CTA)  for people from different cultures and social backgrounds. In addition, it helps in designing for an international market, gaining knowledge with regard to the influence of social and cultural factors on perception, cognition, decision making, persuasion, trust, safety, aesthetics, and usability.   It is interesting to see that the cultural context of the user is found to be a leading reason behind the failure of international projects.

Here is an infograph of SX you can download: http://desops.io/2018/05/07/slides-sx-heuristics/

 

The Evolution of Technology in the Context of Software Development & Design Process: Take-away from the First PatternFly Conference

[This post was originally published on Red Hat Developers, the community to learn, code, and share faster. To read the original post, click here.]

Last Sunday, I returned home, India, after attending a series of collaborative sessions in Raleigh, NC, with many designers and developers across Red Hat and the open-source community, at the UX Summit and the PatternFly Conference. The whole experience was inspiring, informative and at the same time thought provoking with many takeaways, out of which the most interesting for me was that cumulatively all the inspiring talks from the speakers of the conference were implicitly hinting towards a clue. How our attempt to solve the existing technical solutions also impact the existing work process and thereby demand a rethink on the process blocks we use.

Being part of the Red Hat UX Design team, it is always an exploration and giving value to the core principle of “being open” to the “Design” — this is something similar to how the “openness” is seen as the integral value of the “Development”.

“We approach user experience design in the same way we develop our products. It’s all about being open.”

– Jim Whitehurst, CEO & President, Red Hat

So, what’s so special about the design being open? Is it something different from how we design in a traditional enterprise organization? It’s natural to have such questions when we face the open paradigm of the design challenges — I had similar questions. One thing to note here is that designing for open-source has its own challenges that require a re-look at the existing design processes and frameworks especially in the software development scenarios that have been evolving over last two decades. With the focus to bring the user-centric focus to the existing sets of Software Development Life Cycle (SDLC) — these were mostly about advocating Human Factors in the perspective through which we have been used to see SDLC.

But as day-by-day major enterprises are going open-source to bring more and more collaboration with the community to develop the software, the open-source movement itself is getting mature by gradual evolution through different seasonings in the context of the growth of technology and the changing market needs that are driving shaping the SDLCs. For example with the rise of startups in last few years, the adoption of MVP-driven Lean Development models instead of traditional SDLCs has increased indicating the evolving dynamics of adoption of such processes.

In the traditional enterprise, the design process is more or less influenced by standard UX approaches that have evolved over the last couple of decades. Taking into account the SDLC defined towards the end goal of the organization in context to the user experience related benchmarks. Many take different components/tools and methodologies from the Design Thinking and other similar HCI process models, and align them into the SDLC, be it agile, waterfall or hybrid, and try to achieve the user-centered software development (UCSD) from an engineering point of view.

There are sects of organizations, who take into account the user needs related benchmark and make the existing SDLC components to align to that — be it through User-Centered Design (UCD) approach blended with a part of Iterative, Agile or Lean SDLC models or simply following a ready made Lean UX model. While everyone is attempting to solve the UX equation to come up with the best possible framework that works great in advocating user needs, the question is still unsolved — what UX approach works best in a diversified collaborative open-source culture?

In the very first PatternFly conference held on 8th of this month, in his keynote, Michael Tiemann, VP of Open-source Affairs at Red Hat, referred to continuous evolution in the software development domain in context to design. His expressed views, which resonated more with the belief that the sustainable design solution can evolve from an organic design process, where reusability can play an important role.

(Michael Tiemann, Vice President of Open Source Affairs at Red Hat, delivering the keynote at the very first PatternFly Conference at Red Hat Annex, Raleigh on 8th June 2017)

The PatternFly community project supported by Red Hat is an attempt in such a direction that promotes “design commonality and improved user experience”. Dana’s blog post, Are “Web Components” in the future for PatternFly?, is an interesting read in this context from a technical angle where he addresses the thoughts on building a UI framework when there are so many choices and so many strong feelings about the different choices? While every organization is still trying to find the solutions for challenges related to UI development for a better experience such as – how to structure and organize CSS code for reusability in the ever-growing complex world of UI framework choices like Bootstrap, Angular & React etc. It’s also important not to forget that with each adoption of UI framework the impact on how we implement experiences to our products is also evolving, thereby making an impact to the process blocks that run the design, and development testing phases of SDLC.

This leads us to the hypothesis that with the evolution of newer technology adoptions, we are bringing the change catalysts to our development process, which can influence how we conceptualize and deliver the best experience for any product we are building. Along with it, as SDLCs are now getting re-shaped due to needs like, “faster time to market” and to bring out more sustainable solutions for the business needs, so is the associated stages of “Design”, “Development” and “Testing”. These are also getting more mature through the focus on Continuous Integration (CI) and Continuous Delivery (CD); thereby bringing a sea of change to the way software was planned, designed, developed, and tested traditionally. To this model when we add the “Open” aspect that demands the need to improve the process dynamics in order to ensure the end-to-end software delivery is sustainable in coming times. Red Hat’s recent open initiative to announce OpenShift.io is an attempt that tries to address all these aspects, at least it is a “start” where we start re-thinking openly about the solution that we thought we already have.

Openshift.io as an end-to-end development platform tries to address multiple areas or the process blocks like Planning, Analysis, and Creation, that tries to answer one question – what is the best way to deliver a software product in the most effective, seamless and consistent way in a diversified work-culture with value and best experience possible. It would be interesting to see how this platform evolves in coming times with the support and collaborative effort from the open source community to address these process related change catalysts that are getting their way into the work practices due to an ever growing complexity of technology change.

In the forthcoming posts, I will be exploring this context with respect to existing UX models and methodologies try to reflect thoughts on “UX in the Open “. Stay tuned.

(c) 2017,  Samir Dash. All rights reserved

Lean Methodologies & Hypothesis-Driven Design (HDD)

The second life-line as pointed out in the dimension of ‘Culture’ is “Cultural Shift towards Lean Philosophies” (Refer the part 5 of the current series here https://www.linkedin.com/pulse/desops-next-wave-design-part-5-definition-3-dimensions-samir-dash/ ). In this part of the series, we will be deep diving for the same.

Typically any lean methodologies are based two basic goals:

  1. Helping the organization understanding customer value
  2. Using the key processes of the organization to continuously increase it and work towards delivering a perfect value to the customer through a perfect value creation process with zero waste.

In the context of Design and User Experience(UX), in the seminal book Lean UX by Jeff Gothelf, provides some lean methodologies break the stalemate between the speed of Agile and the need for design in product development lifecycle” [Jeff Gothelf and Josh Seidenjeff, The Lean UX]. If we observe closely, the basic foundations of Lean UX prescribed are common to the core Lean philosophies, namely:

  1. Remove Wastage from Design Process — Moving away from heavy documentation to a process that creates artefacts which can be directly used in the design and development lifecycle itself.
  2. Cross-functional Collaboration — All the stakeholders from any parts of the product lifecycle including the designer, developers, quality experts, analysts, marketers and end-users all collaborate in a transparent and productive way.
  3. Experimentation Based Iterative Execution — So fundamentally it alludes to the UCD core principles, that assumes that the designer (or the team) learns from the execution of the prototypes in an iterative cycle that starts early in the product lifecycle, from which the learning is used as an input to improve the product along the way. If you notice this is the very basis of what we talked about the continuous and integrated feedback loop.

The use of Agile and Design Thinking practices can be seen alluding to the philosophies above. However, regarding the third philosophy — to ensure that the designer has the right approach to conduct the experimentation so that the feedback can be used in a productive way to take informative decision making along the way across the design process requires some non-ambiguous methodologies that can help the designer making some assumption and validate that through experimentation. This is the basis of one of the core foundations of Lean UX and related lean methodologies, which is popularly known as Hypothesis-Driven Design (HDD). As any design that we produce is based on certain assumption and HDD provides the non-ambiguous approach to the same, that follows the third philosophy i.e. Experimentation Based Iterative Execution.

“Declaring assumptions is the first step, in Lean UX process” [Jeff Gothelf and Josh Seidenjeff, The Lean UX] . This statement reflects how the assumptions or the hypothesis is the core the Lean UX principles. Basically, the four steps in the Lean UX approach is the same blocks that appear while in HDD, and can be mapped to the following blocks:

  1. Making Assumption / Formation of Hypothesis
  2. Build a Prototype / Minimum Viable Product (MVP)
  3. Execute / Run the Prototype
  4. Get Feedback / Observation

Now step 4 is the feedback loop that connects to step 1 making a cycle, thereby using the feedback from current iteration as the input to form the assumption for the next iteration.

Interestingly this means the HDD process always depends on outcomes rather than traditional outputs of any traditional process. The outcomes are kind of hints from the segment that can give direction to the design along the way and help in getting incremental validation of the vision by acting as “evidence” or the and more precisely they are the factors that help in “course correction” for the design. As the outcomes of the assumption act as pieces of evidence, it helps in making data-driven decisions.

You may ask, does that mean the design is reduced to quantitative factors which will act as evidence to support some of the designs? Now, here is the interesting aspect that helps to understand the approach — the feedback or the evidence can be either quantitative or qualitative in nature. And to avoid the risk of being limited to measurement-driven design, the qualitative perspective is provided equal footing in HDD approach. This makes a fit case for DesOps that can help in converging the technology with this philosophy to form required service design solution powered by machine learning, artificial intelligence and automation. The aspect of the actual implementation using technology is what we will be exploring in coming articles of this series, mostly while discussing the third dimension i.e. technology.

The very first step in HDD, i.e. “Making Assumption / Formation of Hypothesis” involves articulation of the assumption or the hypothesis. And this is the most important aspect of HDD, as the other steps depend on this. Typical hypothesis statement can be framed as per the following simplest form —

I think doing [this] will result in [that ].

There multiple variations to this that many professionals use in their area for HDD based research and design /development activities. Some add the factors such as the segment or the persona or the end user of the product, something like the following —

For [user / him/her ] I think doing [this] will result in [that ].

If you see the above keeps segment in a context that helps it keep focused on to specific persona, which thereby can lead to the user-centred design process. This is essentially labelled by many as a design hypothesis.

Some use additional factors of forming negation of the hypothesis by adding an attribute like whether this hypothesis is believed by him as true or false. To formulate a null hypothesis and thereby move on to define an alternate hypothesis (which is essentially a negation to the null hypothesis one craves to validate, but due to nature and structure or any metrics associated with that, it may not practically be possible to achieve that. So in such kind of cases the implicitly the state of belief is presented as another factor to take part in the validation process —

Because I think [this] is true, I think doing [this] will result in [that ].

I believe that any hypothesis statement can be cultivated from the bare-bones model of cause and effect being rendered as a formalized statement of “if …. then” or “when … then” kind of format. At least this gives a more practical approach to build a real-world HDD based system which is technically feasible and is the essence of any DesOps system.

The next important aspect in this regard is how to ensure that we are considering the qualitative aspect of the evidence, as discussed above. If we look at irrespective of the fact that there is a crowd of applications out there which claims to support the business through a data-informed approached, they are primarily a set of some variation between the extremes like A/B testing tools and data-driven analytics and data modelling based prediction systems. But if we notice with care at the core of HDD we found that the essence of HDD lies in making sense of the data and treat it as evidence so as to inject it to a UCD based process to fuel design or business decisions. Though coming up with a real-world HDD system would require similar tools and technologies of data-driven systems, but they will be supporting components to HDD based system. In this regard, the real HDD based full fledged system is literally non-existent as of today, while I am writing this article. In regards to DesOps, this makes a lot of difference, as most of the HDD frameworks out there are not 100% autonomous. Most of the implementation of HDD is mostly based on the work practices and methodologies, which is implemented depending on the need and feasibility. However, these are good enough when we use these, in context to the tools we gain from UCD, Lean models and the Design Thinking principles. But, it is interesting that the philosophies of DesOps, take it to the next level, making it autonomous and integrated with the over-arching feedback loop we have been referring many times.

To be continued… Keep tuned in.

 

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

Beta Testing in the Ever Changing World of Automation

(Apart from some details about my prototype in Beta Testing, this also explores the interesting definitions from ISO regarding quality that brings “reviews in context” that fundamentally lauds usability philosophies. (Originally first published at RedHat Blog in January 2018)

Beta testing is fundamentally all about the testing of a product performed by real users in a real environment. There are many tags we use to refer to the testing of similar characteristics, such as User Acceptance Testing (UAT), Customer Acceptance Testing (CAT), Customer Validation, and Field Testing (more popular in Europe). Whichever tag we use for these testing cases, the basic components are more or less the same. To discover and fix potential issues, this involves the user and front-end user interface (UI) testing, as well as the user experience (UX) related testing. This always happens in the iteration of the software development lifecycle (SDLC) where the idea has transformed into design and has passed the development phases, while the unit and integration testing has already been completed.

The beta stage in the product lifecycle management (PLM) is the ideal opportunity to hear from the target market and to plan for the road ahead.

As we zoom into this phase of testing it has a board spectrum of ranges. On one side is the Front-End or UI related testing involving UI functionality (Cosmetic, UI level Interaction and Visual look and feel). At the other end is the User Experience (UX), including user testing involving more from A/B (split) testing, hypothesis, user behavior tracking and analysis, heat maps, user flows and segment preference study or exploratory testing and feedback loops.

Beta testing relies on the popular belief that goodness will prevail, which defines the typical tools that carry out such tests. Examples are the shortening of beta cycles, reducing the time investment, increasing tester participation, improving the feedback loop and visibility, etc.

The Importance of Beta Testing

If we dive deeper into the factors behind the existence of tools from different angles, we find two major reasons that advocate the importance of beta testing:

1. Left-right brain analogy, which points to the overlap between humans and technology.

The typical belief is that the left-hand side of the brain mostly processes the logical thinking, while the right-hand side is more about the emotional thinking. Based on this popular analogy, when we map the different aspects involved in different stages of SDLC for a digital product across a straight line from left to right (refer to the diagram below), we will notice the logical and more human-centered aspects are divided by an imaginary line from the center. We will also notice the gradual progression of the emotional index for the components from left to right.

When we map these to the beta testing phase, we notice these right-hand components are predominant. As users of the products (like humans), we are more emotionally connected to such aspects of the product, which are validated or verified in a beta test. This makes beta testing one of the most important testing phases in any SDLC.

Another interesting point to note is that when we look from the traditional software approach to define “criticality”, the areas that are tested during user acceptance testing (UAT / Beta), mostly fall into Class 3 and 4 type of criticality. But because these touch the core human aspects, they become more important. This Youtube video (Boy Receives Enchroma Glasses From Father) helps to illustrate the importance of technology touching the human emotions. It was posted by a popular brand of glasses to demonstrate how they can correct colorblindness in real time for the end user.

Interestingly, this is an aspect of “accessibility”, which is typically covered during a beta test. Considering this video, the aspect of accessibility naturally raises the question about what we can do for this father and son as a tester, as a developer, or as a designer? And when we look at the stats, we find that the number of people the accessibility impacts is huge. One in every five people is challenged by some kind of disability. And unfortunately, some reports indicate that a majority of websites do not conform to the World Wide Web contortion’s (W3C) accessibility guidelines (in 2011 almost 98% of websites failed the W3C’s accessibility guideline).

This helps to demonstrate the human angle, which advocates why beta testing is important to ensure these aspects are validated and verified to ensure the target user needs are completely met.

2. A second reason for advocating the importance of beta testing is evaluating it from the international standards perspective (ISO/IEC 9126-4). This helps to define the difference between usability and quality.

The International Standards Organization (ISO) has been focused on the standards around quality versus usability over time. In 1998 ISO identified efficiency, effectiveness and satisfaction as major attributes of usability. In 1999 a quality model was proposed, involving an approach to measure quality in terms of software quality and external factors. In 2001 the ISO/IEC 9126-4 standard suggested that the difference between usability and the quality in use is a matter of context of use. ISO/IEC 9126-4 also distinguished external quality versus internal quality and defined related metrics. Metrics for external quality can be obtained only by executing the software product in the system environment for which the product is intended.

This shows that without usability/human computer interaction (HCI) in the right context, the
quality process is incomplete. The context referred to here is fundamental to a beta test where you have real users in a real environment, thereby making the case of the beta test stronger.

Beta Testing Challenges

Now that we know why beta testing is so very critical, let’s explore the challenges that are involved with a beta stage.

Any time standards are included, including ISO/IEC 9126, most of these models are static and none of them accurately describe the relationship between phases in the product development cycle and appropriate usability measures at specific project milestones. Any standard also provides relatively few guidelines about how to interpret scores from specific usability metrics. And specific to usability as a quality factor, it is worth noting that usability is that aspect of quality where the metrics have to be interpreted.

When we look at popular beta-testing tools of today, the top beta testing tools leave the interpretation to the customer or to the end-user’s discretion. This highlights our number one challenge in beta testing, which is how to filter out pure perception from the actual and valid issues and concerns brought forward.

As most of the issues are related to user testing (split testing and front-end testing), there is no optimized single window solution that is smart enough to handle this in an effective manner. Real users in the real environment are handicapped to comprehend all the aspects of beta testing and properly react. It’s all a matter of perspective and all of them cannot be validated with real data from benchmarks or standards.

The World Quality Report in 2015-16 Edition indicated that expectations from Beta testing is changing dramatically. It hinted that the customers are looking for more product insights through a reliable way to test quality and functionality, along with the regular usability and user testing in real customer facing environment.

It’s not only the Beta Testing, but more user-demand is also impacted by the rising complexities and challenges due to accelerated changes in the technology, development, and delivery mechanisms. The 2017-18 World Quality Report states that the test environment and test data continue to be an achilles heel for QA and Testing.   The challenges with testing in agile development are also increasing. There is now a demand for automation, mobility, and ubiquity, along with smartness to be implemented in the software quality testing. Many believe that the analytics-based automation solutions would be the first step in transforming to smarter QA and smarter test automation. While this true for overall QA and testing, this is also true for Beta Testing, which deals with the functional aspect of the product.

Let’s see where we stand today. If we explore popular beta testing solutions, we will get a big vacuum in the area where we try to benchmark the user’s need for more functional aspects, along with the usability and user testing aspects. Also, you can notice in the diagram below that there is ample space to play around with the smart testing scenario with the use of cognitive, automation, and machine learning.

(Note: Above figure shows my subjective analysis of the competitive scenario.)

Basically, we lack “smartness” and proper “automation” in Beta Testing Solutions.

Apart from all these, there are some more challenges that we can notice if we start evaluating the user needs from the corresponding persona’s viewpoint. For example, even when assuming that the functional aspect is to be validated, the end-user or the customer may have an inability to recognize it. The product owner, customer, or end-user are part of the user segment who may not be aware of the nuts and bolts of the technology involved in the development of the product they are testing to sign it off. It’s like the classic example of a customer who is about to buy a second-hand car and inspects the vehicle before making the payment. In most of the cases, he is paying the money without being able to recognize “What’s inside the bonnet!”. This is the ultimate use-case that advocates to “empower the customer”.

So, how do we empower the end user or the customer? The tools should support that in a way so that the user can have his own peace of mind while validating the product. Unfortunately, many small tools which try to solve some of those little issues to empower the user are scattered (example: Google Chrome extension that helps to analyze CSS and creates the report or an on-screen ruler that the user can use to check alignment, etc.). The ground reality is that there is no single-window extension/widgets based solution available. Also, not all widgets are connected. And those which are available, not all are comprehensible to the customer/end-user as almost all of them are either developer or tester centric. They are not meant for the customer without any special skills!

When we look at the automation solutions in testing as part of much Continous Integration (CI) and Continuous Delivery (CD), they are engaged and effective in mostly “pre-beta” stage of SDLC. Also, they require specific skills to run them. With the focus on DevOps, in many cases, the CI-CD solutions are getting developed and integrated with the new age solutions looking at the rising complexities of technology stacks, languages, frameworks, etc.. But most of them are for the skilled dev or test specialists to use and execute them. And this is something that does not translate well when it comes to Beta testing where the end-user or the customer or the “real user in real environment” are involved.

Assuming we can have all these automation features enabled in BETA, it still points to another limitation in the existing solutions. It’s because the employment of automation brings in its own challenge of “information explosion”, where the end user needs to deal with the higher volume of data from automation. With so much information, the user will struggle to get a consolidated and meaningful insight of the specific product context.   So what do we need to solve these challenges? Here is my view — we need smart, connected, single window beta testing solutions with automation that can be comprehensible to the end-users in a real environment without the help of the geeks.

For sometime since a last few years, I have been exploring these aspects for the ideal beta testing solution and was working on the model and a proof of concept called “Beta Studio”, representing the ideal beta testing solution, which should have all these —  Beta-Testing that utilizes data from all stages of SDLC and PLM along with the standards + specs and user testing data to provide more meaningful insights to the customer.  Test real applications in real environments by the real users. Customer as well as end-user centric. Test soft aspects of the application — Usability, Accessibility, Cosmetic, etc..  Be smart enough to compare and analyze these soft aspects of the application against functional testing data.

Use machine-learning & cognitive to make the more meaningful recommendation and not just dump info about bugs and potential issues. Here is an indicative vision of Beta Studio:

Mostly this vision of the ideal beta testing solution touches upon all the aspects we just discussed. It also touches upon all the interaction points of the different personas; e.g. customer, end-user, developer, tester, product owner, project manager, support engineer, etc.. It should cover the entire Product Life Cycle and utilize automation along with the machine learning components such as Computer Vision (CV) and Natural Language Processing (NLP). Then gathering this information to be processed by the cognitive aspect to generate the desired insights about the product and recommendations. During this process, the system will involve data from standards and specs along with the design benchmark generated from the inputs at the design phase of the SDLC, so that meaningful insights can be generated.

In order to see this vision translated into reality, what do we need? The following diagram hints about the six steps we need to take.

  1. First we should create the design benchmark from the information at the design stage that can be used in comparing the product features against metrics based on this design benchmark.
  2. Then automate and perform manual tracking of the product during runtime in real time and then categorize and collate this data.
  3. This involves creating features to support the user feedback cycle and user testing aspects (exploratory, split testing capabilities).
  4. Collect all standards and specifications on different aspects — e.g. Web Content Accessibility Guideline (WCAG) Section 508, Web Accessibility Initiative Specs ARIA, Design Principles, W3C Compliance, JS Standards, CSS Standards & Grids, Code Optimization Metrics Error codes & Specs, Device Specific Guidelines (e.g. Apple Human Interface Guideline) etc.
  5. Build the critical components such as Computer Vision and Natural Language Processing units which would process all the data collected in all these stages and generate the desired metrics and inferences.
  6. Build the unit to generate the model to map the data and compare against the metrics.
  7. The final step is to build the cognitive unit that can compare the data and apply the correct models and metrics to carry out the filtering of the data and generate the insights which can be shared as actionable output to the end-user/customer.

While experimenting for BetaStudio, I have explored different aspects and built some bare bone POCs. For example, Specstra is a component that can help create Design benchmark from design files.

With Specstra I was trying to address the issues related to the cosmetic aspect or visual look and feel. Typically when it comes to cosmetic issues, more than 30% are non-functional and mostly cosmetic. There is no reliable solution that helps in benchmarking these kind of issues against specific standards. One third of the issues found during the beta / UAT stages of testing are mostly cosmetic and alignment issues, including category 3 and 4 types. And these happen mostly because the two persona’s involved (developer and designer) have their own boundaries defined by a mythical fine line.

When a developer is in focus, roughly 45% of them are not aware of all the design principles employed or the heuristics of UX to be employed. Similarly, half of the designers are not aware of more than half of the evolving technological solutions about design.

And in 70% of the of the projects, we do not get detailed design specs to benchmark with. Detailing out a spec for design comes with a cost and required skills. In more than two-thirds of the cases of development there is the absence of detailed design with specs. Many of the designs are not standardized and most of them do not have clear and detailed specs. Design is carried out by different tools so it is not always easy to have a centralized place where all the designs info is available for benchmarking.

Specstra comes in handy to solve this. It is an Automation POC that is more like a cloud-based Visual Design Style Guide Generator from the third party design source files. This is a case where the user would like to continue using his existing Design tools like Photoshop/Sketch or Illustrator, PDF etc..

You can view the video of the demo here:

View the demo of the BetaStudio POC here:

I understand that reaching the goal of an ideal beta testing solution might require effort and will likely evolve over time. Rest assured, the journey has started for all of us to connect and explore how to make it a reality.

Originally published at the RedHat Blog at https://developers.redhat.com/blog/2018/01/05/beta-testing-automation/