UIEtips: The Dirty Dozen Roadmap Roadblocks

In this week’s UIEtips, we share an article from Bruce McCarthy. In it, Bruce defines the product roadmap and offers twelve areas where organizations break down when developing roadmaps. Best of all, he shares ideas on how to put all twelve roadblocks in your rearview mirror. Want to hear more from Bruce? He’s presenting our next virtual seminar on June 26, Lean Roadmapping: Where Product Management & UX Meet. Here’s an excerpt from the article: A good roadmap inspires. It inspires buy-in from executives, inspires confidence from customers and salespeople, and inspires development teams to produce the groundbreaking products that drive significant growth.  A good roadmap keeps your organization on course toward its destination. Stating what you will do and when makes it easy to judge when you fall behind schedule or get detoured by good ideas that just don’t fit your strategic vision. Read the article: The Dirty Dozen Roadmap Roadblocks. What roadblocks have challenged your organization in creating product roadmaps?  Leave us a note...

Maximum Viable Product

Eric Ries, pioneer of the Lean Startup movement defines a Minimum Viable Product having just those features that allow the product to be deployed, and no more. I’ve worked on many projects where we’ve defined the bare minimum feature set for the product to have any kind of success. I’ve yet to work on a project where we define the most we could or indeed should do to maintain the success of our product. Introducing The Maximum Viable Product We can define the Maximum Viable Product as a product that has just those features that allow it to be successful and no more. Customer needs are being met. The Max VP is reached when you’re at the top of your game. Your product hums like a finely tuned engine. Business is booming. But there’s that fear it’ll end. Maybe competitors are snapping at your heels or your internal process are at max. The most common course of action is possibly the worst course of action. Keep adding features. At what point does the addition of extra features detract from those features already present. This is not just the law of diminishing returns. Adding more bells, whistles and enhancements can mean that finely tuned engine that is your product sputters and stalls. More features does not equal better Adding in features is good right? It shows your product is evolving. Well not always. Fellow cxpartner Giles Colborne in his book Simple and Usable gives us the secret to designing the perfect product. Customers don’t choose our products based on features, they choose our products based on their desired outcomes and...

Notification Design Strategies

No one designs an email hoping that it'll read like spam. Nevertheless, many notification emails do. In this article, designer Katharine Bierce shares a few ways to ensure that the emails we send avoid the spam folder. The post Notification Design Strategies appeared first on UX...

Minimising Risk or why you shouldn’t re-design and re-platform at the same time.

I think back to the major site relaunch projects I’ve worked on in the last ten years and I see a pattern. When I started working on the web back in 2003 the projects I worked on were all second versions of sites. Version one sites were typically basic, hurried and often naive designs that had one objective, get us on the internet. The move from version one to version two sites was a glory period. A client once said to me “You could hit our website with a stick and it would be better than it is now”. Success was relatively easy to achieve. Crazy increases in conversion and other metrics; 500% increase in sales, 200% increase in successful applications were not uncommon. Version two sites were good, solid well executed builds. We as an industry had learnt how to do things well. The majority of large scale projects are version three. The days of huge increases in sales are behind us. In fact I’ve come across projects where the opposite happens. Where a new site performs worse than it’s predecessor. The common factor? Re-designing and re-platforming at the same time. Your trusted but long in the tooth version two website has had years of tweaking from user research and MVT / A|B testing. It has evolved to be pretty damn good. There are always incremental improvements that can be made but large scale jumps in performance require a re-design. Your tech team, similarly, have had years to iron out issues around uptime, performance and integration with your platform. A re-design will give you a leap in performance...