Uncategorized

For web design – Use your backlog!

by

Screen Shot 2018-04-11 at 8.18.27 AM(Graphic courtesy of of this deck from Reinhart De Lille)

 

Interesting article here by Guy Ligertwood – 11 Valuable Lessons I Learned While Working in the Real World of UX. The article, as a whole, got me thinking about the difficulties of agile, UX and specifically some thoughts around my early days of of backlog grooming and development.

Guy writes:

“Put it in the backlog and we’ll get back to it (never)”

 

Sadly, Guy’s not far from the mark. Frequently what goes into the backlog just doesn’t get revisited, mostly because it’s the non-priority, non-MVP (minimum viable product) options that get left behind (See the ‘Backlog Iceberg’ above). Movie editors will talk about losing parts of a story to the cutting room floor; Product manager’s lose stuff that isn’t a priority in the backlog. Backlogs are intended to be living and breathing documents that, especially during the critical start up phase, get much attention, but as market priorities shift, new products are released and organizational focuses evolve, older but not less useful backlog items get neglected. More than once, even right now as I type these lines, I can think of great functionality and features that didn’t make it into a releases I had hoped… the ones that got away… Well, maybe not ‘got away’ because as a Product Manager you have to hold on to those ideas, functionality and features for the right time.

Guy further writes:

“We hear lots about doing the best for the customer and in lots of cases we do, at first. The problem lies when we don’t get back to iterating on designs when delivering becomes more important…”

Again, Guy’s not wrong. As a product manager, you have to always be on your toes — Thinking, grooming and prepping the backlog, because iterations and sprints move quickly and they won’t wait for you. Nailing your cadence, watching the team’s velocity, negotiating stories, etc. are all the things that will keep you prepped and ready to hand off wishlist features and functionality that might not have made it into to early releases. If used consistently, the backlog can be the product manager’s best friend. If we’re doing our jobs as product manager’s well, there will be very few features that ‘got away’…

The Evolution of UX

by

As far as web design in Lansing goes, I consider myself one of the most vocal advocates for user experience design. When I saw Ian Armstrong’s article on the evolution of UX, I was sure that other folks doing web design in Lansing would want to learn more –  Check out Ian’s article here. Additionally, I will add a few of my own points based on my reading of the article, but a full read is a must.

lean ux design lansing

Ian states that “in its purest form, UX Design is waterfall based.” These days, in most circles where folks are talking about UX, ‘waterfall’ is a dirty word that hearkens back to rigid PMBOK processes and exhaustingly long requirements gathering sessions, but Ian’s absolutely right. You have to get a sense of requirements, gather perspectives, mock things up, test out assumptions, wash, rinse, repeat. It’s waterfall. There’s no way around it.

Ian nails one of the key problems with being outcome based, what we work towards with agile vs. requirements based. This is a conundrum that many of have faced and still work to reconcile:  “Whereas classic UX is requirements based, Lean UX is outcome based… Designers found themselves under immense pressure to fill a sprint backlog before they really understood what they were building. As a result, a lot of development cycles got burned on features that never made it into the final product.”

So much development and rework lost trying to anticipate product needs… <sigh>

I’ve read a lot about the Google Ventures Design Sprint, and attended a session at an O’Reilly Design conference where they talked about it, but even then, Ian’s explanation is as succinct and spot-on as any I’ve come across:

“Google Ventures conceived the design sprint, which allowed teams to rapidly define and test a low-fidelity prototypes. This jump-started the Lean UX cycle on emerging product teams and effectively eliminated the waste and rework problem.”

I’ll put a pin it there. Check out Ian’s original article.

If you’re looking for web design in Lansing that puts your user’s experience at the center of their work, then get in touch today.

Why UX should mean User Expectations

by

exceeding-user-expectations_3

As UX professionals there’s little that we do that isn’t steeped in expectations. Sure, we can have high-minded discussions about design, the vision of Steve Jobs, and of course Henry Ford’s ideas about faster horses, but what we’re really talking about are expectations. Whether we’re talking about the expectations around the speed or performance of a website, app or product or around the design, functionality and usability of those offerings. There’s just no way around it. That’s why, for my part, when I think about UX, I think of it as user expectations rather than user experience and I think that you should, too.

Think about it — Many of the practices that make up the discipline of user experience are, in fact, centered on establishing user expectations. Whether, we’re talking about personas, use-cases or journey maps, these all revolve around establishing user expectations. Additionally, user-centered design, which is really at the core of UX is all about getting a user’s perspective on what they expect through research and iterative development, ultimately delivering on user expectations.

It’s all about expectations.

I can’t tell you how many times I’ve heard the term ‘manage expectations’. For a long time, I thought of it as almost a pejorative perspective, like I had to sell something that wasn’t quite up to what a user wanted, and at times that’s exactly what I had to do. At other times, though, especially when I could get in front of a project or an initiative before it got off the ground, managing expectations became something entirely different. The managing of expectations became a practice in determining expectations, researching user needs and making them part of a product vision.

Many organizations still try to manage expectations as “requirements” during this phase of a project (waterfall), but the speed at which a project tends to move and the maturing realization that not everybody can visualize what they want in a software, app, etc… 6-12 months before they ever see even a paper prototype (show don’t tell) has increased the need to undertake UX in a different way. Many organizations are doing this as “lean UX” or building a UX approach into some form of agile software development. In my experience I think that we have a ways to go here, but were on the right track.

The right track being the maturing of the UX discipline and building out that discipline across organizations to capture user expectations and include them as part of the product vision… That’s why, for me, as a UX professional, there are times when the work that I’m really doing is researching and establishing user expectations, that work alone, defines the user experience, and for that matter designs the user experience, too. After all, if you don’t know what the user expects how can you design a user experience that suits those expectations?