Thinking outside the box: the difference between constraints and perceptions

You need an app.

The constraint is that it has to be accessible.
The perception is that it has to be screen reader friendly.

But… That excludes deaf people who miss the audio cues in the app
… That misses the option to add voice control. If it’s a booking app, why not talk through the booking?

---

The constraint is that users need to be notified (it’s a legal requirement)
The perception is that only one channel is acceptable (must be post, must be a tracked email)

But… each user has their own preference, or accessibility baseline. Post only may help, or hinder, victims of abuse. I can’t guarantee that you’ve read a letter, but I can guarantee you’ve hit the “I read this” button.

---

The constraint is that you need to mark and control personal and sensitive data because of GDPR, and you need informed consent to do that

The perception is that making users click “I agree” is informed consent
The perception is that gaining consent absolves you of responsibility to mark and control personal data “because they agreed to our terms and conditions”
The perception is that location data isn’t sensitive, even though Google knows your home and work address, and the address of the abortion clinic, the LGBT nightclub, the local mosque, the local love hotel

In the beginning… was the conversation

The history of computing has been an evolution of conversation between us and machines. Single-purpose machines were built to be talked about, not communicated with. Even a hoax like the mechanical Turk.

But then the punched cards of the loom and Ada Lovelace’s ideas of a general-purpose computer started to become real, and we needed a language. At first, it was a language based on mathematics, the language of log tables, the language of angles, and then the language of letter frequencies. But soon we got more advanced, we got to the language of logic. Decision making, and computers, were open to working on anything.

And that’s where software engineers, programmers and developers enter the story. The medium of communication between the world of humans and the world of logic (because there has been no greater fallacy in human endeavour than to assume there is a complete overlap between the two, despite how many Nobel prize winners in economics have tried to prove otherwise).

The story of computers since then has been the story of building layers upon layers on top of machine logic to bring machines closer to humans. The command line, high-level languages (when C was considered a high-level language), graphical user interfaces, and the emerging field of voice and text conversation epitomised by Alexa and but Google and Facebook bots, but also the first line at the call centre, the first responder on live chat.

There has always been a conversation, and there’s always been a mismatch between our words and our intent.

As developers, our job is to derive intent from those words and the actions. Traditionally, offline in workshops and focus groups, but increasingly in real-time, teaching the machines to understand users and adapting conversions, websites, and apps, as we detect errors and confusion, as our data tells us users are unable to complete their goals.

There has always been a conversation. But this new conversation is with the users, and the machines, and the stakeholders, in real-time. With incomplete and biased data.

Be forgiving in your conversations. No one knows what this global conversation is like. But we know from social media and the news that not everyone in the conservation is pursuing truth and simplicity. But that is the only logical route, and behind all the facades is whatever truth you’ve built into the system. Are they the truths you can stand behind? Are those the truths that help and empower people?

Communicate your truths clearly and without favour, because this conversation is never pure or simple, and we have unearned power to control and shape that conversation. I don’t know if anyone would have chosen to give power to the developers and make us responsible for the truth, but in an information economy, that’s where we are. All these conversations are our conversations.

Tech is not neutral.

Speak your truth and recognise your responsibility.

Further reading

Neal Stephenson – in the beginning… was the command line

Conversation is the command line of tomorrow

Blank spaces : how to deal with nothing in API design

Consider the following HTTP endpoint:

GET /{user}/appointments

How do we deal with nothing?

Nothingman

🚫 If the user doesn’t currently exist, return 404 – this informs the caller that nothing can be done with this resource until it is created or recreated.

🙈 If the user exists, but we want to protect against username enumeration, return 404 – this removes a route for malicious agents to identify actual users, perhaps prior to a password brute force. They may decide this endpoint is less likely to have the full protections afforded to the login endpoint. This endpoint should also avoid indirect enumeration, for example returning immediately for “user doesn’t exist” and delayed for “user exists but we’re pretending because security”

