Skip to content

Wayne State University

Aim Higher

Oct 18 / Rolaine Dang

Hello Collaborative Design. Goodbye Ninjas and Rockstars.

As our team goes full throttle into the use of agile methodologies, our design process also adopted a new, leaner workflow derived from the LeanUX book. Hello collaborative design. In my past blog post about LeanUX, I briefly mentioned the concept of collaborative design and shared my excitement in implementing this process. In the past, I worked in a waterfall process. I was left to solve all design problems (i.e. layout design, information hierarchy, building of new features, etc.) on my own. The weight of finding the appropriate solutions was all on my shoulders. I never liked the Ninja and Rockstar mentality of one person being the savior. Ninjas and Rockstars don’t like to share ideas and spotlight (though I never liked being in the spotlight anyways). I gladly parted ways with our old process. Now I can share the responsibility with my colleagues and direct the spotlight to the team.

In our third sprint, I was able to lead the team in this collaborative exercise to come up with the WSU header design. Let me tell you, as a designer,  it was invigorating to see unconventional ideas evolve into a viable product. Since then, we have used collaborative design to come up with the homepage and childpage design templates.

Below, I’ve included some information on how our team went about the collaborative design process.

Who can participate?

Any one can be involved in the process (designers, developers, content strategist, business analysts, etc.)

The Process of Collaborative Design:

  • Define minimum requirements and constraints.
  • Break out individually for idea generation by creating wireframe sketches  (15 mins).
  • Individual presentation of wireframe to the group followed by group critique on individual’s wireframe with feedback focused on clarifying the presenter’s design (5 mins per person).
  • Break out individually for iteration on their own most well-received wireframe (15 mins).
  • Presentation/group critique  (5 mins per person).
  • Team idea generation to be done on a whiteboard. Sketching a single solution based on ideas from wireframes that the team thinks will be the most successful in fulfilling the goal(s)  (30 mins).
  • After the wireframe design has been completed, pass it on to a developer/designer to get implemented.

 

What are the benefits of Team Collaborative Design?

  • More ideas are generated
  • Get immediate feedback on ideas
  • Everybody shares a common understanding on the problems and solutions
  • Greater team ownership of product
  • Builds team moral and camaraderie
  • Long term time savings by avoiding potential pitfalls
  • Happy designer! Design is not burdened on one person.

We hope you find this post helpful or at the very least thought provoking.

 

 

 

 

Oct 17 / Robert Vrabel

Sprint 4

header

 

homepage-preview

 

Visit next.wayne.edu to see our progress!

Oct 5 / Robert Vrabel

Sprint 3

What we launched this week

directory-search

Retrospective

Sprint three marked a crucial crossroads in our project. When we started, we were given total freedom to create the best site imaginable. Months of planning and preparation yielded a ton of ideas for everything from small page features to site-specific templates and intricate UX elements. But as we flesh out the work that goes into bringing our grand vision to life, we’ve realized that delivering a complete product that lives up to our original expectations would take more time than we currently have. After a lot of internal communication and consultation with our product owner, we’ve shifted focus to creating a minimum viable product that can be used as a solid foundation and be built upon to meet our original goals.

Moving Forward

In our next build we plan to reevaluate our tasks to align them with the launch of a minimum viable product. As opposed to spending a lot of time on our original design and UX goals, our redefined focus will place a greater emphasis on information architecture, user flow and content.

 

Sep 20 / Robert Vrabel

Podcasts

Podcasts have easily been the best way for me to keep up with the latest and greatest going on in the web world. I mainly enjoy them during my commute to and from work, which makes the drive enjoyable and something to look forward to. I wanted to share some of the ones I’ve been listening to lately. * represents my favorite shows.

For Everyone

*Shop Talk - A show about web design. These guys are very entertaining, which is an important part of a good podcast. Watch out for the loud, random sound effects!

*The Web Ahead – Simply put, Jen Simmons is awesome. She is very well spoken and I find her to be very easy to understand. The show talks about a wide range of all things web related.

The Big Web Show – Jeffery Zeldman doesn’t need an introduction. He does a great job bringing on passionate guests.

Boagworld Web Development – These british guys are very entertaining. Sometimes the shows are a little too relaxed, but there’s a lot of gems to be found.

More Technical

*Hansel Minutes – Scott is very good about breaking down what guests have to say into layman’s terms. This podcast can get very technical, but it has shows that cover broad topics as well.

*Javascript Jabber – All things JS. They do a great job talking about a wide range of JS frameworks and their differences.

