“If you don’t have people that care about usability on your project, your project is doomed.”

— Jeff Atwood

Occasionally you’ll encounter people that question the value of user experience design. My advice is: don’t try to convince them. And don’t be goaded into an ROI (return of investment) discussion of UX with „non-believers“.

Make the case for user experience design and for its contribution once, maybe twice, as people may be unfamiliar with it. But don’t you don’t want a repearing “why this is actually needed?” discussion.

continue >

Nowadays it’s easy to learn the lingo and the approach of user experience design. It just takes an (online) course or two, and a few books. This teaches you the basics – so you are told. Unfortunately, it will not turn you into a UX designer.

UX design is a craft. And a craft needs practice and real-life practical experience. Without practice, you are just playing UX design. There is no substitute for hands-on, practical experience.

Made-up projects demonstrate that you know the steps of the UX design process. And that you can apply design methods. They show your method and process knowledge. They show that you know the basics and that you know the moves. But they cannot replace practical experiences. 

continue >

This is part of a larger series, you might want to consider reading parts one and two first.

As promised, I will now discuss the parts of the platform in more detail – starting with the server.

The main job of the server is to connect the prototype’s HTML and the ESP devices via MQTT and WebSockets. In the first iteration, I used Node.js​ and Express to write it, resulting in about 600 lines of code. But since I am a UX designer and not a developer it’s probably best when I don’t write (a lot of) code.
The source code felt a bit crude and overly complex to me. It was hard for someone with little coding experience to get how the server worked. And that made maintaining and changing it hard for regular folks.

continue >

Here is the link to part one of this series, you might want to start there.

Based on the before stated principles and requirements for the prototyping platform I came up with the following architecture:

On the left, you see the web server where the HTML of the Prototyping tool will be stored. On the right, the different hardware components (sensors and actuators, e.g. buttons, rotary encoders, LEDs) are connected to ESP8266 microcontrollers. In broad terms, ESPs are similar to Arduinos but also offer WiFi connectivity for a low price. In between sits a server to broker and translate the information coming from both sides.

continue >

This is the first article of a series (parts: two and three), as this topic needs some more space and time. I have about half of the content written, so I will post updates as I go along.

Even though the Internet of Things (IoT) is a hot topic, with today’s tools it is really hard to prototype and test IoT products or services beforehand. Very few tools allow us to use hardware components (like buttons or knobs) together with software user interfaces (UIs). Most software prototyping tools are closed systems offering no or only very little outside connectivity. Most of them only allow us to link screens together and that’s about it.

Plus, hardware prototyping is more complex than software prototyping: In addition to software interfaces, you need to know something about hardware, of course. Programming skills are needed if you want to tinker with them. And some knowledge about IoT protocols and platforms is helpful, too. These are skills very few user experience (UX) designers possess since a lot of them focus on the design of digital-only products and services. Just google the evergreen argument whether UX designers should be able to code.

Motivation

I thought that this was unfortunate since prototyping is such a crucial activity for creating successful products or services. We need to make your ideas tangible, test them with users and evaluate their feasibility before starting to build the real thing. And since I have some experience with software prototyping tools and tinkering with hardware I started looking for a way to create IoT prototypes.

continue >

For design to become corporate competency, it has to be more than just a department of people with the cool shoes, more than the activity you perform just prior to commercialization. Design is a way of approaching problem solving, decision making, and strategic planning that can yield better outcomes. It’s an open approach, and anyone in the organization can participate […].

Subject to Change, 2008

Amen.

Peter Merholz wrote that in 2008 – more than a decade ago. And organizations are still trying to get a grip on this.

About a year ago Mark Zuckerberg released a video clip about the result of his personal challenge of 2016: Jarvis, a simple AI to control his home.

Back in December 2016, this was cutting-edge technology: a smart home assistant you could talk to or chat with. It was able to play music, inform Zuckerberg about events, recognize faces, and control household applicants, of course.

continue >

Five years ago, in 2012, I released a small e-book on the Amazon Kindle platform called Axure for Mobile. At that time Axure 6.5 was just released, offering quite a few enhancements for mobile prototyping (swiping events, the mobile settings panel, etc.). My book described these new features and offered quite a few hacks which made mobile prototyping way easier.

continue >

For the longest time our discipline seemed to pay only lip service to one of the key activities of UX design: prototyping.

Yes, everybody always states that prototyping is important. Do it often and early on in the process. Always treat your prototypes as experiments. Don’t fall in love with them and last bust not least, always welcome failure.
Right.

continue >