Project Terminology: The 15 Most Common Revelry Terms

“What does that mean?” can be one of the scariest questions to ask. And project terminology is loaded with ambiguous words and phrases. At Revelry, we work hard to remove ambiguity and encourage questions.

As widely known as many terms are, they can be just as widely misconstrued. So I’ve created this quick cheat sheet in order to create a shared understanding for our partners and clients – and all of our teammates – at Revelry. We hear these terms thrown out frequently on Revelry projects.

If you’ve ever wondered the difference between staging and production, or styles and UX, then this is for you! Here’s the list of the 15 most common pieces of project lingo we use at Revelry:

Project Terminology: Design Terms

Wireframes

Not intended to serve as a visual indicator for how a page or feature will look, wireframes are more for base-level planning of how the user will get from point A to point B.

Wireframes are a good place to start before creating full mockups. Sometimes, wireframes are viewed as the “skeleton” of the site. We use them more for outlining everything that needs to be included on a single page before deploying UI/UX to refine. A wireframe at Revelry can be as simple as a sketch in a notebook or whiteboard, and as elaborate as grayscale mockups using tools such as Balsamic or Sketch.

Mockup

When a project calls for it, we’ll create static mockups for screens so that the team can collaborate on UI, UX, and design before implementation and styling. These are useful for establishing a look and feel on the first few screens/pages of a product and for getting product owner buy in.

UX

“Maybe it should be called UE because UX stands for User eXperience,” Laura says. UX encompasses design, UI, and user experience.

At its simplest form, it is considering the user’s experience as they use your product. Revelry approaches this starting with userflows, which can be accomplished in the form of flowcharts, wireframes, or acceptance criteria. Device or browser usage constraints also factor into UX decisions.

Pinpointing the target audience is key. It’s important know what drives your audience. What do they want to do with your product? What problem is your app solving for them? How old are they? What is their level of technical experience? Developing user profiles is an excellent exercise that we encourage all of our clients to do, particularly startup founders. The more an ideal user can be described, the more tailored the user experience.

Design and Styling

Design involves selecting the imagery, the colors, and the fonts that feed into the user interface (UI).

Styling is the process of implementing design choices into the code using CSS or SASS.

At Revelry, we always start a project with a living styleguide on a web or mobile app page that will guide all styling choices as the product is built. While Revelry does offer branding services, if a client comes to us with a brand guideline, we use that as inspiration to bring the product to life.

UI

UI stands for user interface, which is how the design and styles are applied to the digital product. A bit simpler than UX, UI determines all of the styles that will be used in the product, from the H1 font to the button border width, while also taking into consideration responsiveness of screens and devices.

At Revelry, our design team members can also do front end development, so our designs are involved not only in the design and UX discussions but also the implementation of the UI. Throughout a sprint, designers and developers will tag team tickets: passing a ticket back and forth until both the implementation and design meets our standards and acceptance criteria (AC).

Project Terminology: Engineering Terms

Implementation/Implementators

The implementation team at Revelry are our developers and engineers who work within a codebase. They are the builders of products and writers of code.

We have a wide range of languages and backgrounds that our developers come from before working here. Knowing a particular language is not a requirement for working as a developer at Revelry because we place strong emphasis on pairing and continuing education. Some of our strongest developers were startup founders or worked for Fortune 500 companies.

Merge and Deploy

Merging is the process of merging a new set of code written into a larger codebase. Before this can happen, we have lots of layers of review by both bot and human.

Lintron is a bot that checks all code. Once that checks out, another developer, either on the project or not, is assigned to manually review the code. They can either leave feedback or merge the code in.

Deploying code involves pushing a codebase to a Heroku instance. We like using Codeship because it does this for us automatically when code is merged. Therefore, the new code gets pushed straight to staging, which is where our quality assurance (QA) team gets to work testing.

Staging

Staging is a test site, usually run through Heroku or Kubernetes that hosts our client’s site. Only our team can access staging; it is not open to the public. This means we can test and play and mess up and get things straightened out before pushing to production, which is typically the live site.

We seed realistic data whenever possible to replicate what’s on production, however, staging and production are hardly ever exactly the same. When the QA process has been completed, we can merge the branch from “develop” to “master”, to view the code on production.

This is typically done manually in a more controlled way to allow for immediate testing and fixing of any bugs or discrepancies that could affect our client’s business.

Production

Production is the live site, for the most part. The production site can be used for user acceptance testing (UAT) after QA and regression testing has been completed, but typically UAT occurs on staging.

Some code, like payment processing, requires testing on production with real credit card credentials. Merging to “master” and deploying to production tends to be a controlled exercise for our team.

Some of our project partners have a weekly standing deploy time where our devops team member will oversee the push. Then, the rest of the team can test to ensure nothing broke. If and when this happens, we already have people’s attention to quickly assess and fix the issue.

Project Terminology: PM Terms

Project Management

A member from project management serves as the Scrum master. Project management involves moving the project forward while managing all of the moving parts: resources, decisions, ideas, bugs, features, etc.

Since we move so quickly and do one-week sprints at Revelry, it’s easy for a project to go off the rails in a short amount of time. This is why one of our core philosophies is “call your shots”. That way, everyone on the team is aware of what you’re about to do and can provide input or pivot you if needed.

The PM takes this responsibility full on by constantly striving to understand the product owner’s priorities and keeping the project team informed. In exchange, the PM helps unblock the team and decipher issues or speed bumps and relay to the product owner.

Product Management

Product management drives day-to-day decisions about the product and how users will interact with it.

The main example of how this is manifested is via story writing. Stories frame a feature, and we discuss these with the product owner for approval at weekly sprint planning calls. However, product input can come from anyone on the team or someone who has beta tested the product. A product manager demands prioritization of work while considering the users and business goals. There may be several ways to deliver value to a user, so time, resources, and goals can help drive when stories are written.

Product owners can best help by really knowing their customer. Being able to explain their customer’s needs and prioritization will keep everyone on the team on the same page and working towards a milestone.

AC

Acceptance Criteria define the expected behavior the user should experience when using this feature of the app. AC make up our stories, which make up our tickets. Stories are written in BDD (business development driven) language and broken out into scenarios as needed. Both the PM and the product owner must agree upon the Acceptance Criteria before scoring and working can begin.

QA

Quality Assurance is both a department and a part of our process here at Revelry. QA team members test the applications that we build on staging and production. They check that what was spec’d to be built is built the right way, and help us identify areas of our products that need more work. In layman’s terms, they make sure we have crossed our t’s and dotted our i’s. QA is also responsible for exploratory testing the product and logging any bugs or regressions found.

UAT

User Acceptance Testing is where the product owner checks what we’ve set up in staging against the AC. Since the product owner knows their customer or user best, it is helpful for the team to receive feedback on this feature from that perspective. Similar to the QA process, once the product owner tests against the AC on the proper devices and browsers, they can comment with feedback and assign back to their PM, or close out, meaning the issue has passed their expectations.

You don’t have to know. You can always ask.

At Revelry, we believe in earning and dispensing trust and that fear is the mind killer. So, you’re encouraged to ask about anything that’s unclear and to trust that we are happy to make sure we all have a shared understanding of any concept.

 

---

Process Project Management Team Communication