Tag: requirements

I took a week off of my real job so I could basically work a full week on just the startup. We’re nearing the end of our KM build and the publishing system was nothing but a few post-it notes and dreams.

The new part was so complex that I needed day-in and day-out focus to pull something coherent together. I’m thrilled to say that after nearly a week we have a really good prototype and agreement on how we’re going to approach the UI and feature set.

There’s still a bunch of work left to do before everything is ready for full requirements, but the really hard part of just thinking about how it should work is nearly done.

I’ve been struggling with one set of requirements for a few weeks. The prototype is basically done but I have had a bunch of trouble pulling together the card due to the complexities of the user groups and conditional logic involved.

I finally realized I was trying to do way too much with the one card sometime in the middle of last Saturday afternoon (5, 6 hours into it). The moment I decided to split the cards, the requirements became a heck of a lot easier.

I didn’t want to add more rework to the developer if I could help it, but I have since realized I was probably adding a bunch of time to him trying to figure out what I was trying to convey.

Another lesson learned. On a happy note, my requirements are moving far quicker now.

We’re making some nice progress on our MVP. Without getting into details, it’s marriage of knowledge base and publishing system. To my knowledge, there’s nothing quite like it in production today.

On the business side of things, this is great!

For development – especially UI / UX – it presents a bunch of challenges since there’s not much to mimick.

I installed Balsamiq shortly after starting the work and the wireframing have been helpful, but they can only get us so far. Earlier this year, we moved to Proto.io for rapid prototyping and it’s been awesome. It’s sort of a mix between Balsamiq and more advanced tools but it is still user friendly.

We can easily pull together a prototype and see if it works rather than committing a lot of hours to developing and then pulling it apart. Frankly, I’m unsure how we ever got this far without it.

I’m about to start my main afternoon activity, which for weeks / months / or years depending on how one looks at the work has been filled with writing requirements.

For the record, we’ve been doing this thing for years, but the drafting of written requirements have been hit or miss. My first requirement was about two pages and included a crudely designed layout in Balsamiq that had a few boxes and copy in it. In my mind, it was all we needed. 

But, B needed a little more. Okay, he needed a bunch more. 

Over time, we got the basic requirement ideas in place and B started developing and designing at the same time. As you can guess, this sort of worked for the basic ideas but became a hot mess when we started looking at details.

It doesn’t help that our app marries two large but related ideas so instead of fleshing out just one big ass app, we’re fleshing out two big ass apps. So, back in 2016 we got ourselves a Confluence / JIRA account and our requirements at least started to look a little more thorough. I then studied up on agile requirements and planning (still a work in progress) to attempt to get our drafts accurate.

This year, we’re doing pretty well. The written requirements are looking pretty good and our wireframes are decent too. Not too bad after nearly two-years of making a mess out of the idea. 

A big thing I’ve learned is to fight the urge to combine activities. I’m now trying to draft written business requirements and then do the wireframes rather than combining them. And, instead of trying to plan how the work is done at the same time, I’m now getting more feedback and doing joint planning with B and our new developer.

The separate has helped me move more quickly since it’s relatively easy to write down what we want to see from a screen and then draw pictures. The combined approach was really, really slowing down the process.