Categories
development

Inclusion is not a zero sum game

Look around your office. How many people look like you? How does that compare to the people you saw on your commute, or in the supermarket? How does that compare to your users? Do you even know?

Are you making space?

How many people are struggling with mental illness? How many have accessibility challenges? How many are white, straight, cis-gender, able bodied men?

Is there a mismatch? And if so, what are you doing to change it? Are your job adverts inclusive and on inclusive sites? (hint: look at the StackOverflow developer survey before posting your job there) Do you have a network outside work that you can tap into to find new candidates?

Are you creating a safe space for everyone? Are company events open to new parents, to non-drinkers, to vegans, to women? Do people have to out themselves to attend a family day, or to avoid travel to a certain customer site? Do you support staff who need to transition? Staff who need quiet spaces? Staff who are fasting, or need non-Christian holidays?

Can your staff find somewhere to learn to sign? Or to write simplified for language learners, for those who have struggled to attain or retain language?

Which three of these questions are the most important to achieve for you this year? And how will you do it?

If you need somewhere to start, have a look at Inclusive 101 from the Microsoft Inclusive Design Toolkit, and ask yourself if that’s you, or pick an episode from the Cause a Scene podcast and listen, especially if it makes you uncomfortable.

Categories
development ux

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

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?

Categories
development ux

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.

vennux

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.

cycleofux

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?

Potentially useful resources

 

Categories
development

Sugar coated icebergs

Prototypes are great. They let the user see and feel what the final product will look like, either in printed or in online form.

They suck when the customer wants it next week because “it’s just a bit of wiring up to get it working”

And they can be dangerous. Ship that button without properly tested, or incomplete, code behind it and your software could crash and sink without trace.

If you want to always be finished, you need everything that the user can interact with to meet your quality standards. No unguarded exceptions, no raw data, no untested code. And if that means leaving that button out until it’s ready, do it. Or put in a bulletproof, well tested placeholder, like an email subscription to find your beta testers.

The user doesn’t know or care about all the mass under the surface that they can’t see, so don’t expose them to it. Keep the interface clean, simple and error free. Build up behind the scenes, behind feature toggles, and off production until you’re sure it’s safe.

The one thing worse than a missing feature is a horribly broken one. A user missing a feature may come back when the feature is ready. A user who’s experienced a broken feature won’t come back until they trust it.

Don’t lose your users’ trust.

Categories
development lifehacks

The tech diversity blind spot

 

wp-1450118461565.jpg

Technology makes the world better. It promises to make our lives better. It will free us from work.

Except “The best minds of my generation are thinking about how to make people click ads”. And tech lives in social bubbles as well as financial ones. Apps designed for silicon Valley don’t always travel to the rest of the USA, apps for Western countries don’t always apply in the East, Facebook and Google aren’t always trusted, VR headsets that don’t work if you wear make up, facial recognition fails if you don’t have the same skin as the webcam software developer, or the photo auto-categorising application developers.

Sometimes the solution is to write technology in another bubble. Brazil, India, China, and many other places have strong home grown technology far more popular than the “global” leaders. Sometimes you expand your bubble, diversified teams, balanced teams, who are smarter than homogeneous teams anyway.

Sometimes you look outside your bubble. I get paid to write software that I will likely never use. Line of business applications, including public interfaces, for government clients. I don’t know what their business is until I ask. I don’t know how they work, or what is important to them. And sometimes I have to ask several times, and sometimes people can never understand or articulate what they do, let alone what they want, even after asking them in several ways. So what makes you uniquely qualified to understand what you do, or what problems you have, or whether those problems are universal?

If you want to know if your intuition applies to the population as a whole, make sure your stakeholders reflect that population, or accept that you are deliberately limiting your audience, because that’s what makes sense to you.

Categories
development lifehacks programming ux

Users or consumers?

I’ve just been reading this article about how capitalism has changed our language in the last 200 years, and the move from talking about people as users of products to consumers. “How capitalism has changed our language” http://feedly.com/k/18naQTK

There is an old computer joke that about programmers referring to their customers as users, but this article highlighted to me something deeper that feeds into something about how technology is shaping our world.

Software development, when it works best, happens with active users rather than passive consumers, people who have an active interest in the problem the software is designed to solve, and sometimes ideas on how to solve it.

The biggest red flag I have to indicate the success or failure of a software project is the lack of user engagement. If no-one on the project team is a user, or is listening to the users, the project will almost certainly fail.

Software customers are not consumers, and often the user is not a customer, and they will only use the software they are forced to use by management or that they are comfortable with, and will likely not use it if they know a better alternative. If we can’t write software that engages users and makes their life easier, they will not use it.

This may not be a problem unique to software development, but at least the language of software recognises that there is a problem to solve, and that the user experience is the difference between software that delights and software that frustrates.