My recent venture into consulting has allowed me the privilege of working with a talented UX team. The interesting thing is I probably fell into a trap and misconception about their roles and responsibility like any other developer that has not worked with a group containing this specialization. I rack that up to lack of 1st hand experience, so I've appreciated the onboarding of more knowledge. While this may not be the 'perfect' account of the UX professional's world, it's hopefully at least insightful to the large community of developers in a similar position to me.
Recently on our company Yammer site I saw the following quote by my friend and colleague Anthony Handley:
STOP staying UX/UI. It's just UX.
This had me thinking to the previous times I had Googled Bing'd the phrases "UI vs UX" or "difference between UI and UX." These were turning up abstract and sometimes confusing explanations. One link I pulled up was probably the equivalent of a 30 page document! Is it that complex? Other descriptions would say stuff like "the bike is a UI and the user thinking about the purchase and the tire size is the UX..." OK strike 1 - awful explanations and I like metaphors and analogies typically. I still didn't get it.
I was beginning to notice it is taboo to say the wrong acronym. To me I had always called it 'UI'. I consulted with another talented UX colleague of mine, Mickey Moran-Diaz for some consultation and education recently to make sure I didn't say the wrong thing. The resulting information I think built my knowledge to a point where I have a better understanding.
The UX is everything. The UI is only a couple of aspects of the UX. Simple enough so far? Good.
A document I found in my searches highlights this well: UX is not UI. Take a look at the document on that page - it details in a single page all of the aspects of UX vs. UI. Notice how UI is only 2 very fine details withing the broad scope which is UX. This aligns with my friend Anthony's comment - "It's just UX."
This got me to thinking - why all the defensiveness that I've seen from UX people? I started to suspect that these talented group of folks were having their jobs being belittled/simplified to wireframing textboxes (see my post on Pencil for those devs that work alone). I come to find out this was at least partially true, and hence the passion of the UX team behind defining and making an understanding of the vast world that is UX.
This unfortunate simplification of an industry or profession albeit wrong, is quite easy to do. Think about it. "An accountant just adds numbers." "A pharmacist just puts pills in a bottle." "Playing basketball is just a ball going back and forth on the court." All simplifications and not realizing the entirety which makes up those professions. As typical it's "more than meets the eye." UX is much more than just wireframing a design.
UX is a multitude of practices, procedures, research, design, thought, artistry, and many, many more things that make up a being a UX person or team. The document in the link I provided above lists many of those aspects: research, design, brainstorming, requirements, interviewing, prototyping, and the list goes further. The bottom line - don't simplify the UX profession as a group of individuals that produce wireframes for a 'UI' design.
I also found that a lot of this conversation revolves around the context for which it is used. When it comes to a individual professional, team, or practice - it is just UX. However, in the context of an application's architecture I was beginning to be afraid to even call the topmost layer in my app 'the UI layer' anymore wondering if that was incorrect. With a sigh of relief, it is not incorrect. When speaking in a technical sense and distinguishing layers it's acceptable to still label it as the UI/Presentation/Views/etc. layer. In this context, it has nothing to do with the UX process or team, but rather to a technical distinguishing of logical layers in building an application. Cool, I can still say UI layer!
My experience though is the reality of the situation revolves around the fact that there are a ton of developers out there in ratio to UX professionals. As for myself I never had the privilege of working with a UX specialist at any job I've held until currently. This to most organizations (unfortunately) is seen as a 'luxury' position in addition to being misunderstood slightly and therefore does not have a presence. It probably falls in line with positions like DBAs where many companies do not hire them either. Developers do everything and hence the natural ignorance around these specialized positions.
Hopefully if you get the opportunity to work with a UX professional or team you will now as a developer or IT professional have a brief insight into the vast realm of responsibilities and expertise those in this field entail. It absolutely is much more to be a UX professional than simply doing UI design.
I've often pondered over, discussed, and lightly debated the process of designing small applications and the extent to their architecture and implementation. Usually the conversation surrounds doing it 'quick and dirty' vs. creating a 'well built and thought out' application.
Think of this old saying:
Why do we use that saying? The idea is if you do a job hastily, it will have to be thrown out and started all over again. On a larger scale maybe something like this could occur :P
This is not unlike the process of building software. Odds are if you build an app poorly to try and save time, or create a 'throw away' app not supposed to be used in production both situations will yield a front running Enterprise application. Well, not always but it happens more times tan one probably realizes when making these decisions. If you create a poorly made application, there is a strong likelihood in the future that it will also be 'thrown out' and targeted for the old 're-write.'
I know in my years of experience I have opened many of applications of all types (web, desktop, services, etc.) that were a huge mess of code. No wonder the passionate in our industry scream from the mountaintops about things like code standards, design, architecture, OOP, unit testing and the like. Who in their right mind with any experience places 1000 lines of code behind a form with a mix of binding, rules, data access, service calls, etc. that cares about the craft of software engineering? All this does is create a pile of frustration for the next developer to jump in someone else's mind to figure out their goo of an application mess. And is there ever any commenting to help with the goo? Of course not, these same developers believe that code should be 'self-documenting.' Yes thank you, please leave me the manual to your brain so I can decipher the poop you wrote, thank you.
So why waste time with re-writing application, if we can do it right the 1st go around? Well typically this scares those concerned with timelines, as doing an application properly is perceived to take longer to create.
"Ah this is just a little old app, do we really need that fancy design?"
Yes. Or at least closer to 'Yes' than 'No'. In the end the word 'fancy' or 'complex' is overrated and misused anyway. It's cheaper to do than you think. Let's make a real-world example to discuss. Say we are tasked with creating a small web app with a few pages pulling data from the database and in the midst we need to apply a few simple business rules. As usual, it needed to be done yesterday.
1st let's say we choose to use web forms because of it's plethora of server controls which lend themselves to RAD. You could just as easily say WinForms, WPF, or MVC here as well. MVC would naturally have a leg up here because of it's M-V-C architecture that helps start us on the proper path of separating our concerns. However we could still have fat Controllers in MVC and be in the same conversation, so the technology choice here is not the main focal point. We can screw up the implementation using any technology.
Using web forms though we might be tempted with our objective to use one of the more robust data binding controls offered that includes built in data access methods. On the other hand another quick approach would be to use basic server controls and fatten up the single code behind file to get all the requirements complete and done quickly. All of this are poor decisions that are leading us down the path I described earlier.
I'm not advocating for a full blown Domain Model or Onion Architecture, but a simple 3-layer (UI-BLL-DAL) architecture is leaps and bounds better than a code behind file with 3000 lines of code. If you are an experienced developer or have experience designing apps, how much longer does it truly take to set up the additional logical layers?
Let's see:
- Right-click, 'Add New Project' (BLL)
- Right-click, 'Add New Project' (DAL)
- Add references to new layers, create a few classes for busniess rules and data access.
OK, so this is the super simplified steps but in reality how long does it really take to add a few layers and segregate the application code? Maybe 1/2 day to 1 day for a small application. Possibly a few minutes to hours is more the reality. If you have used this in other applications, there will be some copying and pasting of basic logic (if not already refactored into a common unit) and visually copying of solution structure to help speed things along.
What's the payoff for this small bit of work up front? A MUCH better and well understood application, as well as an application that can scale better and stand the test of time longer. Splash on some code standards and common best-practices and we are making giant strides toward a better application.
I think the reality and success to this is having engineers/leaders/etc. with some experience doing this to articulate how easy this process is. Inexperienced engineers combined with nervous management concerned with timelines will most likely 9 out of 10 times agree together that the 'quick and dirty' route is a great option, and sell themselves on this idea because it's a small, unimportant application. The term 'architecture astronaut' or 'over architechting' are common buzz words that kill a good design and make those in charge feel good about essentially creating sloppy applications.
The summary of my experience is dealing with these poorly written apps is frustrating, and 5x time consuming in the long run as opposed to working on a well laid out application, no matter the size of the application. Since the cost of doing it 'right' or 'better' is so cheap up front, why not just do it? The answer should be that there is no excuse or discussion around not building applications with a well thought out design. The thought process should be applications small to large will all be done well, to prevent the known and true pitfalls that exist when creating applications 'quickly' to save time (which is an oxymoron by nature).