*Breaking Development - For web design and development beyond the desktop. I love the variety this show offers.

Have any you’d like to share? Post them in the comments!

Sep 20 / Alexander Bienkowski

Sprints 1 and 2: Seeing the site take shape

It’s the end of our second sprint; we’ve fully embraced agility, and we’re finally starting to see this new site take shape. Our first sprint was as much about getting a feel for our new work processes as it was completing initial tasks to launch a primitive, beta version of the Next wayne.edu.

Sprint 1

  • Wireframing the header, footer and navigation
  • Updating our CMS to work with our new template structure
  • Started identifying things under wayne.edu that we need to move out for launching.
  • Gathering content using Google Docs.

At the end of sprint 1, we had a very basic site framework up and running, and even though it was devoid of content, templates and most of the components that make for a good website, it was nice to see some tangible results.

Sprint1

Sprint 2

  • Update the CMS menu area to work with the new add/edit pages area so the navigation can be inputted.
  • Wireframe the breadcrumb view
  • Add the main menu into the CMS
  • Make the navigation actually pull from the CMS so all pages can be navigated.
  • Pick and create a font iconset that we can start to use
  • Add in blank pages for all the pages identified in the lucid chart
  • Migrat content from google docs into our CMS
  • Wireframe the header out more
  • Start creating our initial tests using casperjs
  • Create Proto-Personas based on each main menu area
  • Create the start of a pattern library

In sprint two, our collective focus was more clear and concise. With the updates to our CMS, we were able to start the first iteration of content development. Additional front and back-end components were added, and the site has taken on a more detailed, albeit still very simple, look and functionality.

Sprint2

It’s safe to say we’re starting to hit our stride, and the new agile environment is one of the biggest reasons for that. Every sprint spawns new ideas, new refinements and interesting breakthroughs. Be sure to check out next.wayne.edu as we move forward and give us your feedback. All forms of constructive criticism are appreciated.

Aug 28 / Robert Vrabel

Going Agile

Over the past week our team has been planning for a big change in how we are going to develop the next version of wayne.edu. We are piloting a process to start working in an agile development environment. There are so many ways to set this up. By no means are we experts on this topic, but I wanted to share with you our experience in getting started.

Building the sprint

A “sprint” is a short period of defined time that you have road mapped based on what tasks are going to be worked on and completed for each team or person depending on how much time is available. Rather than doing project management, development, design, QA and launch multiple times a day, we break these out into certain parts of the sprint to allow everyone to focus on the tasks at hand as a team. Here is a look at our first sprint:

waynedotedu - sprint 1

Monday – week 1

To start off the day we  figure out how many working hours someone has during this sprint. We plan for 6 days of tasks and 6 hours/day to work on those tasks. We automatically deduct some time for daily huddles, communication and working in our project management software. This leaves 36 hours/person/sprint . If someone is taking time off, you would subtract it from this number as well.

