Archive for the ‘User Experience’ Category

User Stories for Understanding Project Requirements

August 6th, 2010 at 2:26 pm

Something we have started doing very deliberately, something that really works to help us accurately scope and manage a project, is writing user stories for understanding project requirements. It’s not a new idea by any means, and we’ve always thought this way, but we’re seeing now it as a “must-do” step in our process. When we’re trying to get our arms around a project, it’s a formula to get moving with.

What’s in a user story? It’s simple (at least the way we write them). It’s just one thing a user can do and why. That’s all. So it describes an action the user takes…and thus implies a function we need to enable, and a user experience we need to streamline. You put all your single user stories together and voila:  that’s the entire website project in action form. It’s also a great way to start documenting your work (more on this another day).

A user story has a beginning, middle, and end. First is the Who.  In the middle is the What.  Last is the Why.

It looks like this:

As a <type of user>, I can <do something> so that <some reason>.

or

As a <who>, I can <what>, so that <why>.

The Who is important because it differentiates between types of users, whether they are:

  • “anonymous” (non-logged in users, more than likely existing/potential customers who only are allowed to view specified pages on your site).
  • “authenticated” (logged in users with more permissions than anonymous types…in addition to being able to view content perhaps they can also upload attachments, write comments, or otherwise interact in some way).
  • “administrator” (can do just about anything from creating/editing content to SEO customization to menu manipulation, and lots more).
  • there are other flavors of user types and some hybrids, but these three are pretty much the arch-types.
The What is the thing that the admin, authenticated, or anonymous user is supposed to be able to do:  call it a “feature” but maybe it’s more accurate to think of it as a desired action. This implies a certain development function we’ll need to implement.  The Why is the benefit of taking the stated action…what makes it meaningful. This implies a certain user experience we’re trying to create. Kind of grounds it in the real world. If you don’t have a good why, you might want to rethink your priority here.

Here are some examples around posting comments on a blog:

As an anonymous user, I can read all recent blog articles in ascending chronological order, so that I can learn about what X company has been up to most recently.

As an authenticated user, I can submit a comment to a blog article, so that I can provide feedback to X company.

As an admin, I can moderate and approve/disapprove of comments submitted to my blog, so that I can ensure that my blog comments are not inappropriate or offensive.

Three different angles for three different types of users, all concerning the same aspect of the site (blog comments), but now we have defined the workflow and we can start discussing it in more granular detail. For the authenticated user, we can extrapolate to think “hey, we will need a little message that says ‘thank you for submitting, awaiting moderation now’”.  For the admin, we need to start knowing how he will be notified that there are comments awaiting approval, or is he allowed to edit or just approve/deny.  It appears to build on itself…but really these project requirements were lurking underneath the surface since the beginning.  We’re simply seeing the whole iceberg better.

As you can surmise, one of the big benefits of writing these silly user stories is that they often foment discussion and further investigation. That’s a wonderful thing…the devil is in the details.  When we get to a point where we have written every last possible user story we can possibly know about…that’s when we can put an hours estimate on implementing each story to completion and feel confident that we’re not missing something. Our clients and ourselves can talk about the project in a very informed fashion. The formulaic writing process forces both parties to suss out the hidden complexities of a project, and evaluate these for priority, i.e.maybe there’s a more efficient way to approach the What, so you can still provide the Why that matters to the Who.

Website Redesign Strategy: Start with the Content

January 25th, 2010 at 10:46 am

So you’ve got a pretty good feel for what kind of new site you want.  Here’s some advice for efficiently building a site of great value.

1. Start with the content.

  • gather all content together in one place
  • content = words, photos, video, contact info, graphic art/logos…ANYTHING that will be visible by anyone who uses your site.
  • organize it into acceptable file formats for the web (check with your web developer)

This is required work for any web project to be successful. Have it before you need it, or you risk wasting resources during your later project stages…because so many design/development decisions depend on what the final content is.

Too many website projects go awry because no one bothered to organize or produce the REAL content they needed for their REAL site. Everybody said “oh, that will be a demo” or “image area”, or “two or three paragraphs of content” and then assumed it would appear out of thin air. Content is the second-most important thing on your site, second only in importance to having users to appreciate it!  You don’t want to mess this up. Organize, write, edit, or produce the content yourself (or see to it that someone else does) now, not as an afterthought.

This is also a great exercise for you to be sure you will actually “say what you mean and mean what you say.”

2. Consider your users.

  • put yourself in the shoes of your best customer
  • what does he or she really want to do on your site?
  • what do you really want them to do on your site?

