Killing Perceived Perf by Trying to Help It

This post by LukeW illustrates perfectly something that I have seen as well. Death by a thousand progress indicators. As he notes, the well-intentioned desire to show progress can actually emphasize that things take time. Watch out for that–you may want to try other approaches instead.

Keep Hammering that Responsive Web Design Square Peg into the Round Good Design Hole

Seems like every day I see a new article talking about the challenges of Responsive Web Design. And tellingly, the discussion of the challenges appears to be more in the context of just basic Web sites, that is, more information oriented sites with relatively straightforward page-to-page navigation interactions. From an interaction design perspective, such solutions are comparatively simple, contrasted against your average application, which typically involves significantly more challenging interaction design problems–just for one device class.

I have speculated before that Responsive Web Design is a lie. While that is a bit of hyperbole, the reality is that the fundamental idea behind the RWD technique is flawed from a Design perspective. It is purely a pragmatic concession, and as you can see by the many pragmatic challenges to even rather basic solutions (information Web sites), not to mention the typical huge bloat it causes, one just has to wonder how long the industry will keep trying to pound that square peg into that round hole.

We can make ourselves bigger, stronger hammers. We can use bores to make the “hole” bigger, but at the end of the day, it’s just a flawed technique. You can’t get to a great experience with a one-size-fits all solution, and you can’t reasonably manage many customized experiences with a single code base. Oh, and that’s on top of the Web platform, a platform that is, at its best, still immature from an application platform perspective.

Call me a party pooper, but that’s the reality we are saddled with. I think we’d be better off focusing our energies on just making it easier to design and build awesome solutions for individual device classes at a time, and looking at more manageable ways to share sharable assets between device class solutions. There are tools today that help, but we are far from an ideal solution.  But at least that approach isn’t fundamentally flawed, i.e., it is possible we will get to a good solution. Not so with RWD.

Adobe Tools Are Not UX Designer Tools

If you’re looking to hire a competent UX professional, do not ask for “Experience with Adobe Tools” in your job description. Especially don’t ask for PhotoShop. Even visual designers are waking up to the fact that PhotoShop is not a good software UI design tool.

UX design is a distinct skill set from visual/graphic design. They are complementary, and some UX designers are competent visual designers while some visual designers are competent UX designers, but they are still distinct skills, much like development is distinct from design.

A UX designer should basically never use Photoshop. Illustrator is a decent hackable tool, but if you’re going to go that route, you might as well just use OmniGraffle. Still, all of these are basically just for static wireframing/UI comps, with varying levels of hackability to communicate interaction design intent. Adobe had an interesting UX design tool for a while–called “Flash Catalyst,” but they killed it, because they killed Flash (I deduce).

If you’re going to pick a software tool for interaction design, it should be one that is suited to exploring interactions, which implies interactivity, i.e., as a designer, I can say, “when a user does <insert name of user action here>, the app should do this…” At a super bare minimum, clicking should be supported, but seriously, what viable apps these days only support static, full-page/screen refresh navigation?? So then you get into needing to explore and express transitions and animations. I’m not talking about fancy dingbat silly animations. No, I’m talking about animations that help users understand and interact effectively with a given UI design.

At this point, the software tools that your average competent UX designer can grapple with get reduced. You can of course code prototypes, but that’s generally not the best idea. So you want a tool that allows a UX designer to explore and express user interactions and app responses to those interactions but doesn’t get them bogged down in code.

Now I am biased having worked extensively on it, but the only tool that really qualifies there is Indigo Studio. Sure, Axure is another alternative, but it is significantly more complex to use and tied to the details of the Web platform.

So if you’re going to ask for a software tool competency for a UX designer, pick one of these. But really, as long as a UX designer can effectively explore and communicate design ideas, it doesn’t matter what tool they use. If you are constraining them to specific tools, something is wrong with your process. What you need to look for is evidence of good designs–both designs and implementations, as well as evidence of design research and evidence of design evaluation. Ask about their process and techniques they use to discover the best designs. Just don’t ask for Adobe tool competency.

I’m My Own Worst Enemy

I Can Code

