Web Design in Lansing

by

Greater Lansing Web and UX Design

Matt Borghi Media and Design is a full service digital agency doing web design in Lansing.

My work focuses on web design, UX design and search engine optimization (SEO). However, I also offer a variety of other digital and electronic communications services.

I’ve been doing web design in Lansing for over 20 years. I take a user-centered approach to all of my design work and that has allowed me to help many small businesses and non-profits realize the potential of their websites and their online presence. But what good is a great website if nobody can find it? By applying SEO-Search Engine Optimization best practices, I can help my clients improve their search engine rankings and their online visibility.

I’ve worked my entire career in Michigan’s capital city of Lansing. Because of this I’ve gotten to know the people, local vendors, what works, what doesn’t and how to keep things simple and moving forward.

Keeping a website current, fresh and relevant is my specialty. I have all kinds of tips and tricks for making a great website.

Over the years, I’ve worked on and created many kinds of websites, including:

  • Small Business Websites
  • Non-Profit Websites
  • eCommerce Websites
  • Social Media Websites
  • Event and Event Registration Websites
  • Wedding Websites
  • Memorial Websites
  • Family Reunion Websites

If you’re looking for an honest and reliable web design partner to get your project off the ground, look no further. I love working on new websites, breathing new life into old ones and generally talking to folks about their web needs. Please contact me today about your web design needs.

Besides doing web design in Lansing, I’m very active as a greater Lansing musician and composer. My music has been featured on Music from the Hearts of Space, Echoes with John Diliberto, NPR, PRX, BBC and the CBC and Matt can be found regularly performing around town.

The 5 Most Popular Website Design Types

by

Website design types vary, but in my 20 years of doing web design, I’ve worked on all of them. Blogs, eCommerce sites, event websites, online magazines, business websites, nonprofit websites, web forums, portfolio websites. You name it and I’ve probably worked on a few.

Because many of my clients are new to website design, I wanted to create a list of popular website designs. I don’t consider this an exhaustive list. However, 90% of my work falls into one of these categories.

Brochure Website

The brochure-style website is the most popular style of website that I’ve worked on; think of this type of website as an online brochure or virtual business card. It’s usually short and to the point. This type of site is under ten pages and usually focuses on a product or service. Typically, you can make contact via the website, learn about hours and locations. I include restaurants, auto repair shops and other ‘mainstreet’ businesses in this category. I also call this style of website design  “brochureware”.

Informational (Small Business and Non-profit) Website 

The informational website design is for small businesses and non-profits. While this website design is similar to the  brochure style it contains more information. This website could include information around bylaws, financials, organizational mission, vision, locations and ways to connect with officers and staff. This website design is kind of like a grown-up brochure website; more responsibilities and user needs to serve.

eCommerce Website

The eCommerce website can be standalone like Amazon or eBay or it can be integrated into larger informational website. For instance, a small business website for a restaurant might also have eCommerce functionality to purchase gift cards. A non-profit website might sell things related to their mission, such as a construction safety organization that also sells discounted safety equipment to its members. The eCommerce website style varies, but it’s always transactional with the buying or selling of goods and services as its core call-to-action.

Event and Event Registration Website

At the intersection of the eCommerce and informational website is the event and event registration website. I think of the event website design as one that showcases events and provides a way to register online. Event websites can be standalone such as for music festivals or religious gatherings. I’ve also integrated event websites into eCommerce and informational websites. For example, a small business could sell trainings, where a user could register to attend.  A non-profit might hold retreats or seminars where a user can register and buy tickets online.

Blog/Online Magazine/Content Website

The blog, online magazine or content website(i.e. Vice, YouTube or Pinterest) is designed for users to engage and interact with content. Content takes many forms: Watching funny cat videos, looking at retro interior design photos, reading about putting Ikea furniture together or just the daily news. These are the oldest kinds of websites: People going online expressing their views, perspectives and life experiences and sharing them with others. These types of sites have been around for a long time, but they haven’t changed. ‘Content is King’ and  creating fresh content is central to getting website visits and good search rankings.

That’s it, in a nutshell.

