Weekly Digest

Life
A busy and tiring last fortnight. Made the most of the Autumn weather and had a couple of trips out to Perthshire. Both were glorious and really pleased with the camera and drone shots like the one below.

Also enjoying the new Apple Watch although I do have some niggles. Hope to get a post up later this week on the last 4 weeks of use.

Media
Forza Horizon 4 is just fantastic. A blip last week stopped multiplayer working smoothly but it’s a realy fun game with loads to do and enjoy. However, it won’t get much playtime over the coming weeks…

Red Dead Redemption 2 came out Friday and it looks stunning on the Xbox One X. Proper 4k and HDR and so far it looks and plays really well. I’ve only put around 6 hours in and it does get off to a slow start but the game soon starts to unveil more depth and suddenly there is tons to do but all at your own pace.

Links

Weekly Digest

Life
Good weekend. Tickled a couple of websites, bit of DIY, out with the camera this evening and actually got some sleep unlike most of last week.

Media
Forza Horizon is just fantastic.

Holedown on iOS and Android is well worth playing. One of the best mobile games this year – so addictive.

Doctor Who – looked fantastic tonight. Well done all.

Links

Ten Principles of Simplicity

What does “simple” actually mean?

People can always tell when something is simple, uncomplicated, elegant, not overworked, or a number of other near-synonyms, but can rarely articulate why something is simple. Because simplicity is inherently subjective, achieving it pretty tricky.

Fortunately, the discipline of experience design has emerged as a means to help the world realize its need for simplicity and what it takes to achieve it.

  1. Meet expectations – If someone goes to your product or website for a specific reason, make sure that you know the reason for their visit and the user can confirm they are in the right place, instantly.
  2. Don’t overwhelm people – Humans can (consciously) only process small amounts of information at a time, so if you don’t quickly make your point, their attention wanders. My favorite technique for not overwhelming people is progressive disclosure. That’s a fancy way to describe showing only a tiny bit of information at a time so people don’t become overwhelmed and confused. Here’s a fantastic example.
  3. Only present a few choices at a time – This is directly related to #2. Studies show that if you give people too many choices, they will “make no choice at all. So, it’s often better to remove features rather than add them. Why not focus on creating the minimum viable product, get it to market, then improve on it (or trash it completely in favor of a better solution)? Constantly adding features only ensures your product will never be complete and you’ll run out of money, all while confusing the heck out of intended users.
  4. No jargon or compu-speak – Talk to people like they are human, and don’t mire yourself in jargon. For example, rather than just label a form “Email,” how about making the label a bit more personal or in-brand? Wufoo does a great job with their form labels: “Enter your email address so we can get a hold of you. Don’t worry. This info is sacred to us. We won’t ever sell or abuse it.”
  5. Consider the abilities of different users – Dr. Jennifer Romano-Bergstrom has done some fascinating research on differences in website usability performance based on users’ ages. One thing I found particularly interesting is that older users tend to ignore content that is located in the periphery of a website. Take into account these differences and make sure your product accounts for them.
  6. Visual clarity – Clarity in visual design is critical for simplicity. Users assess the credibility of something very quickly, so if there isn’t a clear visual hierarchy, people will get confused. But keep in mind, just because something looks simple, doesn’t mean it is simple.
  7. Understand the problem – Mads Kristensen put it best when he said, “… if you cannot take a step back and get a good feeling for the problem, then you don’t understand it enough to see a simple solution … If you don’t understand the problem you are trying to solve, then you probably cannot solve it.”
  8. It’s been tested – If someone doesn’t want to test something, that person is probably cowardly, lazy, or arrogant (and don’t let them play the budget card, you can test things for next to nothing). Creation and objectivity usually don’t go hand in hand. You have to test with users.
  9. Account for context – How you use something differs greatly depending on the time of day, your location, and your culture. For example, try to think how someone might use your product while in a hurry, or perhaps on an iPhone, or while sharing it with a friend. They might also use it completely differently the second time than the first. Time of day, repetition, cultural nuances, and location all drive the context of how your product will be used. Understand it, it’s important.
  10. It’s not just usable – Just because someone can complete a task, doesn’t mean it was a pleasant or easy experience. Be careful not to put too much emphasis on task completion at the expense of a good experience.

How can We Shoot for Simplicity?

