Category Archives: UX

The user experience discipline is a relative newcomer to software development. Alan Cooper is the most prominent figure and author in the space. These articles address different elements of UX.

Product Owner Manager – Alone Together

thumbnail of venn diagram

Product owners and product managers.  Two roles, often done by one person.  Together, the product people need to take an organization’s strategy, figure out the appropriate product strategy, and convert that into actionable work for the delivery teams to create the right product.  What does the product manager own, and for what is the product owner responsible?

Continue reading Product Owner Manager – Alone Together

Why Do Products Fail? – Ignoring Context

Wrapping up the your product failed because you didn’t enable your users to realize value branch of the root causes of product failure, is this article on the context in which your user is using your product.  If you ignore your user’s context, they won’t be able to realize the value you provide – or won’t be interested in solving those particular problems at that particular time.

Continue reading Why Do Products Fail? – Ignoring Context

Why Do Products Fail? – Forgetting that Users Learn

Next up in the series on the root causes of product failure – products that fail because you have ignored the user’s level of experience.  The first time someone uses your product, they don’t know anything about it.  Did you design your interfaces for new users?  After they’ve used it for a while, they get pretty good at using it.  How much do you think they like being forced to take baby steps through a guided wizard now?

Continue reading Why Do Products Fail? – Forgetting that Users Learn

20/20 Vision – Innovation Game in Action

Having an outside-in bias as a product manager is important – you need to understand how your customers (or your customer’s customers) would value capabilities you might build into your product.  When running a workshop to collect that information, playing some “serious games” is a great way to get more and better information.  We ran a few 20/20 Vision games last week, to great effect.

Continue reading 20/20 Vision – Innovation Game in Action

A Prototype is Worth a Thousand Lines of Code

A picture is worth a thousand words.  A prototype is worth a thousand lines of code.  Two key elements of product management – and of agile development are elicitation and feedback.  Low fidelity artifacts can significantly improve both.  Polished, codified prototypes can create problems that prevent you from getting the benefits of communication.

Continue reading A Prototype is Worth a Thousand Lines of Code

Cadence Versus Risk

I’ve been thinking about the software development process.  Big, upfront, design and requirements.  User research and analysis.  Market insights, gained on exploration or over time.  Release cadence – how quickly you get, and incorporate, feedback from your customers about your product.  How quickly you react to your competitors’ reactions to your actions.

Continue reading Cadence Versus Risk

Use Cases for Iterative Development

Almost everything I’ve read about use cases focuses on describing what needs to be added to your product.  Agile development says “get it working first, make it better second.”  That means changing the way the software enables a user to do something they can already do.  How do you manage requirements for incremental improvement?

Continue reading Use Cases for Iterative Development

Measuring Great Design – Mad Libs Input Form

image of mad libs pads

I came across a really interesting article LukeW.com, showing how making changes to the way an input form on a website increased interaction by 25 to 40%. The changes reflect the value of thinking outside-in, investing in user experience, and performance measurement.

Bonus: the idea is cool.

Continue reading Measuring Great Design – Mad Libs Input Form

Design-Free Requirements

Design-Free requirements are important for two reasons, and hard for two other reasons.

Design-free requirements are hard because you “know what you want” when you should be documenting “why you want it.”  Writing design-free requirements can be hard when you don’t trust your development team to “do the right thing” even though it is not your job to design the solution.

Continue reading Design-Free Requirements