Well, earlier this week one of the Galvin Technologies employees came back from maternity leave.  We were excited to have her back and decided to have a small gathering in the conference room with cake.  So when we ordered the cake we mentioned we wanted a chocolate cake with “Welcome Back” written on it.  Easy enough requirement, right?  Well, when the cake was picked up it read “Well Come Back” on three separate lines.

This is a perfect example of documenting the requirements first.  If the cake was a website project we would make sure we documented that the cake was chocolate and to read “Well Come Back”.  We would then hand that requirement to the client only for them to inform us that it is to say “Welcome Back”.  We would have made that quick change and the client would sign off.  Total change time = 1 minute.

But in this situation the person who made the cake assumed it was to read “Well Come Back” so they took the production of the cake all the way to delivery only for the client to be disappointed and tell them it is not right.  Total time to fix this mistake = 1.5 hours + cost of the cake.  A much more expensive mistake plus we plan not go back there although the cake tasted great.  Design is crucial so document it.

Post from: The Galvin Blog

A Good Lesson in Defining Website Design Requirements….From a Cake?!?!

Ok. You have decided to make a monumental decision: you are going to hire an architectural company to build a new house for you. After months and months and what has to equal hundreds of thousands of dollars, you drive to your new home, walk in and…realize things aren’t quite right. You flip the switch for the garbage disposal and the upstairs toilet flushes. When the dryer runs, the air temperature drops thirty degrees. This is not what you had in mind. You have wasted lots of time and lots of money on a product that, in the end, was nowhere near what you wanted.

This is a legitimate concern in the software engineering and development world as well as any other type of construction. It’s easy to just build a house or just design a car if a customer asks you to, but there is so much room for error and disappointment, cost in both time and money, that we choose a little more intimate of a route. Not only do we develop websites for our clients, but we also develop business systems. To do this in at our most efficient level, we go over the functional requirements of the system with the client and follow that up with use cases.

Some sites can be basic, flat html pages, where the user can visit multiple pages via links and learn about the company, the products the company sells, and navigate pages without really doing anything other than that navigation. For example, a florist shop – let’s call it Fiona’s Flowers, based out of Tampa – has a website with a few pages that give the company’s bio, some contact information, some pictures and a list of various plants and boutiques one can purchase at the shop. All in all, it’s not much more than an online Power Point presentation that the user navigates. One can’t buy anything online, nor can one compare prices to other companies when Fiona boasts that her prices are the best in the area.

Now let’s backtrack and say Fiona hasn’t had this business designed yet, much less a website, but she knows what she wants there. She comes to us and says, “Hey, I’m going to be building a floral company. I have nothing except my idea and how I want it to work.” It is then our job to define the functional requirements – what Fiona’s system has to do – for the business system and the company. She has to have customer’s able to purchase online, has to have a shipping service and options for shipping, has to be able to compare prices for each and every plant she sells with the competitive market, etc. We end up with a laundry list of the client’s desired functions for their system because we want to design a complete system for you. Software engineering is, in essence, no different than engineering a car; what are the pieces and parts I have to build to make all this happen?

We’ve listed what the customer wants and documented what this product should do, and now we have a laundry list for system purposes – the functional requirements. Once we have that, we lay it all out into modules, creating a model for everything from application to the storage database. After looking at this list and modules, each building block in the application model, we start creating use cases.

Let’s look at an insurance company, for example. One objective for a use case, the process associated with it, might be creating a quote and saving it to the database for future viewing. The functional requirements are the ability to print the quote, generate a pdf file for emailing, etc. A use case for this quote creation would documents the flow of a user’s steps to creating a quote, from interface appearance, generating a quote number, attributes of the policies available and coverage, and so on and so forth. The use case basically walks through the steps of how a user uses the web page of the insurance company and its components.

Also documented are the specific business rules applied. The customer enters information on the screen  and clicks “save.” The next step would be applying a business rule according to what is laid out in the use case – what has to happen. A quote number needs to be created. What numbers are generated? How are they generated? These are business rules that have to be applied to meet the functional requirements discussed earlier. What happens if the driver’s license isn’t validated or wrong information is entered? What happens if a license number has expired? These are logical business outcomes that need to be very clearly laid out. If a user wants to take a policy on Dodge Viper and the business isn’t willing or able to take on that car value, what is the process that needs to occur that sends a message of refusal? The response is documented in the use case.