I’m something of a freak, though certainly not unique, in that I started my career in software as a developer and am now far more on the Design/UX side of things. Not only that, but I was one of those untrained/uneducated ones with no CS degree that jumped on the dot-com-bubble wagon to break into the industry. For years, I worked my way up through the ranks, learning on the job mostly with the smattering of self study here, conference/training there.

So it was only natural to me, when given the opportunity, to jump on the UX bandwagon several years ago. Again, I find myself a foreigner with no formal Design or HCI or library science or psychology education (but hey, I did take Psych 101 in college!). But I’ve done a good bit of self study, here and there under the mentorship of “real” UX pros (ya know, the ones with the PhDs and MAs and such). I now have several years of experience under my belt, and I had something of a unique opportunity working on Indigo Studio, an interaction design and prototyping tool, to really research and study the discipline/practice/field of UX and Design. That opportunity has given me a lot of exposure and insights into UX/Design that I know I wouldn’t  otherwise have.

UX for Devs ManifestoAlong the way, I’ve been (and still am) an advocate for developers spending time and effort learning about and practicing, when necessary, UX principles, techniques, and processes. This is because today, still, the vast majority of software being built does not involve UX professionals, or if it does, their role is often minimized and marginalized (they have to fight for their lives, or at least for good UX). In the end, devs, being the ones who build the stuff, have dramatically more influence in most cases over the actual UX of software. This is not going to change anytime soon. Maybe not ever. It’s reality. Deal with it.

And yet! And yet, despite my position advocating for devs “doing UX” and despite my bad example as a dev turned UX guy, I have learned enough in these many years to know that designers are indeed a different sort of animal. They think differently about problems than devs–significantly so. They employ different approaches when tackling issues. Heck, there’s a whole thing called “design thinking” that has sprung up around this notion. And not only that, just like every other professional, professional designers learn and hone their expertise over years as they practice. It really is a profession, a discipline, a field of expertise.

And that brings me to the image at the top of this post. (This is an actual shirt I made at one of the T-shirt sites.) It’s funny on a superficial level, and on the level that people can remember actually writing BASIC programs like that. But the underlying thing is–does being able to write lines of code really mean “I can code!”? Does that put me on the same level as an experienced and (possibly) formally educated developer?

That’s patently and obviously absurd–being able to perform one (or even some) of the basic functional activities involved in a profession does not make one a professional in that discipline. Do people who can give themselves shots claim to be doctors? Do people who represent themselves in court for a traffic citation claim to be lawyers? Does being able to shoot a firearm make me a policeman? Obviously not! I can install GFCI outlets like nobody’s business, but I hardly consider myself an electrician.

And yet this is precisely the attitude taken by those who dabble in Design. Being able to sketch UI ideas on a whiteboard doesn’t make someone a UX professional, but you’d never know that by the way people are eager to second guess and criticize professionally designed UIs or by the way they clearly think that their opinion on a UX design is as weighty as a seasoned UX design veteran.

This is particularly troublesome when dealing with what I’ll call “design smell” (lifting the concept of “code smell” from the dev world). Sometimes–often–an experienced designer can consider a design and immediately tell there is something off about it. Sure, there are heuristics, and principles, and testing, and metrics, and so on that can give definition and language to talk about the bad smell, but not always, certainly not always to everybody’s satisfaction.

Maybe they subconsciously recognize things about it that are just asking to go wrong, based on their distilled knowledge, skills, and experience. Or maybe they had more exposure to what went into a particular design–so what is being considered is something they already explored or something conflicting with their sense of propriety for the problem at hand in the context it is in. The bottom line is, maybe the designer can explain it in a way that resonates convincingly with others and maybe not. But sometimes you just gotta defer to their judgment and rely on their expertise. 

My Ivory TowerNow don’t mistake me. I’m not suggesting the all powerful designer dictating from on high, but judging from a very common theme amongst designers–complaining how everybody thinks they’re designers–I think it is safe to say we are squarely on the other end of that particular spectrum, especially in software. People–particularly those who consider themselves smart and talented (and maybe are)–naturally assume that if something doesn’t make sense/resonate with them, then it must be wrong.

