Delivering value to your customer is your primary goal. You want purpose to motivate your product; you want it to be sustainable and intuitive to use. The way to get it there is by talking to the only people who can assess that value.
Those people are your customers.
Whether you’re building a swingset in the backyard or coding a blockchain ledger for microtransactions, you’ll soon know the value of user testing. Sometimes just trying to find the users to talk to teaches you something that you can put into your product. Listening to the voice of your user is such a powerful thing--we think these ten ideas will help you start off on the right foot.
At Lab Zero we ran into a use case a while back where we had some files that needed to be created and shared across Docker containers in the same EC2 Container Service (ECS) cluster. We typically use S3 for solving most types of shared storage situations, but in this case, we needed the storage to be mounted locally on each container instance. Thankfully Amazon Elastic File System (EFS) fit the bill. It provides elastic storage that can be mounted as an NFS drive with just a few simple steps.
I’ve been working on a Raspberry Pi 3 and Elixir Nerves project that utilizes an additional piece of hardware attached through an SPI controller. In order to get this hardware recognizable in Raspbian, I had to include an additional device tree overlay with my Nerves firmware. Raspbian uses a device tree to manage resource allocation and module loading. In order to make the kernel aware of our external SPI device, a device tree blob (DTB) that describes the hardware must be provided to the kernel on boot. While the process was pretty straight forward for Raspbian, I was left a little lost when it came to translating that over to a Nerves RPI3 system configuration. This was my first Nerves project, and I found the documentation was a little light in this area. (I have since updated the Nerves Advanced Configuration documentation to include information about device tree overlays.)
Software projects take effort to manage; that’s indisputable. In order to ensure that we’re spending our time in the most productive way, we make sure that the tools we use to help manage our projects are lightweight and focused on tracking useful information. Our development team usually prefers Pivotal Tracker and our design team likes Trello. No tool is perfect, but these two seem to have the right balance of flexibility and ease-of use while providing visibility into a team’s progress toward a goal.
Over the past year, we’ve been using my app, Lunch, almost every day to decide from a plethora of downtown SF restaurant choices. I made it as a fun little tool to teach myself new technologies, but it ended up becoming a routine — a sort of mainstay of our company culture.
Over the past twenty years, I’ve written my fair share of unit tests, mostly just covering the happy path and sending in some bogus inputs to test the edges. Typically following a fat-model-thin-controller method (often recommended by me), I failed to understand the point of integration tests. I tried TDD at the beginning of several greenfield projects, but I was never successful in making it sustainable. Similarly, with Selenium, it worked at first but quickly proved to be too brittle to keep up with rapidly changing UIs. (In retrospect, bad CSS architecture on those projects probably deserved the blame more than Selenium per se.)
Lab Zero Team members are passionate about staying up-to-date with latest topics and tools of our trade. We regularly host show-and-tell experiences in which a member of our team presents a topic to the rest of the team. They’re fun! They’re informative! They’re a little exclusive.
Most people cannot imagine life without the Internet. Can you also imagine being the only person without access while the world carries on without you? I don’t know about you, but I’d give up a lot of other things before giving up access to the Internet.