Author: Eli

Two years’ ago, while working on the online courts pilot for NSW Justice, I read “Tomorrow’s Lawyers” by Richard Susskind. Primarily targeted at those entering the legal profession (with a side-swipe at those who had been in it for a while), the gist of the book was that the legal profession is not so special that it can ignore the expectations of society upon all service providers in this day and age. Legal firms that charge exorbitant hourly rates for work that can be systematised and commoditised will miss the tide of change and face extinction.

The point in the book that I found most interesting and relevant to the UX profession was the idea that when the work is “decomposed” into a set of tasks, senior lawyers are not necessarily uniquely qualified to perform each task. The example used by Susskind was in litigation: document review, legal research, project management, litigation support, disclosure, strategy, tactics, negotiation and advocacy. When skilled litigators were asked which they felt uniquely qualified to perform, it was really only strategy, tactics, and possibly advocacy that got strong responses. Everything else could be tackled in alternate ways, such as outsourced document review services, and the use of intelligent search services.

The parallel in the UX profession is when questions arise about the differences between UX researchers and business analysts, or any other variety of skillsets in consultancies and client teams. Take a look at this sample set of tasks that a UX practitioner might undertake for a given project:

• Field research
• Workshops and interviews
• Analytics review
• Content audit
• User stories
• Taxonomy
• Information architecture
• Copywriting
• Graphic design
• Interaction design
• Prototyping
• Presenting

As a UX professional, I am not uniquely qualified to do any more than maybe two or three of those, and I’m not even convinced about that number. What I might bring is an overall mindset to advocate for the user, and a working knowledge of the psychological factors that are at play when designing services and interfaces for humans. But there are plenty of other people who are more than capable of either doing or partaking in most of those tasks. It might actually be that there is someone on the client team who is better qualified. For example, while working on that online courts project, I discovered one of the team had a psychology degree, so I was able to get help with research, usability testing and analysis.

There is no need to be dogmatic about how the work is done, or who it is done by. As long as the right tools are being used to solve problems, and there is a shared understanding between those involved, then you’re on the right track.

The following is an unedited extract from a recently submitted social psychology assignment. 

---

Elliott’s Brown Eye-Blue Eye Study, in which members of one group pre-judge those of another group, illustrates prejudice and discrimination. The study also demonstrates how easily the ultimate attribution error can be applied in a social situation, by assuming behaviours of members of a group are attributable to dispositions specific to that group, rather than to situational influences.

In software development, Agile development methodologies promote the use of collaborative, cross-functional, and self-organisation teams to deliver iterative value, rather than “big bang” delivery following gated activities by siloed teams (e.g. requirements, design, development, and testing).

The rituals between those stages are often for the purpose of handing over to the next siloed team, and are often met with misunderstanding, misinterpretation and negativity, feeding stereotypical views held between those groups. Agile reduces these rituals and resulting prejudices through cross-functional teams, which can include developers, testers, designers and business analysts.

As with the Robbers Cave Study conducted by Muzaref Sherif and his colleagues, where existing prejudices between two groups were reduced by giving them a shared higher purpose to work towards, Agile teams are able to cooperate with a shared understanding and goals, rather than those of separate practice-based groups. Similar to Elliott Aronson’s work with Jigsaw Classrooms, successful cross-functional and self-organising teams allocate their own work to complete towards stated goals, through a shared understanding of capabilities and capacity.

These measures in themselves do not guarantee a complete eradication of prejudice, however Agile also places an emphasis on frequent inspection and adaption, making problems visible to the team, so they can then be addressed by the team.

---

References

Lilienfeld, S. O., Lynn, S. J., Namy L. L., & Woolf N. J. (2013). Psychology: From inquiry to understanding (3rd Ed.). Frenchs Forest, Australia: Pearson Education.

---

Trim a word here, delete a sentence there. Generalise everything to Agile to avoid explaining Scrum and Lean concepts. It’s tremendously difficult to synthesise an idea demonstrating my understanding of the concept at hand, tied to a real life example, in around 250 words. How succinctly can you do that without losing meaning?