The next step is going through our backlog of tasks. We size, prioritize and assign them. We then start from the top of our backlog (in this case task #51) and see if that person has enough time to accomplish that task in this sprint. We also designate support time if someone needs help with that task. We do this until an individual is left with 0-3 hours of time. At this point in time you could get this build approved by business owners and easily show how adding other tasks would affect what has already been mapped out.

The next step is planning when this work will be accomplished. We tried mapping out the whole week, but we already have plans to do this on a daily basis or possibly on a 2-day schedule instead.

I possible, we also are dedicating time for innovation and blog posts.

Tuesday on week 1 – Tuesday on week 2 (6 days)

This time is designated to completing the tasks assigned and starting the sprint. Hopefully during this time no major tasks are injected into the sprint. If they are, decisions will need to be made on what will be bumped to the next sprint. The point is to focus on what we road mapped.

Wednesday – week 2

We are dedicating a whole day to do QA. During this time we will review every completed task and make sure they meet our standards. If not, we will take the time to improve the completed work as a team.

Thursday – week  2

On this day we plan to launch the latest work to our production server. We plan to announce this URL soon so you can follow our progress.  After it is launched we are dedicating time for any bug fixes that come out of this launch. If we have the time we will also work on small tasks that don’t impact much.

Friday – week 2

In the morning we are reserving time for more bug fixes that came out of the most recent launch. Next we will discuss how our latest sprint went. Did we size our tasks properly? Any hiccups? Can we improve anything for the next sprint? This is our chance to become more efficient for the next time we build our sprint and to make sure we are on track for success.

The rest of the day is dedicated to blog posts and  innovation time. During innovation time, it’s the team’s chance to discuss new techniques or new technology they have learned about. This way we are constantly improving our web development knowledge and keeping up to date with the latest trends.

The Next Sprints

We are just starting our first sprint and we are really excited to see how it goes. I’m sure you’ll see more posts in the future about our experience! I can’t finish this post without thanking my wife for taking the time to help me get an idea of how to create a sprint. She recently got a job in which she is a project manager in an agile development environment. Hearing her talk about her new job really inspired me to learn more about it. I absolutely believe it’s a much better way to work. Working closely as a team is much better than working as an individual.

Aug 15 / Robert Vrabel

Creating a development workflow with supporting documentation

In the process of migrating to a new server environment for the university’s websites, we figured it would be a good time to take a look at our current processes and try to improve them. The next wayne.edu is going to live on these servers, so it was important that these changes fit our needs.

We ended up making some major changes to our development workflow over the past 2-3 weeks. We also started to document that workflow. Anyone in our department can now follow a hand full of steps to setup their machines to allow them to contribute code.

Github

  • We decided to switch from using SVN to GIT by using github.com. This change alone has been a huge improvement.
  • Branching and forking repositories is so much easier. This has allowed us to truly have our own testing environment for new additions without having to jump through hoops.
  • Pull requests are done when a branch is ready to be merged with master. This has allowed us to have developers submit their code for review prior to it being merged. It allows for an overall discussion of the code and the ability to comment on specific lines of code.
  • Ability to have bugs, enhancements and discussions tied directly to code. You can reference commits in comments to show exactly how an issue or feature was resolved.
  • README.md – This file at the root of the repository has allowed us to define specific instructions pertaining to that repository. It’s shown when you pull up the repository through github.com using markdown to make it easily accessible.
  • You can have a wiki for each repository to organize your application.

Working Locally

  • We’ve now setup our applications/sites so we can work locally on our machines using mamp.
  • This allows us to have our own testing environment so we aren’t competing against each other to test code on our development server.
  • A lot of time is saved since load times are instant.
  • It allows us to use codekit to automatically refresh the browser (another time saver), compile SASS/Compass the same way, and to minify our css/js for production use. It saves a json file to the root of your project so the config settings for codekit can be synced between all developers/designers.

Deploying to Development/Production

  • We are now using capistrano to deploy our websites instead of manually publishing files to each server.
  • Our process is that you can deploy any branch to development for testing, but only the master branch can be deployed to production.
  • Capistrano allows for releases of your project on the server. If something goes wrong on deploy you can easily rollback to a previous release to get the site working again.
  • We are logging each deploy using loggly so we have a record of who is deploying and at what time.

 

These changes to our workflow have boosted productivity for me by an indescribable amount. It feels so much better working this way. I’m very excited to see over the next couple of months how we can expand on this to make our workflow even better. If you’ve ever thought about changing your workflow for the better, do it. The time spent changing it is worth it!

Aug 13 / Rolaine Dang

Going Lean UX

While I was out recovering from my wisdom teeth extraction that put me out of commission for an entire weekend, I started reading the next book on my list. What a great read it was. It was easy to read, and I certainly took a lot away from it. The book is called Lean UX: Applying Lean Principles to Improve User Experience by Jeff Gothelf and Josh Seiden. I initially thought the book would help me design the user interface (UI) of the site to better the user’s experience since we’re are nearing the design phase for the Next wayne.edu. I couldn’t have been more wrong. The book describes how to make the process of a project more efficient and how to better evaluate the accuracy of the implemented design/feature to determine if it does successfully meet its goal(s) thus creating a better user experience! What business or group wouldn’t love to have this process in place so they can have a product out in the market sooner that actually works as planned! I know our team could use something like this, and many other companies have taken on some hybrid of Lean UX.

For the record, I’m drinking the Kool-Aid, and so will the rest of the Next wayne.edu team. Here are the reasons why we’re going Lean UX:

Within the current process, a project will accumulate a lot of things, including waste. Unfortunately, it is hard to identify waste from valuable items until the end of the project. Applying Lean UX will help eliminate waste that doesn’t provide any value, decreases efficiency and increases costs. Another reason to go Lean UX is it uses small collaborative environments of multi-disciplinary backgrounds that allow everyone involved to better understand other disciplines much sooner. Away with the waterfall process of handing over the project to the next person/phase. Gaining a shared understanding is the currency of Lean UX. Having everyone on the same page at the same time and tackling the problem together allows any issues and concerns to materialize early, which leads to an early resolution. Having a small team also makes communication manageable. It makes it easier to maintain focus, and it builds camaraderie and greater ownership of the product at an individual level. Last and most importantly, going Lean UX is having the mindset of adopting a model based on experimentation. There are no heros, ninjas, gurus or rockstars — only measurable outcomes and rapid experimentation to quickly determine the validity of the product against the goals through testing and iterations.

How have we applied it in our process?

Prior to reading the book, we actually had the base for the Next wayne.edu navigation in place. However, I tested one area of the navigation agains the proposed process that Lean UX suggested to see if it does hold true, and if so, show room for improvement as well as use this time to evaluate if Lean UX is scalable in our environment. The result is mind blowing. The initial content that was gathered for the ‘About’ area almost resembled the structure of the current ‘About Us‘ with a paragraph followed by a bulleted list with some alteration to the layout of the page. After my experimental venture with Lean UX’s processes, I shared the outcome with the team. The layout of the page started to transform. It went from just talking points with links about WSU to a site that can elicit emotions, build trust and change perceptions by using simple features to support measurable outcomes. Below is the sample wireframe of the working ‘About’ area in its infancy stage.

Current About vs. future About section

In the Lean UX process, there’s also a write-up that includes stating the hypothesis, assumptions, creating proto-personas and features. This is done prior to the wireframe. Here’s my ‘About‘(.pdf) write up that summarized the group’s intention since Lean UX pushes collaborative work and we did the base navigation prior to me reading the book. As rough as my write up was, it maximized the ‘About’ page in a way that can create an actual experience.

At the moment, I will continue to apply this Lean UX method through out the rest of the Next wayne.edu project to create a stronger foundation on what we already have. I can then run it through with the team and we can build/sketch the wireframes together. There are also particular design projects requiring collaborative design that I can’t wait for the team to do, like designing the header and footer, for example. This will allow everyone to come up and share their own idea of how the header/footer should function and look. What use to be just a one person job with two to four potential ideas turns into 6 ideas from 4 people and collectively improving upon the viable ones. All smiles on my end, especially now that we can push our designs out sooner once we have a minimum viable product (mvp) to test on our real consumers with live feedback right away.

I can’t vouch enough for this book and its processes/methods. It cuts waste, maximizes the product to its fullest capacity and delivers measurable outcomes. I hope you take the time to read the book and implement some, if not all, of Lean UX. Happy reading and good luck!

Jul 24 / Thomas Krupka

User Experience – Going undercover on your own Campus Tour

The Next Wayne.edu team wanted to experience first-hand what it’s like to see the campus from a prospective student’s point of view. How do you attain that kind of intel? You dress up incognito and sign up for one of our own campus tours, of course!

We scheduled our tour online and came up with some undercover personas.

Alex the stylish transfer student

Alex the stylish
transfer student

Tom the geeky helicopter dad

Tom the geeky
helicopter dad

Rolaine the international grad student

Rolaine international
grad student

Rob the undergrad incoming freshmen

Rob the undergrad
incoming freshmen

 
 

 

 

 

 

 

It was flawless. We weren’t even recognized by our own office. You could say we were deep undercover. Ok, maybe not. As we left the office, everyone laughed at our attire. Either way, the plan was set and away we went on our 90-minute undercover campus tour.

At the welcome center we were efficiently checked in with an iPad and put into a pretty typical grouping comprised of a mom with her two daughters, a dad and his son, a french Canadian couple interested in grad school and a few solo prospectives.

We stayed to the back, trying not to be obvious as Rolaine snapped a picture every 50 feet or so. We visited the usual “hot spots” that showed off our what our campus has to offer. This reminded me of all the amazing things Wayne State has on campus, and I wanted to carry this experience onto the next wayne.edu.

Is it enough to only worry about the web user experience (UX) we are creating with next wayne.edu?
No.

We have to think about the whole experience

By taking this tour, we could clearly see one of the first impressions our prospective students get by walking in their shoes. It can be one of the most useful ways to gain insight into how they see us as a university right from the start. This may or may not be their very first impression of Wayne State. Odds are their first experience will be through our website to sign up for a campus tour or explore what we have to offer.

This leads to some questions to ask ourselves as we re-craft wayne.edu to its Next evolution:

  • Is our end-to-end user experience as good as it can be?
  • Is the message/brand the same feel across web and real-person interactions?
  • What would the prospective student say to a friend about the experience they had?

Asking at these kinds of questions will help us to empathize with our users and come up with more seamless experiences from web to real world. Along the way, our users will utilize many different channels of communication to connect with us.  Keeping this end-to-end experience simple, consistent and well branded is essential to our success, including how our users view us and their ultimate decision to become a Wayne State Warrior.
Think about the whole experience
Illustration from Killer UX Design by Jodie Moule

Crafting these experiences with this in mind will make us a more cohesive unit at a departmental level. Instead of the usual hand-off, it will force us to work more closely together internally, ensuring the entire experience is amazing to the end.

Word of mouth (at blazing internet speed) is very important to a successful campaign.
How many times have you complained about a bad user experience?
How many times have you touted a great user experience?

Unfortunately, people are more likely to share a bad experience they had. Even small problems can lead to bad user experience. This can add up quickly, especially with how fast word of mouth spreads in this technological age. Looking at the prospective student entire experience first will help navigate the process through the many layers of interdepartmental depth. In doing so, we can create an experience that’s as flawless as possible.

If we can work together on an end-to-end amazing user experience, there’s no telling what else is possible.

 

Jul 24 / Rolaine Dang

How We See Color

Chapter 4 of Designing with the Mind in Mind talked about reading and how we process language (both spoken and read), along with ways to improve scannability and comprehension. Chapter 5 talks about color, including how our eyes process colors, visual limitations and guidelines for using colors.

If you’re someone like me who never learned about the anatomy of the human eye, reading about it was mind tingling! There was a lot of internal “ohhhh, so that’s how it works” moments. So let’s start!

How does the eye work?

Here’s a quick overview of the first layer of the retina’s anatomy. Our retina, where visual images, are formed has:

  1. Rods that detect brightness and are mainly used in low level lighting like a candle-lit dinner to help us get around.
  2. Three types of cones that are sensitive to the different light frequencies.
    • Low frequency light cones – span the entire spectrum of visible light but mainly yellow (middle) and red (low).
    • Medium frequency light cones – are the blues (high) and yellows and oranges (middle).
    • High frequency light cones – are the violets and blues (high) and some greens (middle).

How does our brain process the colors that we see when the cones detect color?

In the visual cortex of the brain, there are neurons grouped into three different channels called color-opponent channels. Each channel performs differently from each other and each does one of the following:

  • One subtracts the signal that is received from optic nerves coming from the low and medium frequency cones, creating “Red-Green” difference signal.
  • Another one subtracts the signal from medium and high frequency cones producing “Yellow-Blue” difference signal.
  • The last adds the signal from the low and medium frequency cones that produce luminance (black-white).

What can affect the way we perceive colors?

  1. Our visual system is sensitive to contrasting edges rather than seeing in absolute brightness or color. This allows us to see the same object on different background conditions. (See Figure 5.2)Screen Shot 2013-07-23 at 8.30.12 AM
  2. Factors such as paleness, color patch size and separation can affect our ability to differentiate color.
    • Paleness – less saturation between two colors makes distinguishing them harder. (See Figure 5.4 A)
    • Color path size – The size of the of the object will affect how hard or easy it will be to determine the color. The smaller the object, the more difficult it is to tell the color. (See Figure 5.4 B)
    • Separation – The greater the distance between two somewhat similar colors will make it more difficult to tell them apart. (See Figure 5.4 C)Screen Shot 2013-07-23 at 8.30.30 AM
  3. Dysfunction of one or more color subtraction panels (i.e color blindness) can limit a person’s ability to determine a particular color. The most common type of color blindness is “red/green.” Folks with this sort of dysfunction can’t tell the difference between colors like blue and purple or green and khaki.

Guidelines for using colors

  1. Colors should have great difference in contrast and avoid subtle color difference. Test the design/color by turning it into gray scale and if colors aren’t distinguishable, the colors aren’t different enough.
  2. Use of distinctive color such as black, white, red, green, yellow, blue. This causes a strong signal on one of the three color-perception channels. Other colors triggers more than one of the channels, making it harder to differentiate the colors as quickly and easily as black, white, red, green, yellow and blue.
  3. Use dark colors against light colors. Avoid pairing colors that are hard to distinguish by color blind people. Colors like dark red on black, dark red on dark green, blue on purple, light green on white.
  4. When using colors to determine differences between objects, use additional cues to help set one from another. (See figure 5.13)
    Screen Shot 2013-07-23 at 8.30.52 AM
  5. Separate the use of multiple strong opponent colors to avoid a clashing and disturbing shimmering sensation. (See figure 5.14)
    Screen Shot 2013-07-23 at 8.31.00 AM

Hope you learned something new as I have. Till next week!