Everyone wants stuff that’s simple to use, yet simplicity can be very elusive. To find ways to streamline and simplify, it helps to take a look at a project’s framework; controlling the expectations and processes makes achieving the desired outcome much easier.

In the video The ROI of User Experience” by Dr. Susan Weinschenk, she highlights three causes for project failure (she also breaks down the value of UX much more eloquently than I can, so be sure to give it a watch). I’ve cited these (and added a fourth) below, with recommendations on how to address such challenges.

1. Communicate clearly

Lack of clear communication breeds confusion. Establish a project leader and communication process at the onset, be diligent about following it, and keep track of decisions that have been made.

2. Visualize success

Take the time at the front end of a project to define what a successful launch will look like. Answer questions like these to help keep you on the right path: What is the business goal we’re trying to achieve? Who is the user, and what are their goals? What does the product actually do and not do?

3. Align your stakeholders
  • Make everything matter. It’s your job to care about every detail, because if you don’t, who will?
  • Remove technical debt. The time maintaining an antiquated or poorly constructed system can hamstring future efforts to create simple solutions.
  • Keep things from getting bloated. If the people using your product don’t need or want something, isn’t it just a distraction? Streamline!
  • Plan for executive buy in. Stakeholders need to be heard; involve them early on in the process. Good communication and alignment on goals will assure a better end result.
4. Seek outside opinions, because we can’t do it all ourselves

I make music, and often I’ll write a song that I’m initially thrilled with. After a day or two goes by, I’ll return to the song only to be completely underwhelmed with the original recording. Things are always more exciting when we experience them for the first time; as we focus on something, we have less of a visceral reaction to it, second guess ourselves, and lose interest. Get your idea into a prototype quickly, and show it to others.

Why?

Perhaps the easiest thing one can do to ensure simplicity is to constantly ask, “Why?”

  • Why are we adding this?
  • Why are we taking this away?
  • Why would users care?
  • Why would people share this?
  • Why will people do this?
  • Why can they do this?
  • Why will they still do this?
  • Why aren’t we testing this?

The smallest details can make the biggest difference. If you come to an impasse, ask the person who’s been designated as the leader to make a decision and move on. You can always test your hypothesis later.

That’s Simple

Complex is easy, simple is hard. But, with intense focus, good communication, clarity, and bravery, getting there doesn’t have to be so difficult.

Einstein said it best: “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.”

From http://uxmag.com/articles/the-complexity-of-simplicity

Amazon's Leadership Principles

  1. Customer Obsession – Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers.
  2. Ownership – Leaders are owners. They think long term and don’t sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team. They never say “that’s not my job”. 
  3. Invent and Simplify – Leaders expect and require innovation and invention from their teams and always find ways to simplify. They are externally aware, look for new ideas from everywhere, and are not limited by “not invented here”. As we do new things, we accept that we may be misunderstood for long periods of time.
  4. Are Right, A Lot – Leaders are right a lot. They have strong judgment and good instincts. They seek diverse perspectives and work to disconfirm their beliefs.
  5. Learn and Be Curious – Leaders are never done learning and always seek to improve themselves. They are curious about new possibilities and act to explore them.
  6. Hire and Develop the Best – Leaders raise the performance bar with every hire and promotion. They recognize exceptional talent, and willingly move them throughout the organization. Leaders develop leaders and take seriously their role in coaching others. We work on behalf of our people to invent mechanisms for development like Career Choice.
  7. Insist on the Highest Standards – Leaders have relentlessly high standards – many people may think these standards are unreasonably high. Leaders are continually raising the bar and driving their teams to deliver high quality products, services and processes. Leaders ensure that defects do not get sent down the line and that problems are fixed so they stay fixed.
  8. Think Big – Thinking small is a self-fulfilling prophecy. Leaders create and communicate a bold direction that inspires results. They think differently and look around corners for ways to serve customers.
  9. Bias for Action – Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.
  10. Frugality – Accomplish more with less. Constraints breed resourcefulness, self-sufficiency and invention. There are no extra points for growing headcount, budget size or fixed expense.
  11. Earn Trust – Leaders listen attentively, speak candidly, and treat others respectfully. They are vocally self-critical, even when doing so is awkward or embarrassing. Leaders do not believe their or their team’s body odor smells of perfume. They benchmark themselves and their teams against the best.
  12. Dive Deep – Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdote differ. No task is beneath them.
  13. Have Backbone; Disagree and Commit – Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.
  14. Deliver Results – Leaders focus on the key inputs for their business and deliver them with the right quality and in a timely fashion. Despite setbacks, they rise to the occasion and never settle.