---

We fully disclose to the client what we are going to develop before rather than during the building process, which makes construction both cost effective and easier to understand for everyone.

---

Use cases are important because it forces both our client and us to agree on everything that is going to happen. We get sign off on everything before we sit down and design the product. We fully disclose to the client what we are going to develop before rather than during the building process, which makes construction both cost effective and easier to understand for everyone. It’s not only a system for agreement, but it gives the developer, who doesn’t make much contact with the client until the use case is developed, a very specific idea of what they’re going to be building and how to go about doing it. As the blocks agreed upon in the functional requirements are built, what we had previously discussed and agreed upon is enforced.

So, back to the house example from the very beginning. If we built houses, we would sit down with you and discuss – and agree upon – the functions for everything in the house. This switch will turn on the garbage disposal, this will turn up the heat, and this will lock the door. There’s no room for confusion or the possibility of a devastating mistake either on your expectations or our construction. The whole purpose is to get confirmation that what we’re developing is in essence what you need before the product is created. It saves you money. It makes us efficient. And it makes the products stronger, better, and faster.

Post from: The Galvin Blog

Functional Requirements and Use Cases: Avoiding Accidents and Mix-ups in System Engineering

As I was vacuuming the house I began to immediately think that the reasons why everyone likes a Dyson vacuum are that it truly does a great job and that you can see the results. Instead of a vacuum bag the Dyson has a plastic container that you can see through and see all the dirt you pick up. So as I was vacuuming the house I began to think about how successful Dyson is and their positive word of mouth. I then began to relate that to our industry and as well as to Galvin. In theory a vacuum can just be a commodity – you can buy them anywhere and price is a decision factor. But Dyson showcases that they are not a commodity but rather a high end vacuum that will pick up much more dirt and vacuum then any other vacuum. Then they show the results by showing you the dirt that you picked up.

Talk is cheap. For Galvin Creative Technologies to proclaim great service and great delivery we have to back that up with showing the results. The Dyson shows you the dirt you just collected and we show you the results by accurate budgeting and forecasting, approved use cases, constant communication, updated project plans, updated work break down structures, weekly status reports, an issue log and then the end product. With a vacuum that uses a vacuum bag to collect dirt you can only assume and hope the vacuum is working and with a web project if you are not getting weekly communications and updated documents you can only assume the project is being done properly.

Post from: The Galvin Blog

How My Dyson Vacuum is Like a Web Project

Motion Type video for 51st Annual Grammy Awards ad campaign.

Following up on Gary’s post about the rigorous processes we go through in the course of a project and how project management is so important to this process, I wanted to touch on the subject of content and how important it is to design.

Content comes in many forms in the context of interface design. It gives users a sense of what the site is about through navigation, provides direction in the form of buttons, confirms actions inside interactive forms and can be seen as imagery together with main body copy. All of these forms of content are used to strengthen the overall user experience and give the site meaning and validity. 

So why is content important to design?
In the beginning of a project, content is considered to construct site-maps and put together functional diagrams. After that there can be a disconnect of what specific ideas and information the site needs to convey. Content can get pushed to the end of a project because the client wants to focus on the structure and overall project plan. This can eventually bring the project to a standstill. Designers need content at the beginning of the project because we use it to plan the way users interact with the site (wireframes), to create a consistent and useable hierarchy and most importantly, to make sure the information that will accomplish the client’s goals is presented in the best way possible. 

Solutions
So what are some things we can do to insure that content is given the attention it deserves? First of all, it is the job of the designer to educate the client and the project manager of the importance that content plays in the overall objective of the site. More specifically, we as a team can plan out the process in the early stages of the project so it has the best chance for success.

1. Initial Discussion
Before the wireframes are created, there should be a discussion over the content of the site that involves the client, copy writer, the designer and project manager. Ideally, this discussion should be in three parts:
a ) What content do we have and what are we using or throwing out?
b ) What are the new goals and what is the main message for the website?
c ) What imagery, charts or specific functionality do we need to help convey the new goals and new message?

