Infographic: The Full-Stack Roles in DesOps

 

©2018,”The Full-stack Roles in DesOps” by Samir Dash.
Creative Commons Attribution-Share Alike 4.0 International License.

Download PDF from https://www.slideshare.net/MobileWish/infographic-the-fullstack-roles-in-desops-desopsio

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).

Infographic: The Ten Practices of DesOps (aka. DesignOps)

 

Download the PDF version here: https://www.slideshare.net/MobileWish/the-ten-practices-of-desops-aka-designops

©2018,”The Ten Commandments of DesOps” by Samir Dash.
Creative Commons Attribution-Share Alike 4.0 International License

Infographic: The Ten Commandments of DesOps

 

Download the PDF version here: https://www.slideshare.net/MobileWish/the-ten-commandments-of-desops

©2018,”The Ten Commandments of DesOps” by Samir Dash.
Creative Commons Attribution-Share Alike 4.0 International License

The “When/If – Then” Tool to Capture Hypothesis


(This article was originally published onApril 29, 2018 Linkedin Blog at https://www.linkedin.com/pulse/desops-next-wave-design-part-10-whenif-tool-capture-samir-dash/


As I mentioned in the previous article, the assumptions or the hypothesis can be made as a formalized statement of “if …. then” or “when … then” kind of format. To use ensure that this is captured correctly during collaborative sessions and within the design team, I have been using the same and some variation of the same format as a tool which I call “When/If – Then” Tool. This is a simple tool that can be very effective during collaborative sessions, to capture the assumptions that form the basis of why we believe that how the certain aspect of user pain-points and user needs should be translated into solutions using specific aspects.

Basically, this tool was helpful than the traditional elaborative templates to capture assumptions, as it was straightforward and can be used with a minimal explanation to a cross-functional crowd, a large portion of such population may not be accustomed towards the use the typical Tools and methodologies. The “When/If – Then” Tool is synonymous with the typical cause-and-effect kind of flow that is understood by and large and required very minimal explanation, and can be like any other UCD tools, can be constructed using simple post-its or printed formats.

Here is a post-it version of a barebone “When/If – Then” Tool:

Following is the basic format of this tool that has primarily 3 boxes — the left hand spanning column represents the persona or the target user (even segment given a larger scope from the market perspective) whereas the right-hand side boxes represent “When” or “If” part of the assumption and the lower box “Then” forms the outcome aspect of the assumption or hypothesis.

You can download a printable PDF of the template at http://desops.io/2018/05/07/when-if-then-tool-printable-version-for-a4-size-paper/

Basically, the above template helps you in completing an activity to frame your Hypothesis statement that are key to the the whole hypothesis-driven design (HDD) methodology. Now it is important that this tool can be applied to two-part blocks that can be used seeing as what you assumed versus what outcome have you got throughout experimentation.

A friend of mine asked me a valid question that it is fair to assume that HDD based approach as informs the assumption as a part of the course correction, whether it would replace the research from the process? My view on this is that the research (in the traditional definition like user and market research etc. ) has a key role in the process, as it is a mechanism to inform the stakeholder to create a vision. Technically a vision, itself is a set of hypotheses formulated by the stakeholder or the product manager. So it has a unique role in the process at the beginning of each cycle of the iterative process (let’s say to contribute to new requirements that flows down from the vision) and will stay. However, the hypothesis-driven design (HDD) helps in making a formalized approach and adds a mechanism to ensure the feedback-loop that informs these research or chunks-of-research that happens along the way in a structured and non-ambiguous way that enriches the research involving the additional validation process with evidence. Which acts as a catalyst to improve the efficiency of the research in a positive way. So essentially research is happening organically throughout the process in an on-going manner.

In the next article of the series, I will continue the exploration on the same topics. Keep in touch.

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

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

 

 

User-Centered Systems Design (UCSD)


(Originally first published on July 2, 2014 at https://www.linkedin.com/pulse/20140702065559-9377042-user-centered-systems-design-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/


User-Centered Systems Design (UCSD) 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, tasks and 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: The UCSD process must be specified, adapted and implemented locally in each 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 the project 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 Design Activities: 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”.

—–

(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

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/

 

“When/If – Then” Tool : Printable Version ( A4 Size Paper)

This “When/If – Then” tool helps to formalize hypothesis or assumption for any Hypothesis -Driven Design or Development.

This tool is helpful than the traditional elaborative templates to capture assumptions, as it was straightforward and can be used with a minimal explanation to a cross-functional crowd, a large portion of such population may not be accustomed towards the use the typical Tools and methodologies. The “When/If – Then” Tool is synonymous with the typical cause-and-effect kind of flow that is understood by and large and required very minimal explanation, and can be like any other UCD tools, can be constructed using simple post-its or printed formats.

Feel free to download and use.

Licence:

(c) 2018, “When/If – Then” Tool by Samir Dash

Creative Commons Attribution-Share Alike 4.0 International License