And yet, when those same people think about it in terms of their own expertise (or maybe other expertises they have less of a clue about), they obviously can see that people should respect their expertise and defer to them. Something is broken here. What I’m suggesting is that those who work with designers need to keep this in mind and move the needle further to the respecting designer expertise side of the spectrum.

The fact that I have made this transition from dev to UX pro makes me my own worst enemy in this argument, though. What folks may not think about is that this multiyear, full-time professional journey has really warped my thinking. I may not yet (or ever) be in the same mindset as a formally educated, “untainted” designer, but I have had a lot of time and opportunities that have changed my thinking and given me a lot more Design knowledge and experience to draw on than I had before I started this journey.

And despite that, I maintain what I consider to be a healthy seed of doubt as to my own tendencies when it comes to tackling problems and designing solutions using, shall we say, a pure/disciplined Design approach. And if I still do that after years of practice, self-study, and mentoring, maybe folks who lack pretty much any background in UX should doubt their own design skills and defer to experienced designers?

LOL. Who am I kidding?!? Everyone’s a designer, right?

Antipattern: Forms Over DB

Any experienced business software developer knows that CRUD makes the world go round. For those who don’t know, that stands for Create, Read, Update, Delete. It’s the bread and butter of many business apps, the transactional ones that exist to, essentially, manage business data. Oodles and oodles of apps exist to do just this, and that’s it.

It’s fine, in and of itself, because it works, as a bare minimum. It’s also fairly boring to code,as a developer. It gets tiring writing the same code over and over and over again. So, these smart folks who get bored with basic CRUD start inventing ways to make their jobs more interesting.

What this looks like are things like auto-generating CRUD forms “scaffolding” from a database. It looks like ORM–object-relational mapping, where the objects are similarly generated from a DB. And all sorts of variations on these themes.

The problem is that in an effort to not get bored, to not “waste time” with boilerplate code, these solutions miss the mark. The intelligence and creativity of these highly skilled individuals is being squandered. The essential problem lies in the requirements themselves.

When you conceive of software as, essentially, a portal to edit database records, the potential of that software is immediately and fundamentally warped and diminished. It presumes an antiquated interaction model, one in which the database is some angry pagan deity. The people must bring their offerings of information, feed it to the all powerful database, hoping that at some later point, they can return and request some meager insight from the oracle (pun intended).

It is an immensely impoverished and impoverishing view of how software can help people do business. We need to move beyond these primitive interaction models. We need to understand the flow of business activities–from a human perspective. Instead of looking for points in a business process into which we can inject these artificial, software/database-oriented data offerings and petitions, how can we make software feel like it is part of what people are trying to accomplish? Their goals are most assuredly not to create, read, update, and delete records in a database. Their goals are to achieve some human end, and they put up with CRUD type interactions as a means to an end.

The closest thing I’ve seen in the dev side of things to a more human-oriented design was SOA. At least it attempted to frame the design in terms of what people were trying to accomplish. Domain driven design also heads in the right direction, and to some extent, so does “object thinking” that tries to focus more on behaviors and less on data and properties.

But a more robust approach to understanding and formulating a high quality software design is one that follows one of the many UX/Design approaches. There are many, many resources out there for devs and BAs to learn how to improve their design process and “learn UX”; I myself have written much along these lines and given many presentations. I tried to distill this into practicable principles recently in my UX for Devs Manifesto. My company has released a currently free interaction design tool that any dev or BA should be able toque kilt pick up and leverage in an improved design process.

There’s no good reason for us to be continuing with the Forms Over DB antipattern today. In addition to warping software design from the get go, it also leads to other “efficiencies” like auto-generated validation with its inscrutable error messages and subpar input interactions. The good news is that there is a better way, both to get to a better result and to offer a more interesting, more intellectually challenging software design problems that keep us from getting bored and wasting those energies on ways to more efficiently create poor user experiences. Further, we are more empowered today than ever to craft awesome, well-designed software thanks to the technologies and tools available to us today.

Just say no to this antipattern. Work with your managers and BAs to fix the status quo of requirements that engender this antipattern. It can be done, and everyone will be better off for it.

