ForgeConf 2016: A UX conference that embodies the principles it presents

September 26th was a bright, if a bit brisk day in Philadelphia. The weather had finally gotten the memo that Autumn had arrived, but the bright sun made walking from 30th Street Station to the University of Pennsylvania campus more of a delight than a hindrance.

Penn is the home to the largest university museum in the United States, and on that Monday morning, the Penn Museum was the home of the third annual Forge Conference. The two-track conference is one of Philadelphia’s best User Experience and Product Design events. This year’s conference illustrated exactly why designers from as far away as Moscow, Russia arrived — and why the Mayor of Philadelphia was willing to join the conference for a post-lunch Q&A.

First, there’s the speaker line-up and the talks themselves. I wish that I was able to summarize all of them, but my cloning machine is still on the fritz and one of the biggest challenges of ForgeConf was picking which sessions to attend because they were all very good.

Amy Cueva from Mad*Pow opened the conference with an inspiring keynote about purpose-driven design that set the tone for the rest of the conference. “Design gets us from where we are to where we want to be,” she pointed out. “It isn’t enough to imagine better experiences. We have to move from thinking to doing.” Her session wasn’t just about inspiration. It was also honest discussion of why doing the right thing for the user also brings us success at the boardroom. “What is good for the people we serve is ultimately good for the business.”

The next two sessions were split between the larger Harrison Auditorium and the smaller Widener Lecture Room, which participants reached by walking through the Golden Age of King Midas exhibition. I opted to attend Amanda Stockwell of Stockwell Strategy’s presentation on incorporating the Build Measure Learn loop from the Lean Startup method into design. I would have loved to also attend Diogenes Brito’s talk on Design as a Service: Earning a Seat at the Table.

Amanda’s talk was based on the Build-Measure-Learn loop of the Lean Startup methodology’s core principles. Amanda connected the loop back to the scientific method, specifically the “experiment” phase. To build, measure, and learn, we need to develop minimum viable products that allow us to measure meaningful data that allow us to satisfy a hypothesis. Once satisfied, we can decide whether to continue down the path we’re on or pivot the product and iterate through the sequence again.

UX cycles based on Lean Startup presentation
UX cycles based on Lean Startup presentation

Amanda’s presentation was filled with good, concrete examples surrounding cupcakes and cats, and I learned more about Lean in that session than in any number of thinkpieces I’ve read before or since.

I stayed in the Widener Auditorium for the next session by Tom Wlodkowski of Comcast. Over in the Harrison Auditorium, Gina Pensiero and Sara Getz were speaking on Manufacturing Scarcity: Limited Content & Digital Luxury.

Normally I avoid conference sessions by speakers whose companies are also major sponsors, because I’ve already seen enough advertising pitches disguised as conference talks to hold me. Tom’s talk was different. Tom is the Vice President of Accessibility for Comcast Cable. His talk, Accessibility Equals Innovation, explained why accessible innovations are important. “One third of households in the US have a disability. 48% of people with disabilities are also heads of households. They have $200 billion in discretionary spending money.” He explained how many of the technologies that we all use today, including the typewriter, were initially invented to aid people with disabilities. But focusing on only those who identify as disabled isn’t effective. “Ninety five percent of people who can benefit by accessibility technology don’t identify as being disabled.”

Tom brought a voice remote and a set-top box emulator with him to demonstrate Comcast’s accessibility options. The voice remote allows the user to press a button and speak commands, which is handy not only for the blind, but also for those with physical disabilities, cognitive issues, or English as a second language. The set-top box can be configured to read the menus and the interface so that it can be navigated either visually or aurally. He also demonstrated the “voice description” feature that allows blind customers to experience a deeper enjoyment of television through a voice track that narrates the visual elements on the screen.

Lunch took place in the Chinese Rotunda, surrounded by antiquities in one of the oldest domed halls in the city. The break was long enough to allow us to eat with leisure, socialize, and watch the koi in the pond out front.

The koi pond at Penn Museum
The koi pond at Penn Museum

After lunch Keith Scandone, CEO of O3 World, held a Q&A in with Mayor Jim Kenney. Most of Mayor Kenney‘s answers were not directly about design, but they pointed to the challenges of designing and managing complicated systems like city governments. For example, decriminalizing marijuana possession helped to increase police coverage for more serious crimes, because Philadelphia was booking 4,200 people a year for minor marijuana offenses previously.

