There’s no such thing as bells and whistles

Often designers are accused of or cautioned against adding “bells and whistles” to products, based on the premise that designers are like make-up artists or just put the icing on the cake.

Good designers work from the ground-up, from product vision and strategy through research and analysis to design tools for people that are perceived as usable and useful, even desirable.

There shouldn’t be so-called “bells and whistles” or superfluous features that cannot be demonstrated to have derived from requirements and objectives. There are just low- and high-value user stories, and low and high costs to implement them, and the product owner makes a decision about whether investing the time, effort and money into a low or high value feature, experience, streamlining or other change to a product is worth it.

To lump designs into a “bells and whistles” bucket shortcuts the conversation about whether an interpretation of a user story is valuable and worthwhile.

Bells and whistles

If you enjoyed this article please share it with your friends and colleagues.

Do we have to write user stories for out-of-the-box functionality?

Yes, you should.

Even if a user story requires zero effort to implement, it’s still important to apply the same principles of user-centred design and evaluate the suitability of a solution against an identified activity and goal.

Some features of commercial off-the-shelf (COTS) products have been in development for over a decade and are considered very mature. That doesn’t mean they’ll be considered usable and useful for your market. It probably means those features are very sophisticated, support many edge cases and have no defects.

From one angle those are all desirable attributes. From another angle those attributes can be detrimental. You’ll be tempted to just bolt them onto your product without assessing them against how people might perceive and use them. You’ll be less likely to put them through the same rigorous testing that your own code is subjected to. And being ‘fully-featured’ can actually interefere with what otherwise could be a straightforward activity with additional decision points and complexity at the user interface.

Take jQuery File Upload as an example:

jQuery file upload dialog

As far as a file upload plugin goes, this has everything and the kitchen sink:

  • Browse to file on computer
  • Upload a file
  • Cancel or abort upload
  • Upload multiple files
  • Delete uploaded file
  • Delete several uploaded files
  • Select all files and delete them
  • Display size of files before uploading
  • Display and update upload speed in kilobits per second
  • Display and update upload timer in hours, minutes and seconds
  • Display and update progress indicator as a bar
  • Display and update progress indicator as percentage to two decimal places
  • Display and update progress bar as file size uploaded
  • Cancel all file upload activity
  • File names for selected and uploaded files
  • Upload a file independently of all selected files
  • Commence upload of a file independently of all selected files
  • Cancel/abort upload of a file independently of all selected files
  • Larger file sizes shown in MB instead of KB

jQuery file upload dialog with upload in progress

That’s a lot of features! You couldn’t expect a bespoke software product to contain all those features and would be unlikely to write user stories that would result in all those attributes, unless multiple file upload was central to your application, as it is for Dropbox and Google Drive.

But for most websites and web apps I’ve been involved with that have a file upload component, the workflow is pretty simple. Typically a single file of a size small enough for such verbose progress details to be not just inappropriate but clutter.

Can we live with the button being labelled “Delete”? Does it make sense to have a bulk upload-capable plugin when the form being completed by the user only expects a single file? Are people going to figure out they need to close the dialog once they’ve finished by clicking the ‘x’ icon because there’s no ‘next’ or ‘done’ button? Will files ever be so large as to need an upload abort button?

The following diagram illustrates the difference between a solution-centric view of evaluating out-of-the-box (OOTB) features and a user- or problem-centric view.

The solution-centric view (left) would see user needs as a subset of the features provided by the ‘mature’ solution.

Overlap between features and user needs

Where the solution-centric view sees bonus features and ‘value add’, the user-centric view sees avoidable complexity that increases the cognitive load on users for what should have been a simpler, less-featured and better-integrated solution that supports the activity, for example:

  1. User comes to online form expecting to upload a file
  2. User already has the file ready to upload
  3. User selects the file from computer
  4. User submits form, which uploads file
  5. User walks away

Does not require a “file manager” idiom. Does not need to see files upload in realtime. Does not need to monitor upload. Does not need to review filenames and file sizes. Does not need to remove uploaded file. Does not need to abort a file upload operation. Does not need to think about uploading files as a sub-form of the main form that you enter into and then exit from to return to your main form.