Understand that the average web user is in a hurry and does not want to hunt for what he/she wants.  Don’t over think it.  Concentrate on user actions and clarity of information.

3. Assess the ‘minimum viable product’.

  • what’s the simplest way to achieve your goals in a timely and efficient manner?
  • think goals, not features
  • separate the “would be nice to have” stuff from your bottom line “must have” stuff.  Prioritize both lists.

Understand that you can always add more stuff later (and you will want to), the important thing is to have a great foundation to build from.

4. Have a defined decision making process

  • commit to being an active collaborator throughout the project.
  • when it’s time to give feedback, be clear, be specific, and be engaged.
  • when it’s time to decide A or B, be confident and be quick.

You should accommodate for change that will certainly occur during the lifespan of your project.  Building a website is an iterative process.  Sometimes the original vision doesn’t hold up under scrutiny.  That’s okay.  It’s not a failure or a setback…it’s an opportunity to improve and get things right.

Be ready to deal with important decisions in short order so you can keep your project momentum going strong and build a site of lasting value.

Why Drupal?

December 14th, 2009 at 5:01 pm

ENTERMEDIA has built a lot of websites since 2004 for clients of all types. Over the years we’ve gravitated to build practically every site with Drupal. Why is that?

Drupal is flexible.

From it’s inception Drupal was built with open source in mind. The founder of Drupal was smart enough to realize that predicting where the web will go in the future is a fool’s game, so let’s build it to be as flexible and modular as possible so it can adapt to each clients needs as well as any future developments. Remove as many constraints as possible at the outset. What this means is that you need to understand best practices for development to contribute modules that the rest of the community will endorse and adopt, but isn’t that how it should be? For instance, old site planning methodologies such as the waterfall project management approach, were concerned with concepts like knowing exactly where the main navigation menu was going to be before you would write a single line of code. With Drupal, if you decide that the main nav needs to move to the right side or left side instead of across the top you can make that change in a matter of minutes, so long as you haven’t styled the whole site prematurely.

Drupal is modular.

The devil is in the details when you are developing a website. Unfortunately, the majority of projects do not achieve the initial goal of building the entire scope on-time and on-budget. That’s because unless the developer has previously coded something exactly like what you need now, he’s having to estimate how he can get the job done on assumptions alone.  Building every simple thing from scratch is hard.

But with Drupal, ‘there’s a module for that.

Like the Apple store’s claim ‘there’s an app for that’, there’s most likely a feature rich Drupal module that does what you need and can be configured for your exact requirements. If not, there will be soon. There are over 3500 modules that can be used in Drupal to accomplish just about any requirement you can imagine.  Many times multiple modules are introduced that do the same thing, but over time the best solution emerges and the community gets behind it.  Once a module is adopted and accepted by the Drupal community it will be continuously tested and refined to fix any issues or add any ‘got-to-have’ features due to it’s vast number of implementations and specific feedback.  Developers help developers figure out these problems, and then the rest of us get to share in their solutions.

Drupal is scalable.

Drupal works with practically any type of database, so it doesn’t matter if you’re using an enterprise level Oracle databases or a free MySQL database. Without getting too technical, what you need to know is that Drupal can scale to meet your needs, but you’ll need an experienced Systems/Server Admin toproperly guide you to the right hosting a server setup. The greater point is that Drupal can scale as well as any other technology. The best proof is the number of large web properties who are successfully using Drupal, such as the economist. You can find more example drupal sites on the founder of Drupal’s blog.

Drupal is SEO friendly.

SEO is largely misunderstood from our experience. Drupal makes it easy for you to make your site follow best SEO practices.  It also allows you to write, publish, and correct problems with your site content that the search engines might not like with a little training and without needing a web developer to be involved.  Drupal does a lot of things automatically, such as provide strong internal link structure to make sure each link to pages within the site are tagged in the same way.  Drupal does not do SEO for you, however.  For more information on what you should be doing to practice good SEO, start here for a simple overview, but go here if you’re looking for professional help.

Drupal is free.

Drupal is open source and is therefore free of charge.  You will need to pay for hosting if you don’t have your own web server, and if you’re not a web developer you will probably need to hire a good team if you’re hoping for something professional.  However, you won’t have to pay Microsoft liscensing fees, the hosting for open source costs less, and the majority of the web is open source, so there are plenty of capable people in this world who can support a Drupal based website.

Drupal has momentum.