When I work on a website design, the goal is always the same: Help the user complete a task quickly. In order to help the user, you have to understand the user and which kinds of website designs work best.

Getting it Right – Navigating Web Design Ambiguity

by

 

Jonathan Walter has written a great article, Navigating Ambiguity, at UX Matters. It’s part of a series of columns that focuses on enterprise UX, or as he puts it ‘designing experiences for people at work’ – That’s what drew me in, initially because there’s much written about new development and design from a UX perspective, but enterprise work is often the overlooked and neglected ‘other’ that’s not considered very glamorous and doesn’t get the attention it deserves where UX is concerned.

As I began reading the article, thought, I realized that he was a kindred spirit of sorts, because I use the phrases: “Navigating ambiguity” or in jest, “parsing the nebula” just about every day when solving problems with digital experience and software functionality development, roadmapping, etc. We, individually, and as a team, have to understand what we’re trying to do before we can map it, plan it, work on it, but particularly, deliver it. Jonathan provides some great insights on that.

Get comfortable with not knowing everything

Jonathan writes:

“Even in situations in which you feel alone in your lack of knowledge, you must become comfortable with saying, “I don’t know.” In his Forbes article, “The Power of Saying ‘I Don’t Know’,” Gaurav Gupta states: “We are conditioned to having and providing quick, confident answers as a sign of competence and leadership. We behave as though any gaps in knowledge should be hidden at all cost. But is this desire to have an answer—and have it quickly—actually helping you? How often do we trade factual accuracy and thoughtfulness for immediacy? Why do people find it so hard to say, ‘I don’t know’?”

Ask (the right) questions

I would say, just ask question, as you don’t know what you don’t know. It’s a journey of a thousand miles, start with one step. Additionally, Jonathan adds:

“…ask the following W questions to reduce ambiguity and approach a problem from a higher-level perspective:
  • What problems does this product or capability solve?
  • Who will use it?
  • Why will they use it?
  • When or in which context will they use it?
“…Once you understand this high-level information, you can ask progressively more specific questions.”

Provide a vision

This has been hugely important for me. I never had any idea how often I’d have to repeat, dramatize, articulate and visually represent my vision for product or experience. Jonathan puts a finer point on this that I really appreciate:

“…your vision—even if it is overly aspirational or flawed—provides a North Star that product-team members can keep in sight as they develop a product. It can also serve as a useful artifact for identifying which features are in scope for early releases and which you should defer to later releases. “Just take care to avoid leading stakeholders to believe that the vision is final.”

I’ve only scratched the surface on Jonathan’s great article, but I highly recommend you give it a read; if you’re interested in UX and process, you won’t be disappointed and the information is as practical and steeped in experience as it is easy to understand and put into practice. Again, you can find that article here.

For web design – Use your backlog!

by

Screen Shot 2018-04-11 at 8.18.27 AM(Graphic courtesy of of this deck from Reinhart De Lille)

 

Interesting article here by Guy Ligertwood – 11 Valuable Lessons I Learned While Working in the Real World of UX. The article, as a whole, got me thinking about the difficulties of agile, UX and specifically some thoughts around my early days of of backlog grooming and development.

Guy writes:

“Put it in the backlog and we’ll get back to it (never)”

 

Sadly, Guy’s not far from the mark. Frequently what goes into the backlog just doesn’t get revisited, mostly because it’s the non-priority, non-MVP (minimum viable product) options that get left behind (See the ‘Backlog Iceberg’ above). Movie editors will talk about losing parts of a story to the cutting room floor; Product manager’s lose stuff that isn’t a priority in the backlog. Backlogs are intended to be living and breathing documents that, especially during the critical start up phase, get much attention, but as market priorities shift, new products are released and organizational focuses evolve, older but not less useful backlog items get neglected. More than once, even right now as I type these lines, I can think of great functionality and features that didn’t make it into a releases I had hoped… the ones that got away… Well, maybe not ‘got away’ because as a Product Manager you have to hold on to those ideas, functionality and features for the right time.

Guy further writes:

“We hear lots about doing the best for the customer and in lots of cases we do, at first. The problem lies when we don’t get back to iterating on designs when delivering becomes more important…”