The latter view can only be arrived at by following the same process as for the rest of your software and describing the tasks, objectives and situations of actual system users without presupposing a solution.

COTS products are often a great way to implement a solution cheaply and quickly, taking advantage of years of research and development by other companies. You never want to set out to replicate mature platforms and content management systems like Sharepoint, Drupal and WordPress. But have you ever tried to explain the ‘power’ of Web Parts to a content author and have them respond “But I just want to …”

Don’t fall into the trap of solution-centric thinking where more features equals more value. It’s often the opposite where poor integration with users’ mental models and workflow, additional buttons, form fields, screens and decision points actually decrease productivity and perceived usability of the solution.

If you can use an existing solution or plugin to satisfy a user story and any disrepancies or trade-offs are worth it (even if it means an increased abandonment rate or lower level of user satisfaction) then great, go for it.

Don’t be like Beni in The Mummy and load up your camel with gold treasures. It didn’t end well for him.

Beni about to die in The Mummy (1999)

Stay focused on what you came for. Lead with your stories and work the problem space before moving into the solution space. Then and only then look to see what is available to use or co-opt, and assess its suitability against the story and acceptance criteria.

If you enjoyed this article please share it with your friends and colleagues.

Taking the pyramid of quality a bit further

This software product quality pyramid has been reproduced from Gojko Adzic’s book Fifty Quick Ideas To Improve Your User Stories and as presented in Gokjo’s 2012 blog post Redefining software quality.

The five levels are a model for how to assess and perceive software quality ranging from ‘functional’ at the lowest tier where the software is good enough to be deployed because it passes unit tests.

The top tier is occupied by the likes of iOS, Adobe Photoshop, Atlassian JIRA (though that one is up for debate), Buffer and Evernote; software that transcends being just useful to popular (and not in the way that Windows 10 is ‘popular’ because Microsoft is forcing it on everyone).

Product quality pyramid

In his blog post Gojko makes a parallel with Maslow’s hierarchy, so ‘successful’ in this software quality pyramid roughly equivalates to ‘actualisation’. Software that is so good people love it.

But what if instead of a single scale that covers the entire product we look at evaluating parts of a product? This may be a bastardisation of the concept, but let’s just play with it for a second and see if this is useful.

Instead of an overall score of “Works well” or “Useful” let’s slice the pyramid vertically where each slice represents a feature, workflow or user task.

Pyramid sliced into columns


If we’re looking at an e-commerce site then those vertical slices might cover search, browsing categories, shopping cart, checkout, online support, warranty claims, paying with credit card, paying with PayPal, accessing from a mobile device, geolocation, personalisation etc.

Pyramid with overlay

It’s not just a way of evaluating different aspects of software but also a way of thinking about intentionally having different quality criteria across your product.

Perhaps a basic ‘functional’ implementation, a single iteration of a feature may suffice for a feature used infrequently by a minority of your userbase.

Frequently-used features need to be highly refined with several iterations and higher quality criteria (no known defects, performance etc) to be deemed satisfactory and competitive by your target market so they would need to attain at least ‘usable’ status.

I’ve overheard conversations between agile development teams and product owners to pare back test scripts because the high level of quality agreed on was overkill for some user stories.

What if instead of getting into the minutiae of which test scripts to suspend for a user story the team could instead ask:

  • Does this feature need to work well?
  • How often are people going to need it?
  • What sort of people are going to want to use it?
  • Is it just a shortcut or accelerator for something that can already be done?
  • What do users stand to lose if it doesn’t work well?
  • What do we stand to lose if this feature doesn’t work well?
  • How much effort is involved in making this useful?
  • How much effort is involved in making it usable?
  • What might be the ROI if we work on this until it’s useful?
  • What might be the ROI if we settle for ‘works well’?
  • If we aim for basic ‘just passes unit testing’ might that detract from the overall experience? For whom?

So where does MVP fit into this?