While getting the lay of the land in Perth recently, I attended the Perth Web Accessibility and Inclusive Design breakfast meet-up, having previously attended the equivalent event in Sydney a couple of years ago.

This particular meeting was being led by Dr Vivienne Conway, from Webkey IT. Vivienne covered a lot of ground as she talked about her work in the sector, her role and experiences with W3C, as well as some insights on recent trends and emerging issues.

evoGraphs

One of the cool developments she brought to my attention is evoGraphs, a jQuery plugin for producing screen-reader friendly graphs (pie, column, and bar charts). See the demo on YouTube:

EvoXLabs, as part of their “Project WhiteCane“, have also developed a plugin for providing multiple font options to website visitors. It’s great to see people giving up their time to make the web more accessible.

(Vivienne’s business card feature a clear adhesive braille sticker on the back. Another smart idea, and you can get your own by contacting Pia.)

Compliance or Conformance?

It was interesting to hear how governments around the world are working towards an accessible web. In Australia, and in the USA, accessibility is measured more through “compliance” statements, i.e. checklists. In the UK it is more about conformance, through real usability testing and evaluating the overall experience.

I’ve long tried to push this idea of conformance over compliance, but it is not an easy argument to win. Many organisations simply want a stamp of approval on their website, and rarely understand the ongoing work required beyond that single point-in-time. I see the idea of a website (and its component parts) being accessible as more than simply a checkbox process, but one also open to evaluation of intent and interpretation. You still need skilled individuals to make that judgement, but the four principles of WCAG 2.0 allow you to solve problems in multiple ways.

Accessibility as part of the process

I asked about opportunities or examples of accessibility experts working as part of iterative (Agile) web development teams, as opposed to accessibility testing done only at one or two key points (often very late-stage).

Webkey IT offer “partner plans”, by which their customers can buy an allocation of hours to call on. I think this is a good idea, but would like to learn more about development teams that are integrating accessibility into their sprints, and/or the team’s skillsets.

I often perform this role from an interaction design and education/advocate perspective, but I don’t have the unique qualifications that someone like Vivienne is able to offer. It is likely a combination of in-team skills, and regularly scheduled expert reviews that will provide the right balance for organisations and the users of their services.

---

It’s an early start to the day, but highly valuable insights gained. I look forward to the next one.

An addendum to my previous post, summed up nicely by Zoltan Kollin on Medium (Misused mobile UX patterns):

Don’t get me wrong: design patterns and best practices are still your friends. Keep in mind though that apps and users are different: one solution might work for well in an app and fail in yours. It’s not a one-size-fits-all thing. Plus, you never know why an app was designed in a certain way.

Do your own thinking. Do your own design. Do your own research.

And watch out for those design guidelines, because they may not be the guidelines you’re looking for.

That phenomenon of a “just-in-time” tweet, or a particular passage in the book you are currently reading that you underline the hell out of (yes, I put marks in my books).

I’ve been reading a lot of books lately that have been creating an underlying convergence of thoughts, which in conversation sometimes trips me up when I can’t recall who said what, because in my head it starts to blend and tell the same story. When you are deep in problem-solving mode, and you are able to apply the requisite amount or head space to it, your mind becomes receptive to a multitude of stimuli. That just-in-time thing didn’t magically appear when you needed it; it was there the whole time. You were just in a mindset that could receive it in a useful way.

A quick stop to highlight the books I’ve been reading lately, roughly in order:

• Designing with the Mind in Mind by Jeff Johnson
• Thinking, Fast and Slow by Daniel Kahneman
• Microinteractions by Dan Saffer
• The Black Swan (2nd Ed. with Anti-fragility essay) by Nassim Nicholas Taleb
• Service Design by Andy Polaine, et al.
• Dark Matter and Trojan Horses – A Strategic Design Vocabulary by Dan Hill
• Intuition Pumps and Other Tools for Thinking by Daniel Dennett
• and currently, The Design of Everyday Things by Don Norman (yes, I’m late to the party on this)

Last week, Don Norman and Bruce Tognazzini’s epic more-than-just-a-rant article “How Apple is Giving Design a Bad Name” triggered a convergence of underlying thought.