2. Outline of Content for All Pages
A content outline of each page of the website should be created not only to keep track of what content is on-hand and what is still needed, but also so that all parties know what to expect when the website is developed. This insures smaller more-specific goals are met.

3. Internal Collaboration
A discussion should take place with project managers, developers and designers over what will be presented to the client in the initial comps.  What content can be used in the initial design comps to convey the meaning and functionality of each element? This communication will give designers the knowledge to best design for usability and in-turn will insure developers implement the interface correctly.
 
4. Content & Design Audit
After the design is implemented and content has been developed, an audit should be done for all pages of the site. This audit involves making sure the design is supporting the content and that the content is fresh and easily navigated. Is this page conveying what we intended? Do we need a different call-out to bring importance to a certain event? Is the homepage talking to the intended audience, and do we need a call-to-action? These are all questions that need to be answered before a site is launched.

Conclusion
Content is a key ingredient to building a successful website. It is important to the validity of the site as well as the usability and success of its design. Therefore, it should be addressed in the beginning of the design phase. Creating good content requires collaboration throughout the project with the client and development teams to insure all expectations are met and goals are reached.

Post from: The Galvin Blog

Better Content for a Better Experience

We are well aware that our industry is fragmented. There are many web and software development companies within the Indianapolis area. We can all do great designs, solid infrastructures and proper coding but we honestly feel that at Galvin Creative Technologies we can set ourselves apart with our project management processes. We truly think of ourselves as more of a professional services company opposed to just a web and software development company. We value the relationship, the budget and the timeline of the web or software project.

Two weeks ago I was visiting a client and I stopped by one of our contacts office and asked him how things are coming along with the project. His comment was music to my ears. He said “you guys should write a book on your processes.” He was thrilled with the amount of detail that was involved. He went on to say that he knows exactly where we are with budget, timeline and tasks. Then just last week we helped the Secretary of State’s office develop and launch their Rethinking Redistricting website. What should have been a two month project got done in two in a half weeks and came in well under budget. It was a project that came to us quickly with a very tight deadline and a strict budget. Our project managers put together a two week timeline, while not shortcutting any of our processes, then accurately defined the requirements, then developed it and we nailed it.

In our six years of business I specifically look back at how we have grown over the past two years and what we have learned. We experienced the pain of not managing a project correctly and we have experienced the pain of not allocating our resources. But before things got out of hand we knew exactly where we had to improve and began to invest in our processes, business analysis and project management. Now, our projects are on time and within budget. Tom Schaetzle, our VP of Professional Services, has implemented very rigid project disciplines for Galvin Creative Technologies and the projects we develop.

Post from: The Galvin Blog

Proper Project Management in Web and Software Development

Paul Boag writes about the benefits of hand-drawn wireframes in The 7 Wonders of Wireframes and that many can be done in a small amount of time. More importantly, I think, he identifies the key reasons of why this stage is so successful:

1. Improves Team Work
Wire-framing brings together all members of the team. These discussions help manage roles, responsibilities and scope.

2. Better Communication
This stage not only improves team work but it also makes the subsequent steps in the project run much smoother by bringing developers and designers together early on in the project.

3. Engages Our Clients
By including our clients in the wire-framing step we can educate them on all aspects of web development; from key terms to technologies utilized. This also increases the chance of meeting client expectations and goals early on in the project.

4. More Choices
Because wireframes are easy and fast to produce we can show more options at this phase and inevitably have the best result at the design phase.

5. A Testing Stage
A wireframe is the visual representation of our textual “use cases”. A “use case” documents the flow and functionality of key elements on a page. We can use wireframes and “use cases” to internally test how these key components should function.

6. Easier to Rework
Through the use of wireframes our clients can start to see how the site will be laid out. Since they are much faster to produce than design compositions, many more changes and tweaks can be done at this stage without a significant amount of rework.

7. Keeps Projects Within Budget
Wireframes bring together our teams, improve communication with clients and are easily changed and reworked. With all of these important factors projects can run smoothly and more efficiently to save time and costs.

Finally, it is our job to educate clients on how and why we have these processes. That even though this stage can be a bit slow and visually unexciting, it is advantageous to the end result. It is crucial in the beginning to step back from any design aesthetics and plan the best flow, hierarchy and functionality for each project.

Post from: The Galvin Blog

The Importance of Wireframes