I’ve avoided using the term ‘minimum viable product’ in this blog post and I want to point out why. When iteratively developing a product it is considered poor practice to think of it in terms of this pyramid where you build the entire product to a ‘functional and deployable’ state and work upwards.

First, that’s a poor way to determine whether your vision is actually going to result in a viable product from a market perspective.

Second, it often results in decisions to ship overly basic, uninspired and me-too software that meets internal criteria for MVP but actually falls flat in the marketplace.

bottom-up approach like that is not agile, not adaptive, not open to learning and incorporating new information and assumes that the entire scope of what you envisaged from the start is both required and is best delivered in the way envisaged.

You’re likely to throw money away on features you could do without, money that would have higher ROI making other features usable, useful and contribute to a successful product.

When thinking about your MVP or Minimum Viable Experience you should slice the pyramid vertically. Pick one activity, one scenario, one user group and do that well. Test it with that smaller user group, learn from it and get a better feel for what might actually constitute a viable product:

Tiered pyramid with single vertical slice highlighted

There’s also this comparative diagram with different tier labels and slightly different intent to the quality pyramid presented above (author unknown):

MVP pyramid bottom-up and vertical slices

If you enjoyed this article please share it with your friends and colleagues.

Recent book purchases following Scrum Australia

Some of my purchases over the last couple of months, stocking up for reading while on paternity leave. Several of these I got after attending Scrum Australia 2016 in Melbourne.

I try to not stray too far into the leadership/management genre because I have more than enough reading on my plate for coaching, facilitation, design and research but these ones looked good:

Follow me on Goodreads to see my whole bookshelf, read my book reviews and recommend books to me.

If you enjoyed this article please share it with your friends and colleagues.

Experience shopping for nappies

My wife Jenny and I are expecting a baby in the next month. Due to complications including IVF, breach position, pre-eclampsia, gestational diabetes etc we’re expecting our baby to be born pre-term possibly as early as 35 weeks.

So after visiting my wife in hospital yesterday I went to buy nappies from Baby Bunting, apparently one of the only places in Canberra you can buy nappies for small premature babies.

I decided to check the website first to see what I was looking for. Went to the website, scanned the categories and tried a couple before discovering nappies under “Changing”.

Baby Bunting home page with menu expanded

Okay, so now we’re looking at nappies. 77 of them. How can I see what’s relevant to me?

Baby Bunting website with nappies category showing

Firstly I tried under “Suitability” and selected “Newborn”. Scroll, scroll, load more, scroll … no, nothing about premature babies there.

Baby Bunting website with search filters and newborn selected

What about “Size”? Let’s try “Small”. Nothing there either.

Baby Bunting website with search filters set to size small

The midwife had advised I look for something suitable for a 2500 gram baby and if you look closely at the product photos you can see they have weight ranges on the packaging … but there’s no related search filter for weight!

Baby Bunting website showing product photos for BabyLove nappies

So I gave up with search, removed the filters and just browsed the entire range until I found what I was looking for on page five of the category.

Baby Bunting nappies for premmie or premature babies

And while on the subject, I hate infinite scroll. It breaks the back button because if you click on a product and go back you go back to page one and have to click “Load more” a half dozen times to get back to where you were.

If you’re going to do infinite scroll do it properly, rewrite the URL or use doc frag IDs and reload as many pages of results as needed then place the user back where they were.

The lazy way infinite scroll is often implemented is like Game Over, Do You Want to Start Again?

If you enjoyed this article please share it with your friends and colleagues.

To be agile you must change how you treat your people

So, I went to Scrum Australia last week … a conference ostensibly about a specific agile framework developed by Ken Schwaber and Jeff Sutherland in the early 90’s.

It was also about people. If work culture and management approaches were on a spectrum with current waterfall and command and control practices in the middle then Taylorism would be down the far left and Scrum on the far right.

There is paint-by-numbers Scrum (“We do daily stand-ups therefore we are agile”) and then there are teams (and their clients) who truly grasp Scrum as an incredibly powerful and nimble way to work iteratively with short feedback cycles to learn from how the business or market responds to the product or service being developed. Or on a larger scale the delivery of policy, programmes and organisational transformation.