Again, Guy’s not wrong. As a product manager, you have to always be on your toes — Thinking, grooming and prepping the backlog, because iterations and sprints move quickly and they won’t wait for you. Nailing your cadence, watching the team’s velocity, negotiating stories, etc. are all the things that will keep you prepped and ready to hand off wishlist features and functionality that might not have made it into to early releases. If used consistently, the backlog can be the product manager’s best friend. If we’re doing our jobs as product manager’s well, there will be very few features that ‘got away’…

The Evolution of UX

by

As far as web design in Lansing goes, I consider myself one of the most vocal advocates for user experience design. When I saw Ian Armstrong’s article on the evolution of UX, I was sure that other folks doing web design in Lansing would want to learn more –  Check out Ian’s article here. Additionally, I will add a few of my own points based on my reading of the article, but a full read is a must.

lean ux design lansing

Ian states that “in its purest form, UX Design is waterfall based.” These days, in most circles where folks are talking about UX, ‘waterfall’ is a dirty word that hearkens back to rigid PMBOK processes and exhaustingly long requirements gathering sessions, but Ian’s absolutely right. You have to get a sense of requirements, gather perspectives, mock things up, test out assumptions, wash, rinse, repeat. It’s waterfall. There’s no way around it.

Ian nails one of the key problems with being outcome based, what we work towards with agile vs. requirements based. This is a conundrum that many of have faced and still work to reconcile:  “Whereas classic UX is requirements based, Lean UX is outcome based… Designers found themselves under immense pressure to fill a sprint backlog before they really understood what they were building. As a result, a lot of development cycles got burned on features that never made it into the final product.”

So much development and rework lost trying to anticipate product needs… <sigh>

I’ve read a lot about the Google Ventures Design Sprint, and attended a session at an O’Reilly Design conference where they talked about it, but even then, Ian’s explanation is as succinct and spot-on as any I’ve come across:

“Google Ventures conceived the design sprint, which allowed teams to rapidly define and test a low-fidelity prototypes. This jump-started the Lean UX cycle on emerging product teams and effectively eliminated the waste and rework problem.”

I’ll put a pin it there. Check out Ian’s original article.

If you’re looking for web design in Lansing that puts your user’s experience at the center of their work, then get in touch today.

Product Management is Product Thinking

by

usage_ux_product_thinking

John Cutler wrote a great article here: We Need Fewer Product Managers. — To a Product Manager, it’s a provocative, and maybe disturbing title, but I definitely get where he’s coming from.

He writes:

“…We need more product thinking, and less product managing.

You don’t need a product manager to:

  • “Get work done”, and keep the team focused
  • Manage projects, and give status updates
  • Manage a team, and advocate for the team
  • Have “accountability” for shipping features/projects
  • Facilitate standups, planning meetings, and retrospectives
  • Talk to customers and users
  • Measure the impact of work, and design experiments
  • Write user stories and requirements
  • Test work with customers and users

We have roles (hats) for these things: project managers, UX, researchers, data scientists, business analysts, team managers, coaches, etc. Do product managers often wear these hats? Sure. Do you need a product manager to wear these hats? No.”

John’s exactly right.

We have roles for these things, for these many and varied disciplines. Of course, especially in the beginning, there’s usually one evangelist wearing a lot of these hats, but as an organization matures towards a product-centric approach, the role typically known as the product manager, rather organically, becomes that of the product thinker. I’m confident that, in time, the natural evolution that brings together, seemingly disparate, disciplines like UX, IT and business needs will be thought of as a whole instead of separate parts. This is the natural outcome of truly undergoing a digital transformation. That evolution is happening, albeit slowly outside of software development organizations, but it is happening.

The best product managers start in UX

by

ProductManager_UX_Venn

Some may find this controversial, disagree or just find it to be utter rubbish, but I believe, in the venn diagram of product management, it’s the background in user experience that truly makes the best product manager. I believe that in time, it will be UXers and UX designers or folks who came up through design that will eventually come to be the best product managers. You can have an understanding of the business. You can have an understanding of the IT. In both of those cases you’re removed from what the user are looking for and what they’re hoping to achieve with the product, and focused on the other facets of the respective discipline.

