Category: design

Let us talk shop!

Design with your engineers for a better product, a happier team, and stronger results💫

Posted  ●  4 min read

Inclusivity is something that designers like to bang on about. A lot. However, few of us take the opportunity to actually do the work to be inclusive. Let’s take a small step on the path to inclusion and let go of our egos, include engineers in design and discovery, and make better products for our users faster.

Share your lego and work the problems as an inclusive design team

Designers are skilled problem solvers who come at things from the perspective of the user who is going to endure the problem. But, guess who else is good at problem solving? The engineers who build the product. And, guess what? The engineers know the construction materials better than the designers, by the fact that it is their job to know these things better.

“If you’re just using your engineers to code, you’re only getting about half their value.”

Inspired
by Marty Cagan

Inclusion in the real world

Imagine if UX was a more grown up profession for a moment, and consider the real world analogy of an architect who designs a building. In addition to building regulations and planning, a good architect will consult directly with the builders to decide the shape that the building takes and will listen to feedback. It’s a bad architect who doesn’t listen to the people who construct the house and make sensible compromises based on cost, function, whatever.

However, this is exactly what happens when a designer hands off a prototype, calls it done, and leaves the engineers to figure out the implementation details. At which point, the actual design is in the hands of the developers.

The rise of Ego Centred Design

I’m tired of hearing about UX education from designers being used as a shield when things go wrong. The conversation around levelling up UX by teaching our coworkers is worth having. However, far too often this as a one way street for the designer to blab on about empathy or something so foundational it hurts. It is defensive more than productive.

Should designers code?

I don’t care what people do for a hobby. I like to read fiction. Should designers? Actually, they might be better at empathising with others if they did. Do what you want.

Should we be familiar with the platforms we’re designing for?

You bet we should. Knowing the capabilities, behaviours, and limitations of web browsers has often informed the work I do. To tell a developer how to execute designs and not consider the materials is irresponsible. I used to struggle with designers handing over work to me back when I was a front end designer. Often the designer didn’t understand how browsers work and the designs were incomplete and at times unbuildable, inefficient, and frankly outside the budget I’d been given to do the work. Consequentially, I personally have asked for impossible things too as a designer so I’m guilty of stepping in shit too.

Why should we include business people and engineers? They don’t understand UX

Who’s fault is that? If you can’t communicate this in terms they understand or appreciate it’s on you. Saying that, maybe you work somewhere that doesn’t give a shit. But if you take home a healthy pay check every month from your work, they are at least invested financially in UX. Lot’s of places do, what’s known as, UX theatre as pointed out by folks like Brenda Laurel or Tanya Snook, AKA Spydergrrl. Conversely, there’s lots of stuff many designers, myself included, don’t know about business so let’s not play this game.

Include the mission

Obviously, education is a noble goal, but if we give people a mission they can get behind us. We are likely to educate and learn along the way. A mission is inspiring and a way of framing questions that is effective to capture hearts and minds. This example from Creative Confidence shows the power of reframing a question to inspire others to action:

Considering the future of Cisco’s high end Telepresence system, for example, Cisco CEO John Chambers reframed the obvious question, “How can we improve videoconferencing?” as “How can we provide a viable alternative to air travel?”

Creative Confidence
Unleasing the creative potential within us all
by Tom Kelley & David Kelley

Chiefly, we need to show others why something is important, how changing a situation could improve the life of a user, and allow them to provide their input into the solution. As soon as you do this, you open up the opportunities for different solutions, from people without the word designer in their title. Crucially, this brings more diverse discussion on the problem, as well as engaging the team in owning the problem. Work tends to ship faster this way than it does when you just feed the beast.

How can you include engineers in design and discovery?

Here are a few things that work for me. I’m not suggesting you turn into a commune, end up with a committee, or endless layers of bureaucracy. Basically, I’m advocating that you bring engineers, and others without design in their titles, into the fold on the work you are doing where appropriate.

  1. Get them to observe and participate in the research. Active participation requires note taking, and synthesis. In addition, If you are conducting interviews or usability tests, bring them in to watch, capture quotes, and synthesise the findings. Consequently, I’ve yet to meet an engineer who isn’t interested in how people use the things they built.
  2. Come up with problem statements, needs, and hunches together based on the research they just took part in. By and large, I like the lean UX canvas by Jeff Gothelf. It seeks to invalidate hunches fast and includes both business and user needs.
  3. Rinse and repeat. Share widely what you’ve learned. I use loom a lot at work to communicate async. It’s a godsend.

So get the most out of your engineers by bringing them into the UX process, dialling back your ego, and sharing power with your team. You won’t regret it and you will get to ”educate” those business folk all about UX. At the same time you will learn more about your team, strengthen relationships, and deliver better products faster than any godforsaken handoff doco.

Goldfish software. You’ve asked me this before

Posted  ●  3 min read

In this post, I am going to talk about an issue which gets overlooked often in tech. Specifically, products or services that ask information they have already. For want of a better metaphor, let’s call this “goldfish software”.

Banks and insurance providers are great at behaving like goldfish. In addition, the large tech companies don’t do much better here. For example, my former employer, Workday makes you fill out a lengthy form every time you apply for a job on their platform. As you can imagine, their users love to repeat themselves with lengthy forms full of redundancy.

I’m sure there are dozens of people out there who get their kicks as unpaid data clerks for large tech companies. Personally, I don’t want to spend time at a party with them, but surely they exist somewhere.

Why does software act like a goldfish?

I’ll level with you. I don’t really care why software behaves like a goldfish. However, I am interested in the ways to address this issue. Oh, and yes fellow pedants, goldfish have actually got good memories but we are this deep in so let’s stick with this stretchy metaphor.

It is understandable that things are the way they are. Large companies and legacy organisations have a lot of dependencies, tech debt, other priorities, and pressure to deliver new stuff and feed the beast. Meanwhile, it’s difficult to justify fixing things that technically work and often you need to pick your battles. That said, we ought to be better at eliminating redundancy.

Provide context when and where you can

It’s often not difficult to understand what our users are trying to achieve if we take a moment to think about it. That is to say, all it takes is for us to put ourselves into someone else’s shoes is a little imagination. Instead of focusing on the “happy path”, we need to design for where things go wrong. This is a mistake that erodes trust and pisses people off.

A real world potential goldfish

Recently, we added the capability to handle join requests in CYGNVS as part of a security measure to prevent unauthorised access. This is an approval step where admins can review new users before they get access to the platform. The requirements were fairly simple with either approve or reject sending emails to the applicant. The happy path includes a link to get in, and the unhappy path was to include a way to contact support.

Meet and go beyond software requirements

Consider the following statement sent as an email:

Your join request was declined, please contact support at support@product.com.

This meets the base level requirements. But, it kinda sucks.

  1. I don’t know who declined my join request
  2. I‘ve no clue as to why
  3. I can contact support which is nice, but what do I need to include in the email to avoid going back and forth playing email tennis

Comparatively, let’s take this example:

Joe Bloggs (jbloggs@work.com) declined your join request to Product X’s account. “Hi Eoghan, your application was denied for some compelling reason.”

Contact support

  1. I now know Joe Bloggs has rejected me. How could you Joey!?
  2. I have additional context. I know what (Product X), and why (compelling reason)
  3. Contact support uses a mailto link to write the email for me. Yay! I don’t have to write.

Respect users and don’t goldfish them with software

This second example is pretty low cost to implement. Mail to links are as old as the hills, and work great when used in emails. Admittedly, they can behave a bit weird on web, but being able to pass parameters in is pretty magic feeling and not often done. However, I’d recommend some caution here as you are literally putting words in peoples mouths. Chris Coyier has some good advice on this.

Importantly you treat a user who’s been declined with respect and your tool does not behave like a goldfish. As a result you give support the information it needs to act on the request, and save them hunting for information from the person who is getting in contact. This makes them look good, and speeds things up for everyone. Win, win.

Useful links. Well… links at least

Don’t make me (not) think. Responsible design

Posted  ●  4 min read

Steve Krug’s famous call for clarity is sensible and easy to understand. His book Don’t make me think deserves its place as a design classic. As a primer it is useful to understanding how other people think. Touching on how cognitive barriers can prevent users from achieving their goals. Don’t make me think suggests a path towards reducing friction. Adopting it blindly as a rule is dangerous.

A lens on the past.

This book came out in 2000. Back then, computers were unfamiliar alien objects with impenetrable interfaces. The internet was niche, and often little regard was given to the actual experience. The space jam website from 1996 is a beautiful artifact that shows how things were at the time. Don’t make me think was a needed clarion call to making digital things more usable.

How we think.

Humans are surprising, and diverse of thought. Technically savvy people think in a way that is frequently far removed from the rest of societies expectations. To massively generalise, engineers understand processes, logic, and think in systems . Regular Humans have systems too. They just don’t follow the implementation models of software. Designs role is to make systems behave how the people using them expect them to work.

The conceptual model.

This isn’t the same as how things actually work. It’s a subtle and important distinction. A good real-world example can be found in your kitchen. If you ever set your oven to a high temperature to get it hotter faster you have (probably) fallen into a trap. Most ovens, like thermostats, heat at the same rate. It’s a reasonable misunderstanding. The conceptual model you hold of how you think something works doesn’t line up with the reality of how it actually works.

There are times when you can be right in understanding the concept of how something works in one situation, but wrong in a virtually identical situation.

Take music as an example. Playing a song from your phone connected to a speaker with Bluetooth is different than playing over wifi. Bluetooth acts like an invisible wire that tethers the phone to the speaker. Playing a song over wifi cuts this tether and effectively reduces the phone to remote control.

When is it okay to trick and deceive people?

These deceptions exist in lots of software. To give the impression of speed, Apple show a screenshot of the users desktop when they power on their computers. Likewise, Twitter “works” when you are offline.

Picture of a magician turning the words interaction designer into distraction engineer
Interaction Designer is an anagram of distraction engineer. Illusionist image by sobinsergey

Don’t believe me? Try it this yourself. Go into airplane mode and like some tweets. It will work without an internet connection. A way nicer way of handling things than popping up an error. As a result, the action is only applied when you go back online but that doesn’t matter. Twitter assumes success, and handles failure.

Feeling fast. Speed as deception.

There is a reason why you walk so far to collect your bags when you get off an airplane. This walk is designed to occupy you while they unload the plane. People hate waiting. Perceived efficiency is often as good as, if not better than, actual efficiency.

Make it easy to use.

This seems a noble goal. That said, there are times when cognitive ease is bad and friction is good. Sometimes you want to engage what Daniel Kahneman and Amos Tversky called System 2. In essence, thought is divided into the 2 systems. System 1 is automatic and quick. System 2 is slow and deliberate.

Forming design.

Seemingly small design decisions like the positioning of labels with input fields can serve to slow down or speed up people when they are entering information on forms. Using a single checkbox for decisions puts the burden on the person to understand what the impact is. This is utilised as a dark pattern to manipulate and trick. A simple cheap solution exists in the form of radio buttons which spell out the decisions without requiring cognitive leaps.

As an aside, if you want to learn more, read the book that Michael Lewis wrote instead of Kahnemans. It’s far more fun and way less academic than Thinking fast and slow. Personally, I’ll take a love story over a science journal any day.

Rules of engagement.

The Privacy by Design guidelines by Ann Cavoukian are an interesting and often cited source worth mentioning. There is criticism that the guidelines are vague, favour corporations, and are difficult to adopt/enforce. This is probably valid, but a little harsh. Personally, I see the guides as a decent framework that can serve to discuss values. The European General Data Protection Regulation (EU GDPR) incorporates these guides.

Privacy by Design.

  1. Proactive not reactive; preventive not remedial
  2. Privacy as the default setting
  3. Privacy embedded into design
  4. Full functionality – positive-sum, not zero-sum
  5. End-to-end security – full lifecycle protection
  6. Visibility and transparency – keep it open
  7. Respect for user privacy – keep it user-centric

Brave new world.

As a tool these guides can help to ensure the impact on people is considered upfront. It can at least facilitate the conversation. Like Neil Postman predicted, we are all amusing ourselves to death. So, we’ve given up our privacy and let companies look deep into our lives. More than we probably should.

It is absurd to say we understand what we are giving up. Companies claim we are willing participants, but that is clearly a deception. Honestly though, do you really trust Jeff Bezos?

Your rules and my rules are likely different. We are all moral creatures. As such, you are welcome to disagree with me, and I often contradict myself or otherwise fail to live up to the standards I set. But it is worth considering your impact on society.

Price of success.

I am in a very privileged position in that I can determine the kind of place I work, and the type work I do. I have worked on things in the past that I wasn’t proud of. Honestly, when I was starting out I didn’t give enough thought to the actual impact of the work I was doing.

Personally, I don’t really want to work on addictive software that nudges people towards compulsion, depression, and isolation. I mean, I wasn’t designing bombs, but I did work on some questionable products that treated people as means. It’s all very well to moralise on this now that I can afford to, but as I have gotten older I am more interested in this stuff.

Destructive innovation is the term for things that get destroyed by progress, and is seen as the cost of doing business. Amazon killed bookshops and ironically brought them back in 2018. We don’t consider the bad side of what could happen if we are successful when designing products.

Sometimes make me think.

Cennydd Bowles has written an incredible book called Future Ethics. Watch Cennydd speak over on ethical.net. He makes a more compelling case than I can for when it is important to make people think. The book is essential reading for anyone interested in Ethics. It is not preachy in the slightest, and cleverly frames ethics as a constraint. Designers love and understand constraints.

In the book he contradicts the idea of data transparency. The case instead is for making data more material and visible. If we could see information flow, we would be better informed on the exchanges we were making with people our data. He also keenly articulates the need to widen the net when considering stakeholders in our design. AirBnB serves as an example of something that is well designed for two specific groups (the host and the guest) but bad for the local community. Dublin has felt the downside of AirBnb immensely.