Like most movements, what’s critical to the success of Drupal is the huge adoption rate of the development community and the business community in general.  It is one of the greatest crowd-sourcing success stories around.  It is this community that will decide if Drupal deserves it’s success, if it should continue on, and for how long.  The Drupal 7 User Experience Project is a good reason to believe that Drupal will continue to be the best available option for years to come.  Already, some very big and important websites are built with Drupal, like:

Drupal is simply an efficient tool.

Drupal is a content management system that allows non-technical site owners to manage their own content. It’s open source, which means it’s free as well. It still requires a high level of experience and expertise in web development practices and principles to build a professional website, which is not free unless you are one of those people. Drupal is simply the tool that allows you to do great things like build an online storefront, event listings, a social community, blog, photo slideshow, multimedia video player, forums, discussion groups, etc.

Call to Action Buttons

October 22nd, 2009 at 4:53 pm

Smashing Magazine does it right once again…a great resource for spies like us…

>> Call to Action Buttons:  Examples and Best Practices

Call to action in web design — and in user experience (UX) in particular — is a term used for elements in a web page that solicit an action from the user. The most popular manifestation of call to action in web interfaces comes in the form of clickable buttons that when clicked, perform an action (e.g. “Buy this now!”) or lead to a web page with additional information (e.g. “Learn more…”) that asks the user to take action.


Application-based Website by ENTERMEDIA

October 8th, 2009 at 9:41 am

AustinontheRocks.com is live!  This brand new website is all about serving up search results for local happy hour and food/drink specials based on user submitted criteria.

Say you want to find a bar in North Austin that has a nice patio, beer and wine specials this Thursday night, a big TV to watch the big game, is “date worthy’, and allows a dog.  Austin on the Rocks will deliver the skinny.  (It won’t buy you a pitcher, root for your team, find you a date, or walk your dog.)  This unique site actually caters to Austin bar-goers and Austin bar/restaurant-proprietors alike, because it matches up the perfect customer with the perfect local food and drink establishment.  Bars can control and update their own entries on the site, too.  Design cues are simple, clean, and easy to navigate, so the user experience is smooth.

From concept to creation, ENTERMEDIA made it happen for this start up custom application-based web business built in Cake, including:

  • brand and online strategy consulting
  • creating the cool logo
  • designing all interface and admin layers
  • sussing out important content strategy and user-experience decisions
  • setting up a database design that will allow Austin on the Rocks to scale gracefully

Our fantastic client Cathi Rustmann and her daughter Taylore Cunningham are the one-two punch signing up the hippest bars all over Austin to be a part of this.  Cathi and Taylore have big plans in store for Austin on the Rocks and really perform a great FREE service to local folks who want to find the best food and drink specials in town. Be sure to follow AusontheRocks on Twitter and become their facebook fan:  you’ll hear about unadvertised food/drink specials and “get ‘em while they last” promotions you won’t want to miss.  Cheers!

Austin on the Rocks logo

“A Complete Home Run”

August 18th, 2009 at 9:21 am

Last week we got a fantastic bit of client feedback on a recent redesign project we wrapped for his web-based business:

Hey guys,

I wanted to let you know that we have launched our new website:  http://www.yourteacher.com/