I also believe that there will be a time, when those designers have to tuck their design experience in their back pocket (design and UX thinking are likely second nature at this point or maybe that was just the case for me) and start to learn about the business and the technical aspects. This pivot is the thing that will leave some designers disinterested, some may even find it unsavory, and because of that I think that many designers will stick with their respective discipline of design, but for those who have that broad-ranging curiosity about all of the moving parts of their product I think it will be the UXer/designer that will be the discipline to lead product management.

Evangelizing for UX Without Overwhelming Your Organization

by

evangelism_evangelize_ux

So you’re organization wants to get started with UX? Maybe your CMO heard about it at a buzzword-filled session at some marketing conference or as a designer you’re tired of designing, by committee, things that don’t meet user’s needs, or maybe, you’re somewhere in between? Whatever the case, you’ve found yourself at the front lines of advocating for this new approach and all that comes with that. Ok. So do you want the good news or the bad news first?

Bad news…?

Alright. Like me, you like to get that out of the way. Understood.

The bad news is that it’s going to take a lot of time, a lot of passion and a lot of energy. However, you might also find yourself here, because I learned that I liked promoting and talking about UX as much as I liked sitting down with a Brian Eno/Harold Budd record and a hot cup of Kona blend to design (actually, maybe even a little more).

The good news is actually pretty great news.

UX has a value proposition that’s pretty hard to argue with, at even the most change-averse organizations.

As with everything, though, there’s a balance. How do you evangelize for the value of UX without overwhelming the organization?

With all of the day-to-day activities it can be hard to introduce new processes, especially if an organization doesn’t think that there are any issues with the current processes and it looks like you’re adding a greater degree of complexity for no apparent value. No worries, but do keep this in mind: Organizations, like people, generally resist change, so like with any kind of change, the less scary you can make something, the better.

The Problem

Before doing anything with UX you have to establish what the problem is. And even though, you, as a designer, are most familiar with the users, and most sympathetic to their needs, and all of your education and experience tells you what the problem is, you have to make the adoption of UX, not about your opinion, or your feelings, but about user problems based on usage data.

Hopefully, you’ve been tracking stuff with Google Analytics, or an occasional survey or maybe some other voice-of-customer feedback tool; if not, no problem, there are a variety of tools you can use to get started. A few examples are: Google Analytics, GoogleDrive surveys, do-it-yourself user interviews, and A/B tests based on paper prototypes. These are quick and dirty ways to begin collecting data on your users, but usually, it doesn’t take a ton of data to begin to see issues, patterns and the areas of discontent for users. Start collecting the data.

Now that you have some usage data it’s time to highlight the issues and to talk about the solution, which is building the UX discipline into your organization.

The Solution

Evangelizing for UX in organizations that already understand it and think it makes a lot of sense are not really the target audience here, so we’re going to focus on the other kind: The organization that doesn’t understand UX and finds any kind of operational change suspect.

Getting an organization interested in UX is a journey of a thousand miles, with each conversation about user data, each shared interaction on user pain and each reference to the concept of ‘user experience’ being a single step. For my mind, the slow-grow approach of evangelizing for UX is the only way, because an organization that goes too fast will get operational whiplash. We don’t want that.

As I stated at the outset, UX creates a value proposition that’s hard to argue with, but people don’t know what they don’t know, and it’s your job to teach them.

With that said, some folks will still try to argue the value of UX. You’ll hear things like “Why would we do this? The users are happy.” Or, “the users don’t care.” Or, perhaps, my favorite “This is the way we’ve always done it, why should we change?” These are not qualitative arguments, these are barely opinions, mostly they’re smokescreens meant to discourage you. Don’t be discouraged. You have your data, you know where the users are struggling and best of all you have a solution to fix it.

The Practice

Often, there’s the question of where one should start with UX and I believe that you should start right where you’re at.

First and foremost, you can talk a lot about UX, but if you can show the results that’s even better… as the saying goes, ‘show, don’t tell.’ Look at ways to integrate paper prototypes into design discussions. Conduct A/B tests internally with fellow employees and organizational leaders. Use low-res mock-ups or wireframes and talk through the interactions. Getting started with UX can be very low-tech and yield incredibly satisfying results, as well as creating positive experiences/stories that will be shared throughout the organization.