The article naturally polarises people, and no doubt there are rebuttals due (even-handed or otherwise). I think it would be fair to say it was so long that many didn’t actually read it to the end. And that’s a shame, because behind the almost-click-bait headline there is a very good overview of important design guidelines, informed by scientific research from the field of psychology, with specific reference to Norman’s own books, and to his tenure at Apple.

The headline suggestion is that Apple is slowly changing their own guidelines to be weighted more and more toward visual aesthetics, at the expense of established usability principles.

Why does it matter? Because what Apple does is incredibly influential, and there are many people who follow their design trends. Not just designers, but the people who buy their services. E.g. “Look at this app on my iPhone. Can we do it like that?”, or “If it’s good enough for Apple, then it’s good enough for me”. Apple’s design is pervasive, so a swerve in this direction (gradual as it may be) could be perceived as dangerous. Call me crazy, but extra light typefaces and hidden signifiers to a vast array of affordances built into impressive technology might not be the right solution for every design problem. I’m generalising, but hopefully the point is made.

Aesthetics are important, but as Norman and Tognazzini point out, aesthetics are not just the veneer; aesthetics are also the experience, and the flow, and making sure to minimise instances of your target user feeling dumb. Know your audience. Do the work to design services and interactions that prevent failure. Sure, use established patterns and conventions. Use tried and tested design tricks. But make sure you’re solving the right problems, not someone else’s. Use the appropriate validation measures and tests, e.g. prototyping, usability testing (not “user testing” – thanks Katja).

Looping back to Kahneman, and other readings in psychology, everything is multiply determined. There is never just one thing that determines why people need what they need, do what they do, or indeed how they make decisions. There isn’t even one single part of the brain solely responsible for any given thought or action. Designing for humans isn’t easy (though as Kahneman and Dennett point out, we can stand on the shoulders of those before us to learn and do the work). One single convention isn’t going to solve everyone’s problems or meet their needs. Make sure your target users, and their needs, are as well defined as possible, and design for that.

And looping back to Taleb, build robustness into your design solutions to help meet those needs, and help humans achieve the goals that your service is supposed to provide. There are known knowns, and known unknowns. You can design for these.

…and what exactly do you mean by “UI”?

This is a modified version of an internally-facing post (heavily referencing Erik Flowers’ article), which aimed to develop a common language between two groups of people. These two groups of people are not so different from each other, but words are funny and can only convey so much meaning by themselves in a given context. People bring their own meaning to the table.

The process of writing it down helped me better understand the problem, and as a result better at explaining my take on what UX is, what a UX designer does, and what value it contributes to “the work” we do. (At the very least, it should foster a discussion that gets us closer).

In doing so, it’s useful to first see what we (the Folk I work with) mean when we say “UI”.

“UI is what people see and touch.”

User interface design … is the crossover between visual design (look and feel) and the interaction design (how the look and feel work). Combine those two and you have an interface. The interface is the result of the “solution design” that came before it.

The user interface is typically implemented (built) by a front-end developer (with CSS, JS, etc.).

What do we mean by “UX”?

“UX is the intangible design of a strategy that brings us to a solution”

UX is a label that is often used, but not fully understood. This applies both to those in the industry, and those outside. Often (not always) what people mean when talking about UX is:

‘We just want it to look nice’.

User Experience Designers don’t design things “in the same sense as a visual or interface designer”. (Can you actually “design” an experience?) UX works to identify and satisfy “the specific goals of well-defined users”, and how they interact with a system through a user interface. It’s not just the look and feel.

UX can be seen as an ‘umbrella framework’ for solving problems, which decomposes into other practice areas and activities:

Decomposed further:

However, “doing” UX doesn’t require doing all these activities all the time. Some of these decomposed activities can be done by others (who may be more uniquely qualified), and some are not needed at all for a given problem.

Another classic diagram:

Not every UX practitioner is “full stack”. Who does the work depends on the people involved, e.g. user research specialists, interaction designers, web designers, developers, etc.

The order in which these things are done depends on the type of project/engagement, e.g. linear, lean UX, variations on the above, etc.

How successful the work is depends on many things too numerous and detailed to cover here, needless to say communication plays a big part.