Sitting in a kick-off meeting, little tedious, sometimes steals your energy. Simultaneously reading email, IMing, listening to the client, giving feedback. Occasionally thinking how lucky I am to be in this room, in this conversation, & what/who we’re designing the software we’re creating.
Don Draper now builds software for a living.
Clicking through the email subscriptions and discovering a conversation about why they’re doing software vs. advertising. nice. These are the small points of validation when you think your life/career works more like a series of winding rivers, and less like a decision.
There are some great gems in this article about WHY software needs design. & how people with creative backgrounds can influence in a positive (designed) way that people interact with software. Smaller software tailored to the user, not enterprise. Making it technically “work” is no longer the need, making it usable is now the hard part.
“…Charles Phillips, puts it: “using enterprise software sucks.” It’s ugly. Cumbersome. Difficult to use. And impossible to love. “When engineers started to build these incredibly complex systems in the early ’90s, their biggest concern was: how are we going to make it work?” …. Now that business technology can deliver those basic user needs, it’s time to ask: How can we make business software work beautifully?”
Great food for thought for those of us who get up in the morning sometimes not knowing what the day brings, but feel purpose & drive towards a longer goal. Making things work beautify is the same in User Experience as it was in Advertising. When it works, you know it.
This past Thursday I was fortunate to hear Bill Taylor of Fast Company speak at the Charleston Chamber of Commerce annual event. There were a lot of components to his talk that sounded like the culture we’ve created Sparc. The phrase that caught my attention was the “Architecture of Participation“. There have been many times that I’ve thought of gathering the right people in a room as being an “architect” of people. My friend Taylor seems to be an expert at that. Or when my developer buddy Josh “architects” a solution by knowing what technologies play well together & essentially get shit done. This type of “architect” means as a leader, you facilitate problem solving by leveraging your team for the solution. That’s why we have a team, right? I think we were already doing this well, but sometimes having a word for it helps bring these quiet practices to light; formalizes them.
What interests me in the Architecture of Participation is how it calls out a leadership style I’m very comfortable. Traditional leadership has relied on the leader to identify & solve a problem on his own, then project the solution onto the people below them. The concept of leadership through participation means that rather than working in a vacuum, I can leverage the smart people around me. In the end, they’re typically the ones implementing the solution – this helps them “own it” as well. The Architecture of Participation simply means I facilitate the conversation & then let people be good at what they are already good at. Coming from a creative background, we (my team) is already skilled at working as a team – nothing new here. Learning & creative process intentionally leverages diverse skillsets, so why not problem solving on a leadership level?
I moved forward w/ a plan this past week to create “advocates” within our design team. Motivated individuals who can help lead the team in one aspect of design. This scales me, and offers the opportunity for these smart people to own a focused element that we need as a team. The advocates focus on aspects such as design quality, user experience or front-end development. Things our team need, but I can’t always facilitate the conversation 100% of the time on.
It’s a great thing to work with talented people. By creating an Architecture of Participation, we enable more creative solution & allow the smart people we work with to scale the team as a whole.
One recurring theme as I watch the way our team works: the fine balance of design philosophy (why) vs. Get-Shit-Done attitude (how):
Are we just copying what we see? As designers, are we more often emulating what we see around us rather than “designing” or creating something new. Is it the job of the Artist to be “original” and the designer to emulate? or does the designer constantly look for opportunity and create smaller shifts as they observe. If an artist is large jumps, is “design” a series of smaller responses and shifts over time? Would a client understand something they’d never seen before… something without visual roots or a comparison… “Microsoft is using flat design, so can we”? or to truly change the landscape, it it a series of small moves, tied to a known history that allows designers to be original… And do we really understand what we’re doing?
In some ways this conversation is half in my head, and fragmented between many good conversations on our team. A little bigger than the response to skeuomorphism in the current design trend in flat design. The internet makes it too easy to borrow when convenient and trendy. Guess it’s a good thing I like most things (except the color-blind colors :/ ) about the current design trends. No one trend or concept stands alone without perspective.
One thought that brought me back to this subject this morning while reading an article by John Maeda:
Ultimately, good design will be born from consideration of multiple perspectives. It should be something we haven’t even dreamed of yet.
How do you create “successful” software ?
The first ingredient is having a vision. Something you’re passionate about. And how that vision is vetted, digested and eventually executed on. Digesting that idea into its essence and creating a minimum-viable-project plan that can be developed.
The second ingredient having the right team: a great client, project management & requirements, a group of dedicated developers and designers aligned to the seeing this vision succeed. Executing on this plan through Agile software development & launching the beta software.
Sparc has done dozens of projects internally & with commercial partners. We know how to design & develop software. But does that make it successful?
The Success Phase.
We understand the “Idea” phase & we understand the “Build” phase very well. What we’re quickly learning more about is the “Success” phase.
This is the phase that happens after a software launch and has begun to receiving feedback from the marketplace. We came to realize quickly that if we don’t support our clients in being successful, no matter how good the idea or software is, the effort fails. When a client talks about his experience with SPARC, we want him to recollect a team looking to make him successful, not just robots who build software then blindly move on to the next project.
Part of the phase relies on our ability to help the client market their product. Our clients vary greatly in organizational size from established companies to start-ups. Some organizations have a degree of experience or people in marketing roles, but they all have the same post release challenges. We’ve invested heavily into understanding this process ourselves with our own products, so it makes sense to do the same with our clients. The design & marketing efforts we need internally is the same needs of our clients.
No one on our design team is a single role player. Every designer has strengths in building websites, collateral & advertising. Following the release of software, that same cross functional team of requirements, marketing & designers can continue to support the client’s marketing efforts. And it’s that alignment between our team and the client that help make the software successful.
Quick thought that should be incorporated into a bigger post someday. I came to “design” through an education in Architecture. Little unconventional, but there were several messages that were imprinted early on, and I still come back today.
3 rules for solving problems.
Something that stuck in my mind like glue from my first year of study was our professor Jay Stoeckel’s mantra: when you get stuck on a problem, change one of the variables. By changing either media, scale, or concern, you can often solve the problem that’s stopped you.
Change Media – getting away from the computer for the sketchbook? or charcoal instead of pen. Shaking it up a little will often open the problem up.
Change Scale – Get perspective on the problem, zoom out. or zoom in: is there a small detail in the design that starts to solve other parts of the whole?
Change Concern – this is probably the one I use most often: what is the concern of the problem resented to you? what does it seek to solve? And when you change that intent, or question it, or find a new goal, how does that shift your thinking. In software, we often have multiple user personas; look at it to a different persona’s concern.