The latter way of doing Scrum requires a change in attitudes, mindset and culture. You can’t just relabel functional requirements as PBIs or user stories yet still work the same way and commit to a scope of work from day one. There’s no point working iteratively if there are no opportunities to inspect and adapt, conduct user testing or prototype what you’re building out in the real world.

Traditional team management practices such as simplistic approaches to assessing personnel performance, tracking timesheets, monitoring attendance, workplace surveillance (which I’ve been subjected to in several jobs), strong hierarchy, centralised decision-making and the allocation of tasks to subordinates all have no place in a team that wishes to work agile.

Those traditional practices have their place if you don’t trust your employees, the work is predictable, you don’t need highly-skilled staff and make a deliberate strategic HR decision to basically treat people as replaceable commoditised cogs.

For more on that, I suggest Ricardo Semler’s book Maverick.

To be agile there must be trust, mutual respect, cohesion, decentralisation of decision-making, a culture that accepts and even embraces being wrong, that is open to experimentation and pushing boundaries.

Trust means believing that you’ve hired the right people, that they want to do good work and will get the job done.

Cohesion means that you operate as a team that works together, delivers together and fails together; not a loose collection of co-located people assigned to the same project.

Agile teams poke and play with boundaries. They never blindly accept it when someone says “It can’t be done”. To be given a box and told you cannot stray outside that box is demoralising. It diminishes the autonomy of teams who want permission to do what needs to be done to deliver the most value to customers, regardless of what fences need to be bulldozed.

You say it can’t be done? We’ll put that to the test.


Don’t worry, I’m not about to go all Sun Tzu.

Organisations with agile teams no longer micromanage and control each and every decision and interaction.

Focus on what’s important and help your teams grow and mature over time through leadership and coaching. Observe performance and provide feedback over the long-term. Apart from that, step back and trust them. They may do things you might not agree with but interfering and controlling may pose a bigger setback than just letting the team figure it out for themselves and feeling empowered to fix their own mistakes or correct their own course.

Once you start realising and appreciating people’s true potential to be creative and empowered to do their best work then nurturing those qualities take precedence over workplace attendance and delegation of tasks.

Managing working relationships becomes trickier, more nuanced, less big stick and more negotiation and coaching. Less coercion and negative reinforcement, more authentic gratitude and shaping behaviours.

It’s not just letting go of the steering wheel and hoping for the best. You need a new skill set and approach to leadership and shaping organisational culture for optimum performance and safety.

Adopting the Scrum framework and practices is a big job for team. Transforming the way people think to fully realise the benefits of Scrum at a deeper and more profound level is a massive job.

But changing the way you manage and lead, and the very posture of an entire organisation to enable Scrum teams is a gargantuan task.

Are you up for the challenge?

Reading list

If you enjoyed this article please share it with your friends and colleagues.

Coaching product owners

Continuing on from Mia Horrigan’s talk at Scrum Australia 2016 Confessions of a Scrum Mom on doing too much for teams is this quote from Lyssa Adkin’s 2010 book Coaching Agile Teams:

If you step in to “cover” for the product owner by preparing the backlog yourself, the results will likely be disastrous. When you step in, you assume a proxy role, and you have no choice but to guess at how to prioritise the product backlog. It will be wrong. Worse than that, the learning will be lost.

The team will not be able to see the situation clearly because you have muddled it for them with your well-intentioned help. They will not confront the product owner with their needs. The product owner will not learn, and you will have cemented your role as the proxy.

When you coach product owners to be good for the team, remember this: Teach the role, coach the role, and ask the team to expect the product owner to uphold the role. Beyond this, let the role fail. Then, help the team and the product owner learn from their failure, recover from it together, and become stronger.

Even if as a coach you know how something should be done it may be better to let the team make sub-optimal decisions and find their own way under your supervision rather than you leading from the front and they merely following.

Stepping in and actually doing the job of the product owner is not sustainable and is not what a good coach should do.

If you enjoyed this article please share it with your friends and colleagues.