Philadelphia’s poverty level is 26%. Making practical funding calls requires strategic thinking. Hosting the Forbes 30 under 30 with a city contribution, for example, wouldn’t have been a good investment for the city, but hosting the Democratic National Convention was. Philadelphia arrested no one related to the DNC convention, and one of the protestors stopped the mayor to tell him our police force is awesome. The mayor works with the police force on community-police relations. “It starts from a place of respect,” he said. “You can’t go after people with expletives. You have to explain why you stop someone. Be polite, build a relationship.”

It was the first time I’d seen a sitting politician speak at a design conference, and it was a good choice. I came away with a better idea of the design and strategic challenges of running a city, as well as quite a bit of respect for those running it.

After the Mayor’s session, I stayed in the auditorium to hear Steve Hillenius from NASA speak about The Internet of Things In Space: Building Compelling User Experiences. In the Widener Lecture Room, C. Todd Lombardo spoke on Designing Design Process for your Organization.

Steve’s talk was about the Internet of Things (IoT) and how we haven’t really managed to progress it past the “stick chips to existing things” stage so far. As a result, most IoT devices aren’t particularly compelling or even all that useful. Further, they’re scary. No one wants to reboot their door, or their lightbulb.

NASA is tackling the Internet of Things to solve concrete problems on the International Space Station (ISS). Each mission consists of only a few astronauts, and today Mission Control controls most of the ship from the ground. But this structure isn’t scalable for Mars missions or even lower-cost ISS missions. The goal is to make the astronauts on board a ship more autonomous and less tied to voluminous paper procedures and Mission Control. “What if we could guide an astronaut to do procedures without training and the objects they were installing knew whether they were installed correctly?”

They used accelerometers, haptic, and augmented reality to develop all the objects in a procedure and be able to tell where they were located, then walk the astronaut through the installation and provide natural and convincing feedback. The project is still working through testing, but the video Steve played demonstrating the technology made me wish I could put it on my wallet and scissors today. (Yes, scissors.)

Lija Hogan spoke on UX Research = UX Innovation, with Alissa Briggs on the other side speaking on Design Leadership Means Business. Lija’s talk focused on how quality user testing allows a product development team to gather and use data, investigate systematically, and experiment aimed at discovery and interpretation. One of her examples covered the daily iterations an elementary school uses to increase their effectiveness. “This is how things went today. What are we going to do tomorrow to make it better?”

We developed the field of usability, Lija explains, to ensure that users could complete tasks. When we’d made progress there, we moved our focus to user experience – do the users even want to do the tasks, regardless of how usable the interface is? And our most recent direction is toward Customer Experience (CX) – are we advocating for our customers and cultivating our relationships with them appropriately? Basic research followed up with a strategic research program is the key to reaching the next levels of customer engagement and organizational UX maturity.

 

http://www.alissabriggs.com/index/
Lija Hogan’s Customer Experience Definition

The final split session of the day, I attended Frank Yoo‘s talk on Career Growth through Deliberate Discomfort. My other choice was Clemente Miller‘s Motivational UX: The Art & Science of Digital – and Human – Behavior. Frank’s talk interested me because I’m always looking for ways to grow, and sometimes we need a little external motivation to remind us that it’s OK to be uncomfortable.

Frank quoted Jenn Chen as saying “When you’re frustrated or scared it’s just your body telling you to grow,” and that summarized the point of Frank’s talk quite well. We have to be willing to feel like fish out of water when we first start a new experience, and use that feeling to learn. “Sometimes you have to crack the door open just enough to see the opportunity you will actually want.”

We have to embrace our inner imposter and admit we may not be good at something in order to learn the skills to be great at it. “Getting up to production speed allows you to become more creative, so you can grow from tactical to strategic work.”

And we have to embrace the fact that change is always coming, both externally and internally, so sometimes we’re going to grow out of the space we’re in. “Being a veteran in your own discomfort means you’re prepared.”

Bear Grylls - Sun's going down, better drink my own piss
Bear Grylls is a veteran at discomfort

The day ended with Albert Poon‘s keynote, Everything I know about Managing Designers I’ve Learned From Coaching Youth Sports. “If you have a vision to do something big with design, you will have to lead a team,” he explained. Learning how to lead is tough, even for experienced designers that have been facilitating meetings and running projects for years. Albert’s been leading for long enough to know how poorly his first management experience went, and how learning to coach youth sports (specifically his son’s baseball team) was a great boon to his skills.

