Tag Archives: UX

Concepting for UX Designers

“UX people squeeze all of the fun out of creative ideas.” ~creative director

It can be tough for UX designers to embrace the ‘fun’ of concepting. We are trained to explore the dark corners of ideas to make them work smoothly for human beings. We consider the detours and side paths and button them up neatly. Our teams depend on us to apply logic, structure and rigor.

That’s a heavy load.  It’s easy for user experience designers to get typecast as someone who shoots holes in everything. Concepting is an opportunity to set that burden down and imagine the future. If that’s not an exercised part of your repertoire you may not know how to participate. It’s easy to fall into the familiar role of pressure testing the idea, tethering it to the earth. What’s a UX designer to do?

Concepts need space, time to grow before being anchored to structures and interfaces. Let yourself have fun building up ideas without editing. Send your inner analyst on a break. Resist worrying if something will work. Trust that the time for that exercise will come. Don’t fear ideas that fall apart. There is value inside every pie-in-the-sky, you-have-got-to-be-kidding-me concept.

UX Design is part aesthetics, part logic and applied science of human behavior. We make easy connections between the analytical and delightful. Jumping into “will it work” mode too quickly deprives your team from your insight. It also makes you a really lame playmate.

There will be time to revise and mould ideas into a usable experience. But it is not the only standard you have to march behind. You must play. When you catch yourself creating a user flow in your head, set that mental work aside. Reassure your inner IA that you will come back to the comfort of structure…later. Reeling in an idea that is overreaching is easy. Unleashing a design that is constrained and nudging it toward innovation is near impossible. Start big. Give yourself permission to play.

Crush the Real Issues to Make Customers Happy

Your project goal is to update a business solution that is slow and laughably outdated. Frankly, this dinosaur is making life hell for Company X’s employees and causing good people to make costly mistakes. You want to deliver a solution that gets rid of that pain and they will enjoy for years to come. (Hopefully not too many years.) It doesn’t take long to realize that there is a fundamental flaw in a business process that no amount of intuitive interface design will fix.

The great thing about this situation is that you’ve discovered the problem. In the user interviews, discussions about pain points and daily tasks have painted a vivid picture of the issue. Old school requirements gathering processes probably would have disregarded the information about the issue or simply recorded requirements needed to follow the currently flawed process. That’s one of the beautiful things I love about User Experience work. You get to dig deeper. The team can now start discussions to address the root issue.

Of course solving a business process problem is rarely in scope for most software rewrites. But the customer expects the project to make their lives easier. They have put faith, time and money into the project because they believe it will improve their situation. If you deliver a kick-ass application, that only solves part of the problem. The customer will be disappointed and perceive that you didn’t deliver or that the project didn’t accomplish all that their dollars were supposed to. You can meet your obligation, do your best work, and then not understand why the customer a year later contacts a different vendor to fix what you built.

It may mean increasing scope, or writing another SOW to cover the additional project of a new service design. Or, heaven forbid, you may have to take on that extra work and absorb the hit on this fixed bid project. But you have to do something in order to make your customer happy. Either that or you end up being the infamous third-party that technically delivered the requirements, took the money for the gig, but didn’t solve the problem they were hired to fix.

Make fixing that business process your problem. Because it is. You may not be the one to do the work of fixing it, but any UX professional worth their title should be able to guide a business to a new process that will work. And then, when you deliver that kick ass application, they truly will love you.  You will have provided critical value and brought a little more sunshine into the users’ lives. While you’re at it, capture some before and after metrics so that you can measure the awesomeness you have brought to their business.

Crush the Real Issues to Make Customers Happy

Your project goal is to update a business solution that is slow and laughably outdated. Frankly, this dinosaur is making life hell for Company X’s employees and causing good people to make costly mistakes. You want to deliver a solution that gets rid of that pain and they will enjoy for years to come. (Hopefully not too many years.) It doesn’t take long to realize that there is a fundamental flaw in a business process that no amount of intuitive interface design will fix.

The great thing about this situation is that you’ve discovered the problem. In the user interviews, discussions about pain points and daily tasks have painted a vivid picture of the issue. Old school requirements gathering processes probably would have disregarded the information about the issue or simply recorded requirements needed to follow the currently flawed process. That’s one of the beautiful things I love about User Experience work. You get to dig deeper. The team can now start discussions to address the root issue.

Of course solving a business process problem is rarely in scope for most software rewrites. But the customer expects the project to make their lives easier. They have put faith, time and money into the project because they believe it will improve their situation. If you deliver a kick-ass application, that only solves part of the problem. The customer will be disappointed and perceive that you didn’t deliver or that the project didn’t accomplish all that their dollars were supposed to. You can meet your obligation, do your best work, and then not understand why the customer a year later contacts a different vendor to fix what you built.

It may mean increasing scope, or writing another SOW to cover the additional project of a new service design. Or, heaven forbid, you may have to take on that extra work and absorb the hit on this fixed bid project. But you have to do something in order to make your customer happy. Either that or you end up being the infamous third-party that technically delivered the requirements, took the money for the gig, but didn’t solve the problem they were hired to fix.

Make fixing that business process your problem. Because it is. You may not be the one to do the work of fixing it, but any UX professional worth their title should be able to guide a business to a new process that will work. And then, when you deliver that kick ass application, they truly will love you. You will have provided critical value and brought a little more sunshine into the users’ lives. While you’re at it, capture some before and after metrics so that you can measure the awesomeness you have brought to their business.