Quantcast
Subscribe!

 

Enter your email address:

Delivered by FeedBurner

 

E-mail Steve
This form does not yet contain any fields.
    Listen to internet radio with Steve Boese on Blog Talk Radio

    free counters

    Twitter Feed

    Entries in design (46)

    Thursday
    Apr302015

    Revealing Complexity

    Probably the most significant barrier to user adoption of new workplace technology is that users don't see the personal benefit of adopting these technologies. This is the classic 'What's in it for me?' conundrum. While that subject is important and worthy of exploration, I won't be hitting that specific problem today. Instead, let's talk about what is likely the second-most important barrier to employee adoption of workplace technology, namely, that most enterprise technologies have provided (relatively) poor user experience and/or are just too complex for them to use intuitively.

    While enterprise technology companies have talked about, and some have actually delivered, better, more compelling, more consumer-like technology user experiences, even the most modern, best-designed applications eventually run into a common problem in that enterprise tools often require LOTS of data be input into them.

    It could be a new sales prospect being recorded in a CRM, a new supplier that needs to be set up in Procurement, or even a relatively simple matter of entering a new hire in the HRIS, all of these use cases while impacting disparate systems and organizational departments, have much more in common than we usually think. Each of these transactions requires (usually), a whole bunch of data fields to be populated with a whole bunch of data. And even in 2015, for many organizations the bulk of these myriad data elements have to be manually typed into the respective system form fields the old fashioned way - manually.

    And so since the makers of CRM and Supply Chain and HR technologies understand this reality, and like to be able to sell to customers the things they need to run their business operations, even the most modern, slick, mobile responsive, and really amazing looking enterprise solutions often and still have these kind of busy, kind of ugly, kind of tired looking data input forms in order to support these kinds of transactions. And while we might be tempted to look at these kinds of forms, (and the processes that make these 37 field data input forms necessary), as relics from an older, less awesome age, they still have a place in most organizations and in most modern technology solutions.

    Not every interaction with an enterprise technology can (or should) be reduced to a graphic or chart on a tablet, or a glanceable notification on your new Apple Watch. Sometimes, the hard and necessary work of getting relevant data (and lots of it) about customers, vendors, and employees into the enterprise tools that organizations rely upon is, still, kind of boring, kind of repetitive, and even kind of monotonous.

    But that is entirely ok, and should not be considered some kind of an indictment of the technology solution provider that has not figured out a way to make inputting 32 fields about a customer into some kind of a gorgeous 'swipe left' and 'swipe right' kind of user experience.  

    User Experience and what is good User Experience is highly variable and highly personal. And what usually constitutes great User Experience for the sales exec who wants to look at the Q3 funnel on her tablet is much, much different than what makes up great UX for a payroll entry clerk. We can't confuse them with each other.

    The best designed enterprise systems, of course, support both UX's and both kinds of users. The key is, I think, to have the system only reveal its fundamental complexity, and the form with 37 input fields, only to those people who really need them, and care about them, and help them see the 'What's in it for me?' as well as treating them and their role with respect.

    Tuesday
    Mar102015

    Users don't know what they want - but they know something

    How much, or little, should product designers and developers interact with potential users and customers of the products the designers and engineers are creating?

    It seems like a simple question, but if you think about it some and recall some of the famous perspectives on customer input into product development you find that the answers to this question tend to land on one of two extremes.

    On the one side, you have the Steve Jobs/Henry Ford take on customer needs and wants. Jobs more or less thought customers had no idea what they really wanted, and he (and Apple), had to create that want by building amazing products that met that need (that the users didn't know they had). Ford is famously quoted as saying that if he had asked customers what they wanted they would have replied 'faster horses', instead of reliable and affordable automobiles.Ford

    The other extreme, and one seen traditionally in lots of workplace kinds of technologies, is for developers and designers to build just exactly what customers request. This approach is mostly an outgrowth and evolution of internal IT shop's tendency to build custom applications based on a list of documented requirements from the end users. If the feature was in the requirements doc, it made it into the product. If not, then the capability didn't get built in the delivered product. And the IT response to downstream complaints was always, 'Well, it wasn't in the requirements.' 

    So what is the best, or most effective middle ground between Jobs/Ford (customers don't know anything) and the traditional IT (customers HAVE TO know exactly what they want) approaches?

    Maybe the best approach is summed up in this recent piece from the O'Reilly Radar site, 7 User Research Myths and Mistakes:

    The most common reason people give for not talking to users is that “users don’t know what they want.” While that’s sometimes true, it’s not a good reason for not talking to them. It’s just a good reason for not asking them to tell you exactly what they want.

    Instead, ask people about their problems. Ask them to tell you stories about how they use other products and how they make buying decisions. Ask them when they use specific products. Is it on the train? In the car? At their desks? At work? Ask them about their lives.

    Users might not be great at telling you what new product they’re definitely going to use, but they’re great at telling you about themselves, and that is a very good thing for you to understand if you’re making a product for them.

    That seems right to me - describing that sweet spot or middle ground between not giving a rip about what users think and the other extreme of expecting the users to tell you exactly what you should build for them.

    Keep this in mind the next time you sit down with some HR tech solution provider salesperson. How much do they ask you and your team about the problems you need to address? How much do they seem interested in what makes your organization work (and unique)?

    And how much do they like to talk about exactly what their product does?

    You are the user. You might not know everything. But you sure know something.

    Wednesday
    Dec172014

    Show and tell

    The 'Steve Jobs was an amazingly creative thinker and leader' anecdotes will seemingly not be stopping anytime soon, and that is probably just fine. One of the latest, and that particularly caught my attention was related in this recent piece on Business Insider, Here's the Simple Yet Brilliant Challenge Steve Jobs Posed to Employees During Product Meetings.

    Here is an excerpt from the BI piece:

    Ken Rosen, a managing partner at consulting agency Performance Works, which worked with Jobs at Apple and at NeXT, shared one way Jobs was able to get the NeXT team thinking about design from different angles. 

    The challenge was simple: each person would bring a product he or she respected into their team meeting.

    "It could be anything, [even] a paperclip," Ken Rosen, who worked in marketing at NeXT, tells Business Insider. "People brought in very different products, from electronics to a paper notebook to a jump rope."

    Jobs wasn't interested in criticizing or judging the employee based on what product he or she brought in. Rather, the assignment was about broadening the way the team thought about product design.

    [Jobs] just really wanted to develop an organization where people knew what good products were," he says. "He wanted to develop a vocabulary and a kind of nuanced sense of judgement about what a good product really was."

    I think this story is cool for at least two reasons. One, it shows a willingness and a predisposition to look for ideas, inspiration, and even answers to NeXT's particular product and design challenges from just about anywhere. Notice Jobs did not instruct his team to bring in examples of their favorite competing computers or even broadly similar products in the electronics family. He asked them to bring in any products that resonated with them.

    Good ideas can come from everywhere, anywhere really.

    The other reason this story is cool is that it probably helped Jobs understand better the point of view and the design sensibilities of the members of the NeXT team. It is one thing for a team member to sit in a meeting and offer comments on a design sketch or a prototype, but it is quite another for that same person to carry in an object or a product and explain to the group what it is about that object that they find compelling. The exercise wasn't really about rating or evaluating any of the particular objects that the team brought in, but rather to think and see what good product design really was.

    Fun story for sure. Probably something worth trying sometime in your shop as well. And of course after reading I had to think about what product or object I would bring in for workplace show and tell...

    Hmm. I do love my little Acer Chomebook, (used to write this piece). I also might consider my Adidas Superstars, (classic sneakers for the uninitiated).

    Good question.

    What would you bring in for show and tell?

    Wednesday
    Nov192014

    There's more to User Experience than usability

    Here is a quick take and a diagram on UX that I wanted to share on a cold, kind of snowy Wednesday in my part of Western NY, (and thankfully not too snowy, lake effect snow is a funny thing, one side of town can get buried in snow, while a mile away sees hardly anything at all).

    I was plowing through my Feedly last night, (while watching my Knicks fail, admirably however in Milwaukee), and I came across this really interesing piece on API design from the Nordic APIs site. 

    I know what you might be thinking: Really, you must have a terribly exciting life, reading about API design and watching basketball. And you would be right! It is terribly exciting. 

    You don't have to read the entire piece about API design, (I admit, it gets a little ponderous near the end if you are not really, really into APIs), but I wanted to share what I thought was the most interesting and perhaps relevant part of the piece, a diagram called the UX Honeycomb, originally developed by Semantic Studios. The diagram is meant to portray the facets or elements of User Experience, and as you will see, there is much more than 'usability' at play here.

     

    The point of the UX Honeycomb is to make sure that designers understand the various components that encompass UX, and to also emphasize the center element - 'Valuable'. So while for UX professionals, 'usability' remains important to overall UX, it is not by itself sufficient. And it is also a great reminder that the elements like 'useful', 'accessible', and perhaps most importantly for HR readers, 'credible' remain critical.

    And the way that the elements of the UX Honeycomb seem to have really close applicability to lots of what HR in general and HR technology projects in particular is the primary reason I wanted to share the diagram. Whether it is a traditional HR-led initiative like training, or performance coaching, or rolling out a employee wellness program, or a straight up HR systems implementation, evaluating your approach against these UX elements I think makes a ton of sense.

    Is what you are doing, or trying to get others to do, useful, usable, desirable, credible, valuable, etc.?

    I think you have to be able to check 'Yes' on just about every one of the elements on the UX Honeycomb no matter what the project is, in order to have a chance to capture the attention and the time of your users, employees, and leaders. I am going to keep the Honeycomb in mind moving forward, and I think you might want to as well.

    Anyway, that's it.

    Stay warm out there today.

    Monday
    Aug122013

    The Progressive Service and re-imagining the organization

    There are lots of fantastic aspects of being a college student - the parties, the football games, the almost complete lack of real responsibility when compared to what often comes next - the corporate world, the 9-to-5 grind, and trying reasonably hard not to screw up, (after all, all that fun in college came with a price tag, probably in the form of tens of thousands of student loans to pay off).

    But besides all the obvious fun and cool elements of student life, there is at least one other - the chance to work on projects, develop ideas, and present provocative concepts all safe in the knowledge that these ideas will usually be evaluated mostly on their creativity and inspiration, and not out in the real world where at most organizations they are likely to be met with 'That's not how we do things here' or 'That will never work' or 'Who are you again?'

    And out in the real world massive, transformational organizational re-designs almost never actually happen (and work). There is so much legacy baggage, locked-in contracts and structures, and often a substantial level of resistance to change that the change that anyone tries to make to an entrenched institution is usually incremental and small in nature.  All change is hard. Big change is just about impossible to pull off.

    With all that in mind, I recommend taking a look at a student project that focuses on the kind of massive change that is normally only talked about in the detached, theoretical setting of academia. The below presentation is titled United States Postal Service Thesis, and was created by Tom Calabrese for a Masters program. The deck, which presents some ideas and kind of radical concepts for the US Postal Service of the future, is below, and I'll have a quick comment/challenge after the break.

     

    Did you click through the deck? What did you think?

    A couple of things stood out to me. One, that providing, for a price, the ability to refine and tailor your own mail delivery preferences is an idea worth pursuing. And two, the more radical idea about somehow connecting the Postal Service social graph to other, more higher value add services and products.

    But the real reason why I decided to post about this was not any of the specific proposals for the USPS, but rather as it was a great reminder that we almost never spend any time thinking about re-imagining our own organizations in a similar manner. Now certainly most of our organizations don't face the same number and type of daunting problems the USPS faces, but it's also certain that we underestimate the problems, (maybe ones that have not yet even manifested), that face our organizations.

    So the challenge is this - what if you could (or had to), completely re-imagine your workplace?

    What if you were to start from a blank sheet, or close to it, and start over?

    What would you keep? What would you let go? What are you doing simply because of inertia and tradition and internal resistance to change?

    What would the 'new' organization look like?

    Have a great week all!