Category: Technology/Software
Julie Stanford | 12.10.09
AT&T just announced in an investor’s conference that smart phone users are using too much of its network for data and that something is going to have to be done to curb their usage since their network isn’t able to handle it. All I can say is WAH-WAH-WAH.
Let me get this straight. AT&T has an issue that their network is slow, which clearly is not the fault of the network but is the fault of the users of the network. So, instead of upgrading their network or preparing for the introduction of more smart phones which are going to cripple their network further, they are going to do something punitive to get smart phone users to download less data. And is their plan to do this while still continuing to charge $40/month for data service? They could offer tiered pricing to people so that some can opt into a lower price plan for more limited data, but charging users who are already paying $40 for apparently subpar unlimited service doesn’t seem fair.
As you can tell, as a user advocate, I think this is absurd. Problems with your product are never the fault of the customer. They are your fault. And, most importantly, if you are AT&T and ACTIVELY PROMOTING all the awesome apps and great things you can do with the iPhone while then complaining that people are using them too much, you don’t have a leg to stand on.
This behavior is not acceptable for an organization with a lot of competitors (rumored to be losing its iPhone exclusivity soon) that sells a service. Your goal as a product manager, engineer, designer, CEO, etc… is to make your users happy and not think of ways to save money by pissing them off. It may save money in the short term, but if your business is selling a service, there should be a high level of service involved.
This is a new announcement from AT&T but I predict it is going to lose them customers in the long run. In the words of Stephen Cobert, AT&T you’re on notice.
Laura Klein | 11.04.09
The recent release of Windows 7 got me thinking about development cycles. For those of us who suffered through the last 2+ years of Vista, Windows 7 has been a welcome relief from the lagging, bugs, and constant hassle of a failed operating system. Overall, as a customer, I’m pretty happy with Windows 7. But, at least on my part, there is still some latent anger – if Windows 7 hadn’t been quite as good as it seems to be, they would have lost me to Apple. They still might.
A big part of my unhappiness is the fact that I had to wait for more than two years before they fixed my problems. That’s a lot of crashes and frustration to forget about.
One approach that many software companies have been adopting to combat the huge lag time built into traditional software releases is something called continuous deployment. This sort of deployment means that, instead of having large, planned releases that go through a strict process and may take months or years, engineers release new code directly to users constantly, sometimes multiple times a day. A “release” could include almost anything: a whole new feature, a bug fix, or a text change on the landing page.
I worked with a software development organization that practiced continuous deployment on a very large, complicated code base, and I can definitely say, the engineers loved it. From the point of view of the employees, continuous deployment was a giant win.
But how was it for the users? The fact is, some decisions that seem like they only affect engineering (or marketing, business, PR, etc.) can actually have a huge impact on end users. So, whenever organizations make decisions, they should always be asking, “how might this affect my customers, and how can I make it work best for them?”
Is Continuous Deployment Good For Users?
As with so many decisions, the answer is yes and no. Continuous deployment has some natural pros and cons for the customer experience, but knowing about them can help you fix the cons and benefit even more from the pros.
Big Customer Wins
Fast Bug Fixes
Perhaps the biggest win for users is that bugs can get addressed immediately. Currently, even Microsoft releases patches for some of its worst security holes, but there is certainly a class of non-critical, but still important bugs that have to wait until the next major release to get addressed. That means weeks, months, or even years of your users dealing with something broken, even if the fix is simple. In continuous deployment, a fix can be shipped as soon as it’s done.
Fast Things vs. Slow Things
Similar to the first point, continuous deployment lets you get everything, not just bug fixes, to users as soon as they’re ready to go. Small features, easy changes, and UI tweaks don’t have to wait for larger, unrelated features to be released to customers. After all, should a new design for the splash screen really have to wait on the implementation of a whole new payment system?
More Opportunities for Community Involvement
If you’re having a constant dialog with your customers (you are, right?), they’re probably making some pretty good suggestions about problems they’re having or ways to improve the product. A by-product of the first two benefits is that those users are going to feel even more involved in the development process when their suggestions or concerns are dealt with quickly, rather than if they have to wait months or even years for the next major release.
(Mostly) Avoidable Customer Problems
As with anything, continuous deployment can also cause some problems for users. Of course, some of these problems can exist in big, staged deployments as well, but these are a few things in particular to watch for.
Constant Change
Imagine if every day, the layout on your car changed, sometimes slightly, other times drastically. You want to drive to the store, but the steering wheel is on the other side and you’ve suddenly got an extra pedal. It would make it a lot harder to get where you were going, wouldn’t it?
Well, presumably your users are using your product to get something done, and they’ve got a certain way that they’ve learned to do it. Continuous deployment can mean that the interface for your product can change at any moment, even several times a day. If features constantly appear and disappear, it can be very disruptive to your users’ process.
There are a few things you can do to minimize the disruption. First, make sure that you’re testing your biggest changes on small cohorts of people. Iterate on a subset of your user base, rather than hitting every single user with every single change. This will limit the change that any individual sees while still giving you the benefit of constantly pushing code to customers. In fact, use this as an opportunity to do the A/B testing you should be doing anyway.
Also, and this should be obvious, try to limit your truly disruptive user interface changes so that things don’t feel like they’re in constant flux. You can still change things, but be aware of how frequently you’re making major changes and stay in contact with your users to make sure they’re not feeling dizzy.
Inconsistent UIs
When a big new release is planned, often there is a comprehensive design phase where all the new changes are mapped out and discussed. This means that any inconsistencies in the UI can be found and addressed.
In continuous deployment, different pieces of the product are getting built and shipped to customers all the time, and there is rarely a time when the entire UI is reevaluated as a single entity. This means that sometimes UI standards can tend to…oh, let’s say evolve.
This problem can be controlled by having a UX team member embedded in the development team and constantly working with the engineers to enforce standards before things ship to customers. It can also be improved by providing wireframes, visual designs, and tools like templates to developers so that the look and feel of the product doesn’t shift too dramatically over time.
Avoiding QA
I’m certainly not claiming that every single thing in a traditional release process gets a full QA pass, but I do find that continuous deployment makes it easier for code to slip out to users without any human testing at all. Any time you give engineers the ability to ship code directly into production, you’re tempting fate. Somebody’s going to say, “oh, it’s just a tiny change,” and it’s going to get out without any testing. I’m not naming any names, but you only have to have a tiny change break the entire product once before you realize that there’s no such thing as a tiny change.
Also, continuous deployment can make certain types of testing much less likely to happen. While large release cycles tend to have a code freeze and weeks or months devoted to testing, hopefully including regression, unit tests, and end to end testing, continuous deployment doesn’t necessarily have that baked into the process.
You can always add periodic end to end testing of the product to your own process, of course, and it can be quite helpful in improving code quality, especially when your engineers occasionally slip through a “tiny change.”
Communication Issues
When you’re constantly releasing new features and bug fixes, communication with your users can be a challenge. You don’t have one big release with new help docs, a big roll out plan, and an advertising campaign. Instead, stuff is coming out all the time, and users can get overwhelmed by keeping up with the changes.
Context sensitive help and inline information for each feature can help users get quickly oriented. Also, clearly marking new features as alpha or beta can let users know when a feature is still being developed so they can set their expectations accordingly.
Documentation can also easily get out of date when things are getting released constantly. Big, staged development cycles often have a built-in time for creating documents. Typically, manuals or help documentation and FAQs go through QA sometime after code freeze and before release. But since you’re not necessarily doing a big, monolithic release with continuous deployment, you can end up with this material never getting any sort of end to end editing to make sure they stay current. Make time for this. It’s good for both your customer experience and your customer support team.
Frequent Downloads and Updates
While continuous deployment is quite natural with web applications, even downloaded products can be constantly updated. However, you should always be aware of the burden you’re placing on your user base. If you’re forcing people to download a large file and go through an installation process too often, you’re going to annoy people. As a personal example, iTunes appears to have a new version every week, and I’ve started to flinch every time I open it.
There are a few things you can do to make downloads easier on your users. First, you can ask the user to allow the update to download in the background and install automatically the next time the product opens. This means that the updating happens with very little user annoyance. Also, it’s best to keep the update quick by making the downloads incremental. For example, your virus protection software probably updates its virus information daily without asking you to reinstall the entire product every time.
So, Is It Good for Users or Not?
Continuous deployment can be done in a way that’s good for both engineering teams and users, but you do need to take some precautions. By taking care when you introduce changes that your users will really notice and making sure that you make time for important processes like QA, you can get features out faster and constantly improve your product. And that is very good for users.
Interested? You should follow me on Twitter.
For more information on the user experience, check out:
Julie Stanford | 07.17.09
The new shopping area of the Intuit Health Benefits Center has just launched! We’ve been working very closely with Intuit on the design of this new venture for months and are proud to be a part of making healthcare insurance more accessible to small businesses.
Mia Silverman | 05.04.09
Recently, I discovered a new prototyping tool for creating rough, sketch-style UI designs called Balsamiq Mockups. It’s basically a lo-fi mockup tool with a built-in library of sketch-style UI elements that can be easily dropped onto a workspace and edited.
After test driving this tool on my own, I decided to see how Balsamiq Mockups sketches compared to rough HTML wireframes in the context of a user study.
First impressions using Balsamiq
After demoing the tool for only a few minutes, I thought, “Wow, nice job!” It was fun to play with, drop dead simple to use, and required no tedious application tutorials or programming knowledge in order to just dig right in. I liked how quick and easy it was to drag and drop library items into the workspace and quickly adjust and rearrange them as needed. After only a short time using Balsamiq, I could create simple mockups just as fast (if not faster) than I could in Dreamweaver, the tool I use most frequently for rapid prototyping. I also found it very easy to export my Balsamiq sketches as static files and add interactive behaviors on top of them using hotspots.
However, the real strength of Balsamiq comes from the fact that the tool does not simply emulate other prototyping tools that make realistic-looking mockups (such as Visio, PowerPoint, GUI Design Studio, and MockupScreens). Instead, Balsamiq takes an entirely different approach and deliberately uses a rough, hand-drawn look and feel — presumably to better communicate that these designs are just early ideas in-progress and are not fully fleshed out yet. I hypothesized that Balsamiq Mockups would be especially good for communicating early design concepts, to keep users focused on the high-level ideas, rather than on the details.
Balsamiq vs. HTML usability test
To test my hypothesis, I conducted a comparison study to find out if the sketch-like quality of Balsamiq mockups had any effect on the type of feedback that users provide in the context of a study.
The research process
For the study, I used an A/B test format. First, I mocked up the same high level design using two different methods: version one was created in Balsamiq, and version two was a very rough, grayscale, HTML wireframe created in Dreamweaver. Then, I showed half the participants the version one Balsamiq sketch; the other half of the participants saw the version two HTML wireframe. (See images below with text blocked out for client IP reasons)
Version 1: Balsamiq sketch
Version 2: HTML wireframe
In both cases, I told users to share their initial impressions about the design. I explained that the designs were still a work-in-progress and I was looking for high-level feedback regarding the concept and overall functionality, rather than the specific language, details, or look and feel of the page. I then noted their feedback to see if there were differences between the two groups.
The results
All participants were able to provide high-level feedback about both types of mockups. However, participants who saw the Balsamiq sketches were slightly less concerned with the details and specifics of the design. They tended to comment less on the colors and appearance of the design, as well as the particular language and text used. They were also more aware of the fact that they were looking at an in-progress design, making comments such as, “I don’t really like the way this dropdown menu works, but know the design for it might change later anyway.”
In both cases, users still made comments on specific page interactions, but the Balsamiq participants were more likely to be aware that this type of feedback was overly specific, as one participant qualified his feedback by saying, “I guess that’s not really the kind of feedback you’re looking for right now.”
Overall, I found that the participants who saw the Balsamiq sketches did a slightly better job of keeping their feedback more conceptual than the participants who saw the HTML wireframes. However, participants in both cases still commented on some of the details of the mockups as well, and it was necessary to use the moderator questions to guide the user’ focus and attention back to the level of feedback I was looking for.
Conclusion
Balsamiq Mockups is a useful new prototyping tool. It’s perfect for sketching quick ideas and sharing with others, especially if the mockups are fairly simple in layout and overall complexity. It’s also a great tool for concept testing with users, as the sketch-like quality of the designs works well for gathering high-level feedback on initial design ideas.
Julie Stanford | 04.07.09
I’ve noticed a trend recently of home pages for various web services having a three step layout. The goal is to describe your service with three simple steps. A few examples:
Sunnygram
Blurb
Poll Everywhere
This pattern is becoming pretty rampant and with good reason — it’s effective. If you have a site that is providing a service in a new or unique way, you need to explain to your prospective customer why you are special very quickly. I can’t even tell you how many sites I visited in the course of doing research for this article that I could not figure out. The three steps design approach provides a framework for communicating uniqueness in a clean, simple format.
For example, screenshotted below are two sites that do very similar things — ticket search. Fansnap uses the three steps approach to describe what they do and why they do it better than others. Seatwave highlights an event at the top and then provides a browse interface below.
Fansnap does a better job educating their visitors about what is so special about their ticketing site. In contrast, Seatwave is just another ticket site — I’m not sure why I would use it over eBay or StubHub which are more well known.
Fansnap
Seatwave
But is three a magic number? Why not four steps?
Four steps starts to feel like a lot. Let’s look at this four step example from LOVEFilm.com – the British version of Netflix.
LoveFilm.com
Four steps starts feeling complicated — I can’t just scan and move on. Do they really need that third step –”Watch it at your leisure with no late fees”? It seems like they could combine it with step 4 pretty easily. Then maybe they could have a big sticker or something that says “No late fees!”
Check out this super quick redesign I did reducing the steps from 4 to 3:
Before – 4 steps
After – 3 Steps with a No Late Fees sticker
2 Pitfalls
As with every good pattern, there are ways that you can mess it up:
1. Avoid empty sound bites
In the quest to have 3 catchy pieces of information, don’t reduce your something to nothing but buzzword fluff. Fansnap is trying to be clean by sticking with three words: Compare – Choose – Click. But, on first glance it’s a little confusing what they are talking about and why they are unique. Basically, they search across a bunch of sites (like kayak.com except for tickets) and then offer a cool UI to compare the seats so that you can get the best seats at the lowest price. Handy. Here is a redesign of the language and graphics that keeps the simplicity but doesn’t force the user to think:
Before – empty language
After – clear languag and graphics
2. Put the numbers close to the words
In the original FanSnap above, the numbers are buried in the graphic. This makes me wonder at first if the items below are steps or just three features. In the redesign I’ve put the numbers next to the words and suddently it is clear that this is a quick, fun process.
So, to make a long story short, three steps is an interesting design pattern for quickly communicating the essence of your service to your prospective customer. Next week, I’ll delve into the sister pattern of 3 steps which is 3 features.
Julie Stanford | 03.10.09
Economy be damned, we’ve just started working with 2 new clients in really interesting spaces.
Yummly is a start up looking at the intersection of food and the internet. They’re in stealth mode so that’s all we can say for now but we’ll keep you posted.
iConstituent is a more established company that provides email communication solutions to congresspeople. We’re working with them on a visual refresh followed by a more comprehensive user experience redesign.
We’ll post pix of our latest work as soon as we can.
.
Julie Stanford | 01.22.09
After a few months of working with Sliced Bread to develop the concept, Intuit has just launched the initial version of its health benefits center. This new experience is designed to help small businesses in California learn about choosing the right health insurance plan for their company. Sliced Bread Design did all of the interaction and visual design for this Adobe Flex site. Intuit did the implementation.
In addition to learning about the different health insurance options, the site also presents the results of a survey Intuit has been conducting of what health benefits small businesses offer their employees. Finally there is a place on the web where you can go to see what employers like you are doing for their employees — a feature we think is pretty neat.
Needless to say we have worked hard with Intuit on the information design for this site to make complex insurance verbiage more transparent. We are very excited about how it has turned out and are even more excited about what is in the works for the future so keep checking back to watch it grow.
You can also join the feedback group (link at the top of the site) if you want to be in the group of customers we’re working with to make sure that we create a site that really works for users.
http://www.intuithealthbenefitscenter.com/