“Leaders are completely responsible, and you have no control. You’re never the one up to bat, and you’re never the one in the field.” You can’t do everyone’s job. “Any success is theirs, and any failure is yours.” As a manager, your job is to build and nurture a team so they can do great design. His keynote was structured around ten tips for becoming a better manager (one for each inning, including going to extras).

Albert Poon's 10 tips for management
Albert Poon’s 10 tips for management

Albert’s talk was the perfect high note to end the conference on, because it wrapped together so many of the themes that we’d heard throughout the day about empathy, quality, bringing people together, and being willing to grow. “Mostly it’s listening, learning, trying, failing, and adapting.”

I felt a little bad for the folks who weren’t laughing at the baseball references – there were some pretty funny ones — but the Phillies have been pretty bad for more than half a decade so I guess we fans are in a decline again.

The quality location, compelling topics, and excellent speaker presentations were three great reasons to attend ForgeConf. The super-comfy tee and water bottle that came in our swag bags were also perks that, while they wouldn’t compel me to attend a bad conference, were icing on the cake of an excellent one. But there’s one more reason to attend ForgeConf that not every conference can match, and that’s the time that the organizers clearly put into designing the conference itself.
For example, the speakers weren’t just excellent at their craft, they were clearly chosen to represent the diversity of UX as an industry. The speaker list is almost evenly split between men and women and included a larger-than-normal-conferences number of racial or ethnic minorities. It was important to me to hear the hard-working women I know are in our industry represented by the speakers, and I’m sure it was just as important to other attendees to see people who represent them get a chance to speak.

Especially appealing was Tom Wlodkowski’s attendance as a speaker, because while awareness of accessibility is on the rise, it’s still rare to see UX folks with noticeable disabilities attending our conferences, much less speaking. Hearing about the issues Tom faces in his own voice — and the changes that he’s bringing about on behalf of all users — was as meaningful as the presentation he gave.

The ForgeConf speaker line-up was clearly curated with the knowledge that diversity of thought matters, that Representation matters. Had the staff not put the effort in to procure their speakers, all of the talks that discussed empathy would have fallen a bit flat.

The staff didn’t stop there. They also provided a Code of Conduct that aligned with their implied values of diversity and empathy. While I know some in the industry don’t see the value of a Code of Conduct, I do.
And the people! The staff were always open to questions, even complicated ones. They knew the location, understood what was going on, and were willing to answer any questions that attendees had. They were the kind of helpful and friendly and down-to-earth that earned Philadelphia the name “The city of brotherly love”.

The combination of the code of conduct, the line-up of speakers, the staff, and the quality of design that went into every step of the conference made it an event I intend to attend every year if I’m able. I’m already looking forward to the opportunity to pre-order tickets next February, and I recommend that you do the same.

 

Editor’s note: Conferences are a big part of how UX designers learn and develop. We would love to publish more reviews of conferences. Write for us!

Doing Agile Wrong: Two Big Up-Front Designs

In my last post, I explained that I’ve been tweeting about a Big Up-Front Design project and folks have been replying to me that I’m Doing Agile Wrong.

To which I replied, via that post, that Agile is a development methodology, not a design methodology, so of course my design process isn’t “agile”.

There’s more to the assertion that my choice to use Big Up-Front Design is wrong than the semantics of the word “Agile”. There’s an implied belief that anything involving up-front work is inflexible and bad.

Today we’re going to talk about what the word “Design” means in Software Design vs UX Design.

TRUTH #1 Big Up-Front Design has multiple meanings

What does it mean to do Big Up-Front Design?

In a general sense, it’s any time we do the bulk of the planning for a big thing we need to implement before we implement it.

When I say I’m doing Big Up-Front Design, as a UX Designer, I’m referring to the gathering of user research, scenarios, personas, etc. to form wireframes (and even prototypes or detailed specs) before developers start coding. I want to know (and want my client to know) what the happy paths are, where the business value is, and even sometimes which bits are going to be the expensive ones.

When developers talk about Big Up-Front Design, they could be talking about my job, but there’s a better chance they’re talking about the software development methodology which requires the software to have its systems design, database design, etc. all drawn up before coding begins. Big Up-Front Design refers to Software Design, and looks a lot like Waterfall.