On our first full day yesterday, we had (##) subscriptions. (Our old website averaged (#) per day.)

It’s clear that the new design and graphics have been a complete home run.

Thanks again for all your help!

Mike

Check out this Google Analytics graphic showing the impact of the new design on their subscription page traffic :

website redesign impact graphic

In the busy professional world, good work is simply expected and praise can be infrequently found.  We always strive to make our clients happy, but it feels really good when they are moved to express their enthusiasm about the finished product.  Hats off to Bryan and Ethan, who solved this redesign project in a minimum of hours and apparently to great effect.


A Fresh Take on Testimonials

August 10th, 2009 at 10:22 am

Putting customer testimonials on your website is a time-worn practice and generally a good idea, but there is some debate over their efficacy. One argument in their favor is ‘your users want to know you have them’…like some kind of a credibility benchmark. This is not to say that they will pay any attention to them. Why? Because testimonials are generally so complimentary by their very nature as to be perceived as embellished. They are not “reviews”…so what informational value do they offer? Again, maybe just the simple fact that you can get your current customers to say nice things about you is the entire point.

It’s also possible that users might have a different bias against them…whether or not they are real. Who would know if they are or are true accounts or complete fiction? In our experience, we have sadly come across some fabricated testimonials, that go a little something like this:

“[So and so] is the only [some kind of company] in the [blank industry] that I trust to deliver [x] [with all the trimmings].”

- Kenny S. from Alabama

Thanks for that, Kenny S! Rest assured, all of EM’s testimonials are genuine. (They need to be updated to reflect more of our latest work and clients, but that’s a different issue.)

Recently, one of our clients came up with a great way to present customer testimonials in a way that is genuine, informational, and compelling. Cuatro from CuatroBenefits invited some of his representative clients into his office the other morning and shot a quick video asking them some pointed questions about their experience interacting with his service. Full disclosure, Ethan and Ryan were invited and filmed.

Anyway, we think this is a wonderful and persuasive marketing play in the age of easy YouTube style video sharing. This is going to drive business leads for CuatroBenefits.  We recommend this way of presenting testimonials for similar service-oriented clients.

Check out the video on the CuatroBenefits site:
Cuatro Benefits Blog | Video Testimonials:  Why our Clients Choose to Work With Us

Or check it out right here on YouTube:


Ethan, Nick to Speak at Austin Drupal Meetup

July 29th, 2009 at 10:12 am

ENTERMEDIA cofounder Ethan Worrel and our Head Drupal Chef Nick Lewis will be the speakers tonight at the July meeting of the Austin Drupal Meetup on the interrelated topics of UX, The Client, The Project, and Drupal.

The meetup will run from 7-10p and held at UT’s ACTLab (4th Floor CMB, Studio B, corner of Guadalupe and Dean Keeton).  Ethan and Nick will take turns presenting their brief remarks and then open the floor for questions and comments.

Without giving too much away, here’s a sampling of what you can expect to hear tonight from two of our own most thoroughly enlightening and well-mannered professionals:

UX:

  • Fully leverage everything the user already knows
  • Display the most valuable data…let users dig for the fine detail
  • Make decisions so your users don’t have to

The Client:

  • Guide them to think in terms of page types
  • Demand supporting content early and often
  • Most of the time, you are the client

The Project:

  • Making tough choices that pay off in the long run for both parties
  • How to use the Website Price Estimator 5000

Drupal:

  • Clients can figure out how taxonomy works well enough, but how taxonomy fits into the concept of view arguments?  That’s a different story…
  • [pause for laughter...the audience will think its funny...]


Basics of Website Structure

May 27th, 2009 at 10:33 am

If you’ve never really thought about website structure, here’s a place to start:

Basics Principles of Website Navigation

An Introduction to Information Architecture

Top Ten IA Mistakes

You Say Personae (I say Personas)

May 7th, 2009 at 4:52 pm

We’ve learned that one of the best ways to ensure robust ROI for any website or web app project is to first build an accurate profile of the “desired and likely user,” which we can then use throughout the process to guide key architectural, functional, and aesthetic decisions which would please this “desired and likely user”.  Shorthand, we call it the persona approach.  We didn’t invent it, but it’s really common sense when you think about it.  Say you’re building a house…for whom?  That’s the starting point.

You may care to read Steve Baty’s recent article on the UXmatters site about the building blocks of persona research.  Baty’s overview of the concept is particularly useful as a starting point:

Personas are archetypal representations of audience segments, or user types, which describe user characteristics that lead to different collections of needs and behaviors. We build up each archetype where the characteristics of users overlap.

According to Alan Cooper, author of About Face 3.0 with Robert Riemann and David Cronin, “The persona is a powerful, multipurpose design tool that helps overcome several problems that currently plague the development of digital products. Personas help designers:

  • Determine what a product should do and how it should behave.
  • Communicate with stakeholders, developers, and other designers.
  • Build consensus and commitment to the design.
  • Measure the design’s effectiveness.
  • Contribute to other product-related efforts such as marketing and sales plans.”

But where do we start looking for the data we need to build up these useful archetypes.

Baty suggests surveys, ethnographic research, interviews, contextual inquiries, and web analytics as the primary research tools to formulate a meaningful persona archetype.  Even for our tiniest projects, ENTERMEDIA tries to get as much information as possible upfront about your probable site or app user so that we can efficiently build assets they can and will use.  As Baty puts it:

One important thing to consider about these different research techniques is that each of them is good in certain ways and can provide insights into different characteristics of your audience. A common refrain among UX practitioners who are looking at personas is to draw upon as many different sources of data as you can. This helps you create a much richer representation of each different persona, but also helps you arrive at much stronger set of personas. Each data source has its own built-in bias, so combining data sets helps mitigate that bias.

You can read the full article here.