🔒 If the user exists but the caller doesn’t have permission to see their appointments, return 403 – caller will have to login, or ask someone who has access.

Empty time

Given the selected user exists

🔐 If this user does not support appointments, return 404 – these resources can’t be found.

🗓 If this user does support appointments, but there are none, return an empty list.

note : some APIs will return 204 No Content in this scenario. 204 should only be used for POST or PUT requests to indicate server action was a success, and there’s no data to send back

Empty space

Given the selected user exists
And they have at least 1 valid appointment (see business for what “valid” means)

📺 If the appointment has no location (because online conference links are saved elsewhere in the appointment body) then no location property should be returned

❔ If the appointment has no location (because it is unknown) then the location property should be returned with no data (the empty string)

The Dark Mode of usability and accessibility

I saw an interesting thread by Laurie Voss where he takes issue with the universal shift to Dark Mode across apps and platforms as an option. I’m sure it’s mainly a weary jest about all the effort to make something not for him. (After all, I’ve heard similar takes from white men about why bother spending time and money catering for women or people of colour).

This tweet stood out though and me think about how I conceptualise usability and accessibility :

I have extremely poor night vision (halos and starbursts around anything bright) so dark mode makes any interface that is primarily white on black unusable to me. So Dark Mode is "totally useless mode" for me.

— Laurie Voss (@seldo) April 15, 2019

‘Dark Mode is “totally useless mode” for me.’

I like dark mode for many reasons, there’s a small nostalgia element, but I do get big problems with eye strain. I started programming when we didn’t hook computers up to monitors, we used TVs, and sitting arms length from a bright flickering CRT is no good for anyone’s eyes. Modern LCD and OLED screens are much better (and I particularly like how well my Sony phone handles direct sunlight), but even then, I can get sore eyes and headaches looking at something too bright for too long. Dark mode allows me to use a screen longer without losing contrast. Although I am now more wary of wrist strain.

That’s how I often think of interfaces, as something which makes things easier. Something that reduces strain. And I sometimes forget that the point of accessibility cues is to make things possible. It’s not so I can stare at the screen for longer, it’s so that Laurie Voss has a screen where he can see the words.

So yes, I tag my images in Twitter. I use colour schemes with high contrast. I use structured HTML that ties inputs to their labels so that the accessibility tools have the best possible chance of doing their job.

So today, take a step back and think about what would make it impossible for a potential user to access what you’re building. Be that user. What do you need to add for them? If you’re not sure, enable the screen reader on your device and turn the screen over or off. Grab a screenshot and add a color-blindness filter. Fill out a form by voice, or use your onscreen keyboard to simulate a switch input.

How are you going to walk your software in someone else’s shoes today?

Work hard to make things simple

Bowling Alley

“Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage to move in the opposite direction.” ERNST F. SCHUMACHER

"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage to move in the opposite direction." ERNST F. SCHUMACHER

— Quite Interesting (@qikipedia) January 8, 2018

It’s easy to write software. Ask users what they want (or even better, observe them and discover their problems), find a clean, user-friendly solution, build it and deliver it, for free, with no ads.

And you make a success of it, so you add more features to see off the competition, or to disrupt a new market. Google built Gmail, then added automatic categories, and Smart Replies to make it easier to process your messages. And they also added Wave, Buzz, Google+, Talk and others, to demonstrate other ways to connect and communicate, for places where email doesn’t work so well. So many new features, new things to learn, spinning out from that new core.

And yet Gmail remains popular, the rest, not so much.

It’s easy to add features. With a bit of work, you can even add them seamlessly without adding another menu option that your users will never see.

But what’s your plan to remove options, to streamline your code? How do add a new feature that’s easily discoverable and useful? How can you be smart and subtle?

What is your simplification strategy?

User Experience : A quick introduction for developers