–written from my iPad mini in a session on scaffolding 😉

Yes, Ditch Traditional Wireframes, But Not for Code

Just Say No To CodeI just ran across Ditch Traditional Wireframes in UX Mag. I agree with the basic premise–that static, especially high fidelity, wireframes should be eschewed, but the conclusion I draw about what to do instead is a bit different.

The author of that article, Sergio Nouvel, propounds the wonders of just jumping right into code by doing HTML-based prototyping after nailing down initial concepts with other low fidelity options. The problem is that Nouvel does not identify the drawbacks from such an approach:

1) Despite the relative ease that frameworks like Bootstrap and Foundation provide, jumping into code has the immediate effect of warping the designer’s mind. I don’t care how disciplined you are, when you start dealing with code, your brain is forced to start thinking from the code perspective. It is not acceptable to switch at the interaction prototyping phase from a human-centric focus to a code-centric focus.

2) Especially in non-WYSIWYG environments, you are forced into imagining what tweaking this bit of markup, CSS, or JavaScript will have, then you do it, and then you verify it. And you often find it’s not quite what you had in mind, and repeat. With that, you end up wasting a little time here, a little time there, a little time everywhere fighting with the technologies just to do the simplest things.

3) It forces the designer to learn to code. That is a double-edged sword, as I discussed not long ago in To Code or Not to Code.

4) To be truly easy to maintain and change takes a LOT of planning up front. Even developers struggle with this, and they’re all about reuse and minimizing effort for changes. To pretend that just using code means things are automatically easy to maintain is just wishful thinking. Sure, maybe changing a font color, but changing shared navigation, layouts, etc.–things that are far more pertinent to rapid design iteration–are not easy changes in code. At all.

5) Interaction prototyping is not the same thing as production coding. To pretend that the code a designer writes in a prototype is going to be good for the real product misses several key considerations:

  • Devs are notorious for being picky, and rightly so, about their code (see the last point about code reuse). The chances they’ll just run with prototype code are quite slim, especially if that code relies on prototyping frameworks.
  • The focus of a good interaction prototype should be the interactions, not to have clean, well-layered/encapsulated/maintainable production code. If you use code for prototyping to have “build the real thing,” you’re missing the point of interaction prototyping.
  • Using HTML prototype code as production code only applies, and only sometimes, for Web apps, and simple ones at that.
  • What about statefulness and data? Are you really going to spend time on that in your prototype?  Anything beyond a basic informational Web site needs this sort of thing.

6) Worrying about responsive design at the interaction prototyping phase is premature. We’re in the higher point of the hype cycle for responsive design. Yes, it is nifty for some design needs. But it is hardly a panacea, and more importantly, it (like code or tech) should not be the big thing you’re worried about when doing interaction prototyping.  Why? Because from a user experience point of view, it’s just not that important.  Many of your users will never know if your site is responsive, and very few will care, as long as they get what they want from you.

7) How are you going to share your prototypes? Using HTML means you’re going to need to secure a hosting place, deploy it, and ensure it is accessible for people. And you have to keep updating that. One more thing you have to learn to jack with just to get some design ideas fleshed out and tested, one more thing in your way when you should be simply focused on exploring and evaluating design concepts from a human perspective.

So what should you do instead of static wireframing? Why interactive prototyping, of course! 🙂 Before you shake your head and say it is too hard or too cumbersome, I suggest you try Indigo Studio. Full disclosure: I had a hand in making it, but the reason we made it is because we think it addresses some real needs, such as:

  • The need for rapid exploration of design ideas from a user-centric perspective.
  • Being able to do rich interactions and animations without worrying about code or learning to code.
  • Integrating stories and human contexts into your digital design.

And guess what, Version 1 is totally free, forever.  There is no obligation, no time bomb.  So yes, definitely, ditch traditional wireframing, but not for code. It is good for some needs, but when you’re doing interaction prototyping and design exploration, that’s not the time to saddle yourself with all those ancillary concerns.

Give Indigo Studio a Try!  I recommend watching the videos–they give a good idea about how Indigo Studio is different and tries to address these needs.