At work here, also, is the idea of creating ambassadors for organizational change. I originally heard Eric Quint, Chief Design Officer of 3M talk about this at an O’Reilly Design Conference and it really stuck with me.

The idea is this: The square root of an organization’s employees equals the number of ambassadors needed for organizational transformation. So, if you have 1,000 employees, then you need 31 ambassadors/influencers talking about an idea to effect organizational change. While I never heard of an equation for organizational transformation put just this way, it’s darn accurate in my experience.

The funny thing about the actual practice of UX is that somewhere between getting started, unofficially, just to ‘see how it works’ and full-blown processes being established the discipline of UX takes root. I’m sure it could go the other way, but that’s just never been the case for me. When organizations start to see the positive results of UX and the empathic consideration of a user perspective, it’s as if some area of our lizard brain is triggered, with even those most opposed to the change, getting involved in serving the user. It’s radical and adoption of UX slowly takes hold.

I’m sure there are other, top-down ways to introduce UX. There can be mandates given and directives written, but UX, like any organizational change works best if it happens organically. Whether we’re talking UX or picking a new office supplies vendor, there are varying levels of awareness, acceptance and adoption. In this regard, organizational change works best through gradual repetition and iteration. The worst thing that can happen is that an organization gets overwhelmed by change, UX or otherwise. UX can be a lot of fun, and mostly, folks want to help one another, the user-centered perspective of UX makes it a great practice, not just for making better products, but for bringing people together to solve a common problem.

Takeaways

Do:

  • Collect usage data (web analytics, DIY surveys, voice-of-customer feedback)
  • Show, don’t tell whenever possible
  • Have fun spreading the word of UX with fun exercises
  • Create UX ambassadors

Don’t:

  • Get frustrated if change doesn’t happen quickly
  • Lose sight of your UX goals
  • Give up

 

Lean UX and agile – The one-two punch to quickly knock out great work!

by

usage_lean_ux_agile_diagram

It’s probably because it’s something I do everyday. I don’t think much about it. Or, maybe, I don’t want to think much about it, because day in, day out, it’s where my focus is. However, I do think that it’s supremely important… I’m talking about integrating UX into agile.

One day I’ll probably write a book about it. I love giving practical advice and sharing my experiences, in fact, that’s one of things about agile that I really love, the community-based, open source aspect of the community around agile. Whether you’re looking at scrum, kanban, scrumban, or something else, agile is a great way of working with your development team and it’s also excellently positioned to take advantage of UX practices.

Specifically, (WARNING: Much jargon ahead) I’m a fan of Lean UX, say, as opposed to, agile UX, which honestly, it looks like it is falling out of favor for some of the reasons that the Nielsen/Norman group captured here in their article Doing UX in an agile world, specifically:

…most teams don’t conduct user research on a consistent basis, if at all. People cite tight deadlines and staffing shortages as reasons for deficiencies in user-centered activities.

Research and user testing are two areas that are very difficult to integrate into agile UX. Lean UX, on the other hand, considers this, and in some ways is really an agile UX 2.0. This is important, because the need for that research and testing to happen in real time is super important to the ongoing design and development process. Unlike a waterfall approach, there usually haven’t been requirements or JAD (joint application design) meetings; instead, you start with a basic road map, some use-cases, a couple user stories and get to work. Lean UX thrives in this situation.

Ok, I say, Lean UX thrives… yes, that’s true, BUT… teams have to get used to working with one another and they have to round off the rough edges and bad habits, whether of the development or the interpersonal variety. Lean UX and agile don’t leave a lot of margin for getting mired in unnecessary details and some of the interpersonal issues that may pop up when a team is just getting started. Nevertheless, when it comes together, and when the gelling starts, the team’s pace and work can be exceptional!

I find Lean UX or the idea of UX that can work at the speed of agile to be very exciting, especially if you’ve ever been involved in a waterfall development project or something that was just slow moving. Lean UX and agile are the one-two punch to quickly knock out great work!