From https://principles.design/examples/amazon-s-leadership-principles

Agile Manifesto

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

And the principles behind the agile manifesto are:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

From http://agilemanifesto.org/

Why Corporate Apps Fail

Have you ever found yourself saying things like:

  • Why are enterprises so slow?
  • How do they decide what to buy?
  • Why is it so hard to deliver things in an enterprise?

I worked for a large ‘enterprise’ organisation for a few years trying to deliver infrastructure software change, and found myself having to explain these things to developers who worked there, salespeople, external open source engineers, software engineers who worked for enterprise vendors, and even many, many people within that organisation.

A few of those people suggested I write these explanations up so that they could pass it on to their fellow salespeople/engineers etc..

The polygon of Enterprise despair

From https://zwischenzugs.com/2018/10/02/why-are-enterprises-so-slow/

Towards better meetings

Meetings can be fantastic or terrible. I’ve experienced some serious pros run meetings, and when they do, everyone feels great afterwards. Everyone feels like progress was made, that things are clearer than before, that there is continued momentum.

(This is a note I sent to my team of Product Managers, Designers and Researchers at Intercom)

Meetings are expensive. Consider the opportunity cost of people being at a meeting – they could all be doing other important things. Treat other people’s calendars as a scarce resource and know that an empty calendar is an awesome place to be in because you are free to do your own work.

I consider any structured conversation between two or more people as a meeting. Today, at Intercom, we don’t do a great job of running meetings. We’re neither terrible or fantastic, but I want us to get way better. This is simply a process problem; it is entirely within our control. There are clear best practices in running great meetings. This is mostly a solved problem.

This is how we should be running meetings and you should hold your colleagues accountable to this standard.

Meetings must have one owner

This person runs the meeting.

They are responsible for the attendees staying on topic.

They are responsible for ensuring the meeting starts on time.

They are responsible for ensuring the meeting is on track, in the time remaining, to accomplish the goals set out at the start.

If you walk into a meeting and it isn’t clear who the owner is, feel free to leave and go do something more valuable for the company.

Meetings start by sharing the required output

The meeting owner starts the meeting by saying what the goal of the meeting is. For example, “We need a decision on whether to pursue option A or option B”.

The meeting owner clearly defines the boundaries of the topic. For example, “We don’t want UI feedback today. We need to only discuss concept design so we can decide between option A or option B”.

Meetings end with very clear action items, each of which has one owner and a due date

As a meeting progresses, the meeting owner collects and writes down any decisions made, action items, owners and due dates.

The last act of the meeting is for the meeting owner to read out the decisions made, and the action items and owners. This is to ensure nothing has been misunderstood.

The meeting owner must then email the list of decisions and action items to all meeting attendees to really ensure nothing has been misunderstood, and to ensure we have accountability.

If the due date is not going to be met, it is the responsibility of the action item owner to let others know.

Other best practices

If a meeting concludes before the time allotted, end the meeting and leave! Don’t try to fill the time with other random top of mind topics.

If you are in a meeting and feel you don’t need to be there, let people know, and unless anyone wants you to stay, then get up and leave. No-one is going to be offended.

Feel empowered to decline meetings that you don’t think you should be at, or don’t know what they are for. Don’t ever just show up to a meeting without knowing what it is going to be about.

Meetings should never be the reason a decision is unnecessarily delayed. Don’t wait for a meeting when a decision is needed. If you need feedback or help, make that happen before some standing meeting.

Finally, your time is precious and expensive; ensure good meetings are being run. Your colleagues owe you that, and everyone wins.

From https://www.intercom.com/blog/towards-better-meetings/

Learn to spot Unicorns

Horns, horses and wings exist.

Unicorns do not.

Just because you can talk about “proactive infrastructure”, a “dynamically configurable platform”, or “contextually aware flow routing”, doesn’t mean they exist.

There are a lot of folk out there selling Unicorn architectures.

Learn to subject proposed architectures to common-sense, plain-English reality checks.