Quick recap of Scrum Australia 2016

I’ve been attending work conferences for over a decade, but they’ve all been web and design conferences – UX Australia, WebStock, Web Directions.

Scrum Australia was new for me, a conference not so much about what we do but how we work, lead and coach.

Steve Denning – author of several management and leadership books including The Leader’s Guide to Radical Management – spoke about organisational transformation and how several companies have made the journey over many years from a few teams adoption agile through to it becoming a top-down mandate, including Microsoft.

Steve explained the difference between adopting Scrum practices versus transitioning to an agile mindset; a topic I also discussed in my previous blog post.

Bernd Schiffer from Bold Mover gave us a comprehensive description of what Scrum Masters can (or should) do, how important they are to the smooth and efficient running of Scrum teams and why investing in a full-time ScrumMaster role is generally better for overall velocity and return on investment in the team than someone trying to do both their normal job as well as wearing the ScrumMaster hat as needed.

Rowan Bunning used the differences between scalable Scrum frameworks SAFe and LeSS to illustrate the essence and power of Scrum and how SAFe suppresses that by placing Scrum as a mere low-level cog where LeSS does a far better job of scaling the power of Scrum.

Charles Randles from Suncorp gave an amusing and even heretical talk about the foolishness and wasted effort of typical management practices that pick the easy stuff like checking timesheets and attendance, and optimising the wrong stuff instead of leading, motivating and creating a space where people can realise their potential.

Andrew Rusling covered theory of constraints (as explained by Eliyahu M. Goldratt) and gave us 21 experiments that teams can try to improve their velocity by identifying where constraints exist through the visualisation of work and then tweaking parameters starting with cheap fixes through to aligning people and then finally more expensive fixes like improving tools, environment and only if absolutely necessary bringing in additional people.

Mia Horrigan (my boss at Zen Ex Machina) spoke on Confessions of a Scrum Mom. She shared her story as a parent of a soccer-playing kid and how her idea of coaching compared to that of real coaches. Mia drew a parallel with her professional agile coaching and when she recognised that she was doing everything for her team as a ScrumMaster and instead needed to take some lessons from elite sports coaches and help her Scrum team grow rather than rely on her to fix everything.

Friday morning was allocated to “Open Space” sessions, self-organised presentations and discussions about various topics in all rooms and corners of the venue – I think at one point there was nearly a dozen concurrent sessions ranging from a group of five up to fifty or more participants.

Here are some of the artefacts of those sessions:

I think the big takeaway for me was being re-energised and more confident about the work that I do in advocating for Scrum and coaching Scrum teams. When you’re the only person in a room who really gets Scrum and everyone else is pushing back you can start to doubt yourself and the methodology.

I feel attending Scrum Australia will give me the momentum to stubbornly persevere with a renewed passion for what I do, and a few more techniques and success stories in my kit. Plus quite a few more books.

Reading list

Books given away by Scrum Australia 2016 sponsors elabor8, sadly not to me:

If you enjoyed this article please share it with your friends and colleagues.

Focus on the stories, worry about format later

I often get asked by development teams new to Scrum what format to follow when writing user stories. I love their enthusiasm and desire to do it properly but instead of focusing on the format I instead steer them towards just telling good stories.

There are Scrum-specific maturity models but in the context of user stories I’ll instead look to HCD maturity models, specifically Earthy’s Usability Maturity Model (UMC).

Level B of Earthy’s model (“Considered”) requires that organisations fully or largely meet the criteria that training is delivered so that staff are made aware that:

  • the needs of the end users of the system should be considered when developing or supporting the system
  • end users’ skills, background, and motivation may differ from developers or system support staff

As the executive summary states, progressing to this level of maturity is “a major cultural change”.

When it comes to immature teams writing user stories I don’t want them to get hung up on the format because it’s a distraction. They’re not ready to write what I would consider high-quality stories that describe the people the story is relevant to, what we want to help them accomplish and the nuances of the contexts of use … As a blogger, I want to create a draft post because I have an idea but don’t have time and just need to sketch it out so I can revisit it later.

