Recently I left JPMorgan Chase and New York City, to try my hand at a new locale and job. Back when I completed school, I had that cliche decision to make, New York or San Francisco–why not both. After three years in New York, it was time to give San Francisco a go. Seeking to work on more publicly facing internet products, the decision to head for the bay area was easy.
And as for work, soon I’ll be joining the great folks at LinkedIn.com as a UI designer.
Earlier I had discussed the topic of only solving the surface problem instead of digging deeper into the real problem. The “Reply to All” solution has now been accompanied with other surface solutions to ’solve’ more email problems.
As an organization that deals with sensitive information, the leaking of such information even if accidental is a major concern. And one of the possible ways this information can be leaked is via email to external addresses. In an effort to thwart this issue, a design change has been made to the email software (shown below), which requires users to specify whether their email is being sent to internal recipients or internal and external recipients. If the user fails to select that his email is being sent to external recipients, he will not receive any indication that the email was not delivered.
I cannot ascertain whether additional screening measures are performed on emails which are defined as being for external recipients, but based on communications about the changes, it appears they exist as a means of reinforcing how to properly handle sensitive information (i.e., it most likely shouldn’t be sent to external people). Certainly an odd way of communicating of this though, as users can simply always just select internal / external e-mail just to feel safe that their email will be sent. This is especially due to that by default users will be given the impression their email is being sent when in fact it essentially may have never made it past their outbox.
As an aside, the changes are having an interesting side-effect: as emailing becomes more of a pain to do, alternatives such as IM are becoming a seemingly easier option.
11 15 07Sweeping the dirt under the rug, putting a new coat of paint on an old car, opting for a diet coke and calling it healthy living are all solutions to surface problems that never truly solve anything. They’re the easy and quick things that we think can actually make a difference. Just like in any other space, in software design we see solutions to surface problems passed off as answers to greater issues.
My workplace has a culture of excessive email CCing, which I’m sure exists at many other people’s companies as well. As a result, many people complain of bloated inboxes with emails which may only indirectly involve them. The probelm is the culture of blindly CCing–a result of people wanting to cover their bases, an irrelevant email to someone is easier to deal with than a missed email to someone important. And as such, an email propagates, recipients “Reply to All”–resulting in an exponential increase in email that may be irrelevant to a fair amount of people. Often this fact is made apparent by the amount of people who reply to all, pleading to be removed from the email chain. Chain is probably a good word for this too, as users literally feel they become chained to email.
So how does one solve this issue? For the IT staff it was by creating a new dialog box which prompts the user to confirm whether he truly wants to “Reply to All”. Sadly, this only attempts to solve the surface problem [people simply replying to all], as opposed to delving into the true root of the problem; that of the email culture of CCing a swath of people without regard for taking into consideration if all people need to be included. Instead, users are now left with an additional step, that solves nothing, in order to reply to an email, even if replying to all consists of only two people.
[note: The email protocol as an effective collaboration tool can be debated as a greater root problem.]
The previous example is mostly a minor annoyance and for the most part, people will get on with their activities without much of a hiccup. A more pertinent example, which ultimately had greater consequences, involves the often challenging user authentication process. If a user who should have access can not get access, it is a major problem, one which as time elapses grows even greater. The issue at hand was that a “Forgot Password” function was taking an excessively long time to email the user the link to reset their password. As such, users, after waiting hours, assumed something was wrong and that they should call tech support. This resulted in an excessive amount of calls to the tech support call center.
What is interesting is that the call volume was perceived as the problem. First, they needed to figure out how to stop users from calling about forgotten passwords. The solution was a quick fix, a message was put in place next to the tech support telephone number:
Not for forgotten passwords
It was a very out of sight, out of mind solution. It took care of the surface problem, calls reduced, but the true problem still persisted. Users now had little recourse in finding a way to get back on track. Worse still, was that now, the people who should care don’t even hear the users since they’ve turned off that avenue of communication. Luckily, many people refused to follow the directions provided and called anyways.
During a user interview, a user may describe what they don’t like or why they don’t think it works. And while observing a user in a usability test it can be easy to identify what they get caught up on. The natural instinct is to “ease the pain where it hurts”, but often in software or product usability the problem’s cause could come from an array of different areas.
This isn’t news, but when design decisions such as the ones I described keep occurring it is good to remind ourselves about spending that extra time to think deeper about what we are solving.
10 29 07
I recently discovered that my co-workers have been secretly keeping a running list of how many usability rants I have a day. I won’t lie, it is a fairly common occurrence and an activity I recommend for anyone in the industry. Often my rants are five minute manifestos on why something is designed poorly and what needs to be changed to rectify the situation.
In order to push that agenda for designing more usable products you need to be as mad as hell and let it be known–in the politest manner possible. Being irked on a daily basis, as frustrating as that sounds, I find to be paramount in the ideation process.
08 31 07
It’s apparently a good time to be the CEO, according to Portfolio.com. Most recently CEOs have been making 465 times the salary of their average worker. Compared to only 28 times in 1970.
I think this sums up the response to that age old interview question of where you want to be in 5, 10, or 15 years.
08 21 07User experience professionals seem to be in fairly good demand it appears. I only say this due to the amount of recruiter calls I receive. Typically 1 every other day. Lately though they have really stepped it up–calling my mobile phone, calling my office phone (by way of dialing the company switchboard), and emailing me.
Everyone gets the call saying that a friend or colleague had referred them and by the way they want to remain anonymous. But recently I got a call that topped that them all simply by being as ambiguous as possible.
08 01 07Hi Bryan, this is Ron Gold. I’ve got something important to talk to you about. Call me back at 1-888-555-5555 ext 106
Having recently listened to the NYC CHI talk on UX career paths, I heard some interesting revelations on the perceptions of IA portfolios and gauging ability.
The greatest issue with IA portfolios seems to be that an IA can do many different things and as such their deliverables can be an assortment of artifacts. We see everything from a swath of wireframes to requirements documents and sitemaps, possibly personas or interaction flows–all of which are not necessarily glitzy. There is no one set of expected portfolio elements.
In fields such as graphic design, industrial design, as well as writing there are those portfolio pieces which are a given that they will be shown by any prospective candidate. Not to mention the context is often simpler to grasp for those fields. Attempting to briefly describe the interaction flow of a financial application to a layman can be complicated, unless reduced to simple constructs, at which point a fair amount of relevance is lost.
Kevin Kearney, of Razorfish, spoke of this portfolio issue in terms of hiring, stating that many times it is kind of a toss up and that you hope you make the right choice. But how you make that choice has a lot to do with seeing how a person performs, not necessarily just by looking at previous work. While probably not sitting a person down and asking them to design an application, at the least discovering how they tackle the common design challenges that arrive daily. This is even a time to determine how they work collaboratively, as a great part of designing is the discussion and how well someone handles that.
Similarly, members of the IxDA mailing list have spoken of this matter too. Noting the fact that a lot of great candidates may be passed over as a flashy portfolio is needed to even be considered.
What matters most is very simple, how a person thinks. They need to have the desire to learn, to be annoyed by things and have the drive to want to solve problems.
07 13 07With the Fall semester of school already underway you can probably tell by the lack of updates that I have been inundated with work. Currently I’m working on a few projects which include a fair amount of writing; pleading for grant money and asking for acceptance to conferences.
So I have found myself lately hanging out at various places doing work because at my apartment there are just too many distractions. So I just felt that I should give thanks.
Espresso Royale Cafe
And my soon to be new home: Penguin Pizza
09 26 04
FourSedgewick Interactive has been hard at work revamping The Dating File and bringing it back to life. After a long hiatus we’re ready to bring the site back with a souped up engine.
The release brings along a new standards compliant design featuring XHTML 1.0 Transitional and CSS 2. As well as prominent use of PNGs and alpha-transparencies. In order to discuss the benefits of standards compliant design I’ve provided a bit of analysis between the version 4 site and the newly released version 5.
Being an aggregator site visitors will only spend a short period of time at the site, they may even leave before it finishes loading. That was why we needed to trim down the download time but still keep the same look and feel.
The Dating File previously sported a table based layout for presentation. Which required a lot of slicing of images to get the desired look, which left us with severe image bloat. Not to mention wasted bits on non-structure tags used for presentation.
The previous version featured unique rank, star on, star off, and join images. In order to get our color fade this was the only way possible since transparent gifs would suffer from rough edges.
The use of valid valid XHTML markup and CSS helped reduce the tag overload induced by using a totally table based layout. Separating presentation markup from structural markup also aided heavily in terms of SEO. By presenting search engine spiders only with structurally marked upped content the site gets a better rating in terms of semantics. For instance our logo is actually an h1 tag which has a higher ranking than say an img tag.
In response to the excessive image use we capitalized on the features of the PNG format and its alpha-transparencies. The use of PNGs allowed us to trim 20 unique images down to just 4. Unfortunately our user base is primarily Win/IE users and alpha transparency images and Win/IE do not play well together. Fortunately Justin Koivisto’s IE PNG Hack provided a nice workaround which did not affect other browsers which do display PNGs correctly.
Below is a comparison between the previous version and the current version in terms of download metrics.
| Version 4 | Version 5 | |
|---|---|---|
| Size of webpage | 19.3K | 9.1K |
| Visible text size | 2.1K | 1.2K |
| Size of html tags | 17.2K | 7.8K |
| Number of images | 58 | 33 |
| Unique images | 45 | 10 |
| Size of all images | 27K | 12K |
| Grand total | 46.4K | 21.2K |
As can be seen from the grand total we’ve optimized the site by about 46%! We’ve cut the download size almost in half, without compromising the visual display.
07 30 04The guys from 37Signals have an interesting post on their blog Signal vs. Noise about hourly rates for development work. It is obviously mostly in jest but it says a lot about the way developers feel about clients getting their hands in the nitty gritty of development. For wow factor I’ve listed the rates below:
The most interesting aspect of this is the rate for if you worked on it first. I totally understand why it is the most expensive because many clients always feel that since they have already done some work on it they feel that it will be done quicker and that for the developer it will be easy. I saw this all too often when I worked with clients who were somewhat tech savvy. They would run a huge document through Microsoft Office’s Save as HTML feature and think they were doing us a favor.
It’s a funny list of rates but it it definitely makes me realize that everyone in the field runs into these same kinds of situations with clients.
06 14 04