TRUTH #2: Software Design doesn’t look anything like UX Design.

Software Design is a very different thing from product design.

Software Design is a discipline in which the Designer documents how the software itself is designed to use quality coding structures and data structures. We’re not talking about how the interface works, but how the application’s code is created.

The difficulty of using the term “design” in relation to software is that in some senses, the source code of a program is the design for the program that it produces. To the extent that this is true, “software design” refers to the design of the design.
~ Wikipedia

Software Design is where the development team figures out things like:

  • What is the best abstraction of the logic for this code chunk?
  • How do we refine the requirements from high-level statements to lines of code?
  • How do we make the code modular enough for reuse?
  • How do we architect the software?
  • How do we define the hierarchy of control within the software?
  • How do we partition the software structure?
  • What do the different data structures look like?
  • How do software procedures run?
  • What information-hiding techniques are appropriate in the software?

TRUTH #3: Big Up-Front Software Design can be more troublesome than Big Up-Front Product Design

As we covered in my last post, the goal of UX Design is to help clients define their products based on user goals and business needs.

The goal of Software Design is to help the developers define how they’re building the product.

There’s an interdependency there. A software design is only as strong as the requirements that help to define it. The requirements depend on the client knowing what they want. UX Design helps the client figure out what to build, so that the development team can then tackle how to build it.

Let’s say we have a client that’s contracted for a specific piece of software to be built, and let’s say that the Development team has opted for an up-front design.

If the client has a product design in hand, gathering up-front requirements is going to be easier, and writing a strong software design will be more successful (at least until the client changes their mind on the feature set).

If the client is still at the stage where they don’t understand what the user needs or how they’re going to deliver it, then the requirements gathering is going to be bumpy. If the dev team still chooses to do an up-front software design, it’s either going to be based on educated guesses on one end of the scale or it’s going to be incomplete on the other end.

This is not to say that a Big Up-Front Product Design is required for every project. It’s not. In-sprint UX design is certainly feasible on a lot of projects.

It is to say that a good software design depends on a good product design, so the product design must be produced earlier than the software design.

Since a good UX design can identify flaws in the product idea before developers are engaged, a product design that is created before the software design can not only save money by getting the right requirements, it can save a lot of money by identifying a product that should never be built in the first place.

CONCLUSION:

If someone says Big Up-Front Design is risky because it’s inflexible, well, there’s a grain of truth to that.

But there are different kinds of Big Up-Front Design and the UX Design type is less risky than the Software Design type, so the size of that grain of truth needs to be scaled accordingly.

 

Go to the next post on this topic, Doing Agile Wrong: When is Big Up-Front Design Right?

Nobody Will Read Your Welcome Letter

I have to put a welcome letter on a website. I have to do this because the welcome letter is in the printed program, and if it’s in the printed program, it also has to be on the website. There, it either takes up valuable space for useful content, or it appears as a PDF that no one wants to download, especially to read a welcome letter.

A welcome letter is a terrible thing for a website. There is no audience that wishes to read a welcome letter. They are fiction. They do not exist. People are on your website because they want information, not to read the welcoming platitudes delivered from a CEO, or president, or artist. This kind of content gets in the way of the useful content.

People might read your welcome letter in print. Oh yes, at least a few of them will. But make no mistake, they’re not reading it because they want to read it. They will because they’re currently sitting in your welcome lecture and they’re bored. They will because it’s socially acceptable to read the provided program while tuning out the welcome speaker. They will because it’s not acceptable to read anything on your phone while listening to the speaker. Even if they’re reading the welcome letter you put on the website—which of course they’re not, because the internet is full of much more useful things to read.

I put the welcome letter on the website because I had to, but I put it where nobody is likely to read it, because nobody will read it, no matter where I put it. I’m not just being smug. I know this because of the regular user testing my team has done. In these sessions, we watch real people skip vast swaths of content, many times scrolling straight down to the bottom with wild disregard for The Fold.

It was a political move, I admit, burying the link. It can be hard to convince people who write welcome letters that nobody wants to read them, in part because the writers put time into them and do provide them with the best intentions. Sometimes it’s best to pick your battles when you’re working with a client. Sometimes there’s not enough time or energy to spare for a discussion or argument over idealistic details. But sometimes your political concession doesn’t matter. Nobody asked me where the welcome letter was ultimately posted, because even when the clients use the website themselves, they have no interest in its welcome content.