Those nuances are very important for seeding creative thinking and novel solutions to real challenges that a more simplistic view might overlook. But it’s a stretch to expect teams new to user-centred agile to jump straight into.

If we focus on formats such as Connextra then I believe we risk teams settling for doing Scrum by the numbers instead of embracing the full benefit of Scrum or agile generally as Michael Sahota’s slide illustrates:

Doing agile practices does not equal having an agile mindset

Gojko Adzic implores development teams in his excellent book Fifty Quick Ideas to Improve Your User Stories to not worry about the format and instead focus on conversations, collaboration, and exploration rather than simply replacing functional requirements with story cards.

Personally, I quite like the Connextra format but teams who are new to Scrum and often new to user-centred design really struggle with it.

Teams unfamiliar with user-centred design and agile should take Steve Blank’s advice and GOOB (Get Out Of the Building) before they bother trying to identify user archetypes in their stories.

As for the all-important third part of the Connextra format, I wouldn’t expect teams below UMC Level C (“Implemented”) to be able to accurately capture the reasons why users might want to perform a certain task or be shown certain information.

I’m happy enough when new teams simply challenge their own assumptions in meetings about how “real people” might benefit or even suffer from the team’s decisions.

I’m delighted when teams start thinking “outside-in” as Dan Olsen describes it in The Lean Product Playbook. It is a major cultural change and I want to see teams explore and adjust to the user-centric agile paradigm without getting bogged down in syntax.

If all your story cards are 3-5 words that’s fine. As long as I’m seeing evidence that you’re thinking about users, thinking about journeys and contexts and usability then we’re all good.

For now.

Don’t get comfortable because we’ve still got a few rungs to climb.

If you enjoyed this article please share it with your friends and colleagues.

Iterative delivery done well, and poorly

The iterative design and development of a product or service is a concept that seems really hard for many people to grasp.

As a product manager and designated product owner within Scrum teams I’ve learned you can’t just explain it once, you can’t just structure the product backlog to be iterative and expect people to adopt the mindset. It takes a lot of coaching, persuasion and leading by example with new agile teams.

Well-executed iterations in an agile project target specific user journeys, workflows, audience groups or roles.

Rather than building half a thing that kinda works for most people you build part of a thing for specific people so that it works completely from end to end.

Well-orchestrated sprints and user stories plan to iteratively build parts of the product from a user perspective rather than an implementation model perspective.

User stories shouldn’t really care about which screens or pages features and content are implemented on.

A single user story might require modifying several pages or screens so that someone with a specific need or objective can complete a task or locate information spanning several pages and interactions.

I don’t mind developers breaking up stories into discrete actionable tasks to help them deliver it, as long as everyone is committed to delivering value to end users. It doesn’t have to be pretty but it has to be useful and help us learn whether the user story captured the requirement and whether we need to add, modify or remove something else to meet the essence of the story.

Here’s a literal application of Henrik Kniberg’s famous Not Like This, Like This comic to a screen-based software application:

Illustration of delivering value incrementally the bad way page by page versus user story centric

Hopefully it illustrates how poorly-planned incremental design and delivery may not deliver any value until several poorly-written user stories are completed. The correct way to iterate means that a single user story can be tested with the identified user, audience or role for  a specific scenario, task or information need.

By a “poor user story” I’m referring to the typical practice of using the Connextra user story format as a container to wrap around a good ol’ functional requirement, for example As a user I want to add a new record to the database.

I don’t do lorem ipsum filler text. I don’t do broken links that don’t go anywhere. If I sit a user in front of a release of an iteratively-developed product they should be able to read all the text, click on all the links and validate our design or disprove our assumptions.

This is why high-fidelity visual concepts and designs can make agile harder; they constrain exploration and learning, they support implementation model approaches rather than user-centric and they make it harder for product owners to get the team to focus on stories from the ground up when the team is working from end point designs.

This also works for service design but my specialisation is in web and mobile apps so I’ll tag one of my colleagues to explore good iterative design approaches for services.

If you enjoyed this article please share it with your friends and colleagues.