We were perusing Entrepreneur Magazine (you may recall our appearance in the prestigious publication) and we came across a Boulder company sharing some dire news: If you’re a small or medium business and your website isn’t loading fast enough, then you’re going to have a hard time competing. The Amazons and Ebays of the world have entire teams dedicated to optimizing their websites. What they don’t have, however, is one Mr. Robert Shires. He’s part of the brilliant team behind Lagrange Systems, a company dedicated to turning your eCommerce up to the speed of mind-blowing astonishment. Shires isn’t only technically savvy, but also hilarious, so you get necessary information about improving your website speed (aka Application Delivery) without drowning in tech talk. And, as you’ll see, we’ve taken measures to make sure he stays away from mind-numbing buzzwords.
You’re not developing for you!
They say a video should be really short–like about 90-seconds–to keep an online viewer’s attention. Unless…UNLESS…it’s really good information. This is really good information. Sherri is our reigning queen of the User Interface/User Experience. She recalls how designers were once employed to make things pretty, and then shares the important reality of making your website’s copy, icons, images and voice one coherent, profitable masterpiece. Now that’s inner beauty that radiates across the web…and into a really hot conversion rate.
This week our little UI/UX unicorns and developer wolfpack have been hard at work! Ch-Check out this weeks changes to your account that will make managing your domains that much easier! Game on!
- Ever used the “Email Me My Domain List” link from your Account Control Panel? You should! It now emails you your domains, expiration dates, and name servers! Say what?!
- Your Account Management page just got a lot snazzier too! Look at the magic unicorns running with wolfpacks can do………
- “Action” buttons have been added to make it easier for you to renew domains and products, enable whois privacy, edit DNS, change nameservers, manage URL forwarding, and manage automatic billing. That’s like everything possible you could ever do to a domain!
- To be Automatically Billed or not to be Automatically Billed? We answer the question with, “Disabled” or “Enabled” text.
- Even Whois Privacy got an upgrade. Forgot to add it during checkout? You can now add it from your home page. Not every domain extension allows you to hide your contact details with Whois Privacy. We now let you know the deal by saying “Not Supported” if it’s not possible to add it. #duh
- A new bulk function is best communicated with a poem:
Don’t think we’re stopping here! Share any feedback you have with your comments!
In my last UX blog post I discussed defining the strategy of a project by inquiring about user objectives and company objectives. I’m sure you all went out and immediately started scheduling stakeholder meetings, agreed on a strategy, and then looked around at each other with that “now what?” look. Is that what happened? If so, worry not! The next step is straightforward and obvious – write it down.
Putting the strategy and the flow on paper ensures that you don’t forget it. It also serves as the first section of every product manager’s most beloved (and simultaneously most detested) aspect of his or her job–the scope of work. Call it what you will–the scope, the SOW, the spec (this is what I call it), technical specifications, the scoping document, etc. The bottom line is you need one in order to actually get the product you want to get.
After you have a strategy, define functional specifications, which specify requirements for the project, how the product will function, and criteria for user acceptance. Functional specifications are typically written out and are accompanied by content requirements.
Page content usually has to do with information. You define content requirements by compiling a list of all of the places that messages will need to be communicated to the user through page titles, headlines, error messages, calls to action, etc. Have you ever seen a cryptic error message on a website that is too technical for you to understand? Brainstorming a list of all the required content will prevent issues like that. It assures that you have thought through every possible scenario your users can arrive at.
As soon as you have functional specifications and content requirements you can start scoping out the structure of the product. Wireframes are very helpful in this phase of project planning. Wireframes detail the layout of pages in a bare-bones image. They provide a guideline for the skeleton of the page and are essential reference materials for designers and developers who will actually work on bringing the product to life.
Finally, when the team has agreed upon the functional specifications, content requirements, and layout of the wireframe you can create Mockups in Photoshop
or in actual HTML/CSS code that illustrate the visual design and ensure that standard site elements are being used on the page. Creating a mockup also demonstrates information and functional design elements for the team to examine.
Putting strategy, functional specifications, content requirements, wireframes, and mockups together in a document will give you a spec that your project team can work off of in a sane manner. It is not a simple process, but it makes development move faster because most of their questions will have been answered in a clear way and there is reference material to go back to if key stakeholders are absent.
This is the second post in a series about User Experience design. Catch up with the first here.
UX design, as I aptly described (with metaphors and all) is about creating products that people want to use and can use easily. Realistically speaking, there are a lot of fluffy books and schools of thought out there about UX design that completely ignore real world constraints. I could give you a number of recommendations about user testing in labs and surveys and disregarding existing processes and systems, but then I’d be misleading you. My goal is to provide you with an overview of how a real-world UX design process works. I’m not going to say it’s 100% perfect, but it’s a great place to start. Today I’m going to discuss project objectives.
Planning a project with user-centered design in mind is no picnic. UX design requires a lot of insight into who will use your product and what they’ll use it for. Understanding your users is fundamentally important in web development. User personas are a clean and concise way to keep track of the user base that you are targeting.
You can use your personas to create use cases. A use case is a list of intentions and interactions that a user will have with a page based on their characteristics. For instance, a business owner will land on the Name.com homepage to get a web presence. They might or might not understand the difference between a domain, a hosting package, or a website builder that includes hosting so we need to focus on providing them with the information that they need and the calls to action that they expect.
Beyond understanding what a user wants to do with a product it is important to understand what your organization hopes to get out of the finished product, whether it’s increased revenue, more account creations, brand awareness, or a smaller bounce rate. It might seem like the company objectives are obvious, but you’d be surprised how often different team members have different objectives for the same project.
It is quite easy to make sure that everyone involved with a project has the same objectives for it; all you have to do is organize a meeting with the stakeholders of the project and discuss the objectives. However, it is important to maintain organization and efficiency in these meetings because there are often a lot of people involved and it’s easy to fall into the “too many cooks in the kitchen” dilemma. Before walking into the meeting prepare distribute an exhaustive agenda so that everyone has a chance to think about the items on it before discussing it. Checklists to ensure that you cover everything you need in one sitting are helpful as well.
Defining user and company objectives is known as defining the strategy of a project. As soon as the strategy is defined the project-planning ball can really get rolling. Once you have a strategy you can begin to scope out the user flow and wireframes of new pages, features, etc. From there the documentation process begins, but that is going to be its own post because it is so important.
The main objective behind this blog post is to ensure that you understand that UX design requires planning up front and defining what you want your users and the company to get out of a project. Without these requirements it is very difficult for the project planning process to go anywhere.
I used to have this bike back in college that I rode everywhere. It baffled my friends that I chose to ride a bike, not because the concept of “green” transportation was bizarre or unfamiliar to them, but because of the particular bike that I rode. It was terrible. The gears on the back wheel protruded too far from the bike and they would snag my pant legs and rip them apart.
By now you’re probably thinking “duh, roll the pant leg up” because most bikes will do this if your pants are flared enough at the bottom, but this bike would cut and scratch my leg if I didn’t make a conscious effort to bow it out. So, I had a bike that caused my physical pain to ride, unless I was willing to sacrifice some pants en route. I think it goes without saying, but this bike was horribly designed. It looked really nice (so nice, in fact, that some poor sucker stole it from a bike rack on campus) but it was a nightmare to ride. The designer spent a lot of time thinking about the aesthetic appeal of the bike and forgot that it’s a bike that someone will want to ride.
Why am I ranting about my long lost collegiate bicycle? User experience. Every interaction that you have with a product is a user experience. It doesn’t matter what the product does, whether it’s a well-intentioned mobile app you can’t login to, a crockpot, or even your bicycle. The experience I had on my bike was bad.
User experience, or UX, is a big deal in the world of websites and apps. If a user cannot figure out what you expect them to do on a website how are they going to be able to purchase your product? Too often companies focus web development efforts on aesthetics rather than functionality, and their users become frustrated and bounce.
User-centered design attempts to correct this issue by redefining the planning and implementation process around projects. Aesthetics and system foundations
are not the pillars of user-centered design, functionality and usability are. That is not to say that designers can’t create both, but if the designer who created my bike had focused on usability I probably would have been able to ride it without needing to disinfect my leg after each use.
Here at Name.com we dabble in user-centered design. We are by no means experts at it, but we are trying to improve our process and develop products that our customers actually want to use. We have learned a lot in our journey to improve the UX on our website and I think you could learn a great deal from our ideas, initiatives, and mistakes.
And just like that, I’m kicking off a blog series on the UX design process. This post is just an introduction to the concept with many more posts to come.