The following is an internal summary I wrote for a team that no longer exists, summarising a number of references from UXScotland, various book and blog posts. It extends the thoughts from my Pecha Kucha talk. For more details, please refer to the links throughout and the references at the bottom. The context here is consulting and long-term B2B projects, but some of these discussions are more widely relevant.

User Experience : Project considerations

User experience is about making sure we are solving the right problems in the right way. It is the intersection of design, users, and context. Context here is a combination of one or more of the device in use, the user’s location, any social cues such as nearby friends, and anything else that may be available from sensors or historical information.

In many cases, the requirements we have are assumptions (e.g. what users want is Facebook integration). Where the benefits of a requirement are unclear, we should treat it as an assumption to be tested. Embrace data, and analyse it.

At the requirements stage, we need to make sure we are solving the right problem (pretotyping : “building the right *it*”), and that our chosen design helps the user to solve the problem without frustration (i.e. prototyping the design, rather than the implementation, with wireframes/sketches).

In user testing, particularly in an agile development, we can refine those ideas by seeing how well the implementation solves the problem, by testing with users. We can also test deployed code by analysing heat maps and http logs to see what users are doing to inform further tests and the assumptions that feed into further design cycles.

In a Lean/Agile project, we need to be explicit about our assumptions about the user and test them at every stage of the development to ensure that we always meet user needs.

How does UX fit in our process?

Stakeholders

A system that supports user’s need effectively will need to understand that the user is a Stakeholder in the process. Whilst the users themselves may not be directly involved in the generation or review of design artefacts, there should be a user representative, either a super-user on the customer side, or a 3rd party researcher who has determined user needs, and has authority to verify any proposed solution and high-level requirements against those needs.

Functional Requirements

Personas / Typical Users

A persona is an abstraction of a system user. In a simple system, there may be only one type of user, but more sophisticated systems will typically have users and administrators, and may have multiple classes of each. A persona is defined to encapsulate the types of tasks a specific user may wish to perform, and any limitations that may be imposed (for example, administrators may be able to install specific browsers or client software, but members of the public using the system must be supported across multiple browsers at multiple screen sizes).

User Journeys

Each persona will have one or more tasks they wish to perform in the system. A User Journey describes the tasks as a series of steps that a specific persona will follow in order to achieve that task.

Consider the tasks that a user wants to perform. See also BDD – design from user in.

E.g.

User wants to process a case:

• User logs in to the system
• User selects case from their task list
• User reviews latest document
• User finds agent for case, and calls to discuss
• User adds comments to case
• User saves case and returns to their task list

This process may identify a new use case (“Display task list”), and specific actions that need to be defined within a use case (“Display latest document” and “Display agent contact details”)

The User Journeys provide the context between the Stakeholders (and User Types therein) and the Use Cases. Each User Journey will link to one or more Use Cases, but some Use Cases may not have an associated User Journey (nightly payment processing, for example).

User feedback

If the solution is replacing or improving an existing system, the best source of information on the current system are the users. The requirements capture process should take into account both the tasks that the users perform and gather feedback on any areas of frustration. The prioritization exercise should consider these improvements as well as new functionality.

Testing

As well as testing the Use Cases for functional acceptance, the FAT/UAT process should also test that the final system supports the User Journeys defined up front.

On-going support

Where projects have regular support meetings, the input of users has been valuable in identifying problems areas and possible changes. When on-going service delivery contracts are defined, SDMs should consider whether ongoing user feedback is appropriate as part of the planning and scoping of releases within that framework.

Questions to ask

• Have the requirements been tested on users? If not, why not? (Are these the right requirements?)
• Will users be given the opportunity to provide feedback on these through the development? (And if so, how, when and where?)
• What user outcomes are we trying to achieve with the release? These may not be requirements that we put a cost on, but an expectation that we can measure against to show improvement – we would need to communicate this appropriately.
  • E.g. minimise clicks to access the 5 main functions
  • E.g. reduce time-to-complete for function x, y and z by 10%
  • E.g. Align existing UI with iOS and Android norms
  • E.g. Increase usage of function z by 5%
  • E.g. 99% AAA compliance
• Who represents users on the project team?
  • How many user types do we need?
  • Can normal users and administrators share UX, or are their goals divergent? – different apps, different ASP Areas, different branding, …
• What platforms and form factors need to be supported/tested?
  • Does each platform need a native UX? If native app, probably yes, if web app, maybe.
  • If mobile, do we need to adapt to context : location/orientation/communication with nearby devices/…
  • If social, do we need to adapt to context : can I approve my own work?/who’s online/recommendations/who’s nearby/…
• Do we, as developers, have any input to the UI design? If not, why not?
• Have the designs been tested on users? If not, why not? (Does the UI fit user expectations?)
• Do we have appropriate guidelines for the appropriate platform, and are they listed in the requirements and estimates?
  • iOS : Mobile Human Interface Guidelines
  • Android : Design principles
  • Windows

Potentially useful resources

 

• Lean UX by Jeff Gothelf and Josh Seiden
• Steve Krug presentation : Usability – One more thing you don’t have time for
  • Also check out his books, including Don’t make me think
• UX Scotland
• UX Professionals communities
• UXPA-Scotland (mainly Edinburgh)
• Government Digital Service (Agile, UX and a few other real-world discussions)
• A List Apart
• .net magazine
• Ask Tog
• HTML5 Rocks
• Color Me Impressed: 3 Tools For Effortlessly Finding Beautiful Color Schemes For Any Project

De-pluralisation: strategic blinkers

The process of de-pluralisation takes all your existing problems and combines them into one simple manageable problem: “it’s JavaScript”, “it’s Windows”, “it’s the CDO” with a simple manageable solution “kill it”. Like all simple solutions it’s almost always wrong.

“People aren’t complying with our data quality. Users keep putting in wrong email addresses.”

“The new computer system will fix that”

“Users complain that there’s too many steps to sign off expenses”

“Each step will be faster in the new computer system”

“Staff have low job satisfaction”

“New computer system!”

“Our users aren’t interested in that new feature”

“New computer system!”

“We’ve been hacked with a social engineering attack”

“NEW COMPUTER SYSTEM!”

Changing one thing is rarely the answer. There are many pain points and problems we all face day to day. It’s tempting to try and fix them all together, but unless you understand why the problem exists and what the parameters are to fix that problem, you can’t fix it.

Sometimes New Computer System (TM) will fix multiple problems, if they’ve been defined and the system has been designed to do so. But don’t expect it to fix everything because it’s new. That’s how to make people disenchanted.

If you think one system will rule them all, you may as well throw your team in the fire now before you waste time and money on a misguided transformation.

Little UX wins #littlejoys

I’m no expert in user experience. So I’ll let others talk about the personas, the end to end journey and bringing joy. I want to talk about the details.

Those papercuts that slice away at you, that just make things a bit more work. The things that spending 15 minutes watching users makes you scream at yourself for putting your users through it.

But it doesn’t just affect technology. Here’s a list of papercuts I’ve noticed, either because one company has fixed them, highlighting the pain that everyone else puts you through, or because they annoy me. Reflect on your experiences as a user. What delights you and annoys you?

Things I like

• Waitrose Meat in foil trays store the sachet in the cardboard cover, outside the foil tray, so no meat juice on them. This is a great example of separating concerns so that the raw, unsafe meat never comes in contact with the sauce until it has been cooked to make it safe.
• Double tap to wake. The on button on many phones is small, and often hard to reach when on the table. Phones that allow a full screen action to wake take advantage of Fitts Law and their large screens to make that common action much quicker.
• Lenovo N22 carrying handle. Many people carry their laptops without a bag. When you have a cheap, light, knockabout laptop, embrace it, and give it a handle. Bonus: teachers can carry many at once.
• There’s also a bundle of wonderful examples here: UX out of electronic spaces http://uxpa.org/upasiteredirect/index.html/uxmagazine/lets-get-physical/?utm_content=bufferea7eb&utm_source=buffer&utm_medium=twitter&utm_campaign=Buffer

Less good

• In my house, there are some lockable windows and some button operated (for fire safety upstairs)). On the button windows, you push and then turn. On the lockable ones, you turn the key to release the button, then turn. Every time, I push the button to open those windows, see the locked window depressed and think it’s unlocked. Every. Bloody. Time.
• Something that needs better feedback rather than relying on transferable knowledge that many people are bad at : estimating size. Why does no microwave rice have a visual indicator of 2cm for the tear? So many packets have “tear here” and printed perforation. Why not “stop here”?

What papercuts have you seen, and what user experience interactions give you joy?

Always be finished

I’ve been living on a building site for a while, at home and at work. The work at the office above ours was ambitious, chaotic, noisy, messy and overran. It was a challenging project, turning a “derilict” into a funky new office.

Home was a simpler proposition, a greenfield site, with a well tuned team putting up a batch of similar houses. Each house in the project was a clear finishing point. The work was completed on or near budget, although there have been many bugs in the finished product. Nothing to break the deal, but enough to be annoying, and a few that need serious attention before things get worse.

The most interesting thing for me however was complete the overall project looks. At each stage the customer perception is paramount, so roads and car parks are built and finished in places where in a few months they’ll be ripped up to put houses on because that’s the most central place to put the marketing suite so customers can see their house quicker.

And the perfectly manicured lawns at the show home will be ripped up to build a driveway for the garage. And the landscaped street gables get cut back to move the marketing suite. But at each stage there’s a clear “here’s what’s being built” and “here’s the rest” even when what looks complete is not the final vision.

The perception even extends to certain rules for residents to ensure consistent façades and a complete presentation, with no unsightly trade vans, for the entire site until the last one is sold.

When you build software, how finished do the “temporary” solutions look to the customer and the developers. Do they look hacked on, unreliable and in desperate need of a bug fix, or do they look finished and smooth to the end user, with a few backlog tickets describing what it really should do. No hint to users or competitors that something is about to change.

It’s not enough for everything you release to be complete and tested. If users can see the cracks, it will colour their impressions. Fix the snags and delight your users.

Non-functional requirements and terrific testers

There’s a ongoing debate about non-functional requirements: Non-Functional Requirements Are Not Nonsense and it’s a debate I’ve had within my teams as well.

In most consulting projects I’ve seen, non-functional requirements are listed as a nice to have, rather than a must have. It’s not a matter of business logic vs. performance either. In one rare exception, I’ve had a requirement for an import function to load and validate millions of records within a 48 hour period. If the import wasn’t correct and wasn’t fast enough, the requirement was not met. We made it with room to spare.

I think one of the key problems developers have with non-functional requirements is that they aren’t tasks to be achieved then ticked off, they’re cross cutting concerns, and are often best effort, so don’t need to be 100% complete to be ready to ship. They can be continually refined.

This can be hard for binary developers to grasp. Tests pass or fail, requirements are complete or not. And in a pre-devops world, many of the factors affecting them are outside the control of the developers. You can’t have 99% uptime on a VM that’s off for 30 minutes a day to be backed up.

Good testers help to bridge the gap by turning an aspiration into a target. They hear the customer wants the website to be fast, and they write 95% of requests return in under 250ms. Browser compatibility goes in the test log, because “the current version of…” is a moving target.

Not that we pass responsibility for meeting the requirements from developers to testers, but we get the testers to turn something vague and system wide into something tangible and testable that the business owners and developers can agree on. After all, if it can’t be tested, there’s no way to measure of it’s done.

Most of all, it’s about explaining to business owners that